Corrigir travamentos do servidor de mídia Kurento do BigBlueButton sob carga

Um processo do Kurento Media Server (KMS) que é encerrado durante reuniões movimentadas do BigBlueButton pode interromper a gravação ou, em instalações mais antigas, o áudio e vídeo ao vivo. O primeiro resultado útil não é simplesmente um serviço que reinicia: é saber qual pilha de mídia está lidando com o recurso afetado, qual recurso ou falha precede o encerramento e se a correção mantém a estabilidade da próxima reunião comparável.

Comece confirmando a versão do BigBlueButton e o papel que o Kurento desempenha neste servidor. O BigBlueButton 2.5 e versões posteriores usam o mediasoup por padrão para mídia WebRTC ao vivo; o Kurento pode ainda estar presente para gravação ou porque um administrador manteve uma configuração legada/personalizada. Portanto, o fato de o Kurento ter travado não prova, por si só, que o KMS está sobrecarregando as webcams. Consulte o guia oficial de solução de problemas do BigBlueButton para obter informações sobre a diferença entre as versões. As soluções detalhadas para o KMS abaixo foram extraídas do guia de personalização do servidor BigBlueButton 2.7 ; verifique a documentação correspondente à sua versão instalada antes de aplicá-las.

Primeiro, confirme o que falhou.

Reúna evidências antes de reiniciar os serviços repetidamente. Registre o horário em que os usuários perceberam o problema pela primeira vez, a reunião afetada, se houve falha de áudio, webcam, compartilhamento de tela ou gravação e se todo o servidor ou apenas um recurso de mídia apresentou problemas. Reiniciar um serviço pode restaurar um processo temporariamente, mas elimina as pistas de tempo que diferenciam uma falha grave de um problema de rede ou do cliente.

No host do BigBlueButton, comece com verificações somente leitura:

sudo bbb-conf --check
sudo systemctl status kurento-media-server --no-pager
sudo journalctl -u kurento-media-server --since "1 hour ago" --no-pager
sudo ls -lt /var/log/kurento-media-server/ | head

Use o nome da unidade relevante para a versão e a implantação. Se o serviço estiver dividido em várias unidades KMS, inspecione a unidade e o log do processo que falhou. Compare o carimbo de data/hora do journal do systemd com o log KMS mais recente. Procure por uma saída explícita, um loop de reinicialização, uma falha no pipeline de mídia ou uma mensagem relacionada a recursos; uma única linha de "aviso" sem uma falha correspondente não é suficiente para identificar a causa.

Confirme se os usuários realmente utilizam o Kurento para o tráfego com falha. No Firefox, about:webrtcé possível expor os detalhes da conexão ponto a ponto; o Chrome oferece chrome://webrtc-internals[informações adicionais sobre como verificar detalhes da sessão negociada]. A documentação de solução de problemas do BigBlueButton descreve como verificar os detalhes da sessão negociada para o MediaSoup. Inspecione também seus serviços de mídia configurados e o fluxo de trabalho de gravação. Se a mídia ao vivo estiver no MediaSoup e a gravação só parar quando o KMS for encerrado, ajuste o caminho de gravação/Kurento em vez de alterar indiscriminadamente as configurações da webcam ao vivo.

Determine a pressão que ocorre antes da saída.

"Sob carga" pode significar vários gargalos diferentes. Faça um teste no host enquanto uma reunião representativa estiver ativa e compare o resultado com o horário do evento. Algumas verificações úteis incluem:

• free -he vmstat 1para memória disponível, troca de páginas e pressão na fila de execução;
• mpstat -P ALL 1para saturação de CPU por núcleo, caso as sysstatferramentas estejam instaladas;
• df -he iostat -xz 1para uma latência completa do sistema de arquivos ou armazenamento, quando disponível;
• journalctl -k --since "1 hour ago"para mensagens do kernel, incluindo um encerramento por falta de memória;
• Registros de status do systemd e do KMS para saídas repetidas, falhas de pipeline e qual operação de mídia estava ativa.

Não confie apenas na média de uso da CPU do servidor. Um processo de mídia pode ser limitado por um núcleo ocupado enquanto outros núcleos parecem ociosos, ou a pressão na memória pode causar o encerramento do serviço sem um longo período de uso intenso da CPU. Por outro lado, um relato de "câmera congelada" do usuário pode ocorrer enquanto o KMS permanece ativo porque o UDP está bloqueado ou o navegador não consegue estabelecer uma conexão WebRTC. A BigBlueButton documenta o TURN como uma solução para redes restritivas; o TURN pode melhorar a conectividade, mas não adiciona capacidade de processamento ao KMS. Se o serviço permanecer ativo e os registros não mostrarem nenhum evento de recurso, investigue o ICE, o firewall e a conectividade do cliente antes de aumentar os limites de mídia.

A capacidade depende da combinação real de fluxos e processamento, e não apenas do número de participantes na reunião. O número de webcams publicadas e recebidas, compartilhamentos de tela, sessões de áudio, gravações, qualidade negociada e layout da reunião são fatores importantes. É por isso que um limite sustentável deve ser definido com base no padrão de reuniões da própria organização, em vez de ser copiado de um servidor externo.

Escolha uma solução que corresponda às evidências.

Para uma implementação KMS legada, cargas de trabalho de mídia separadas.

O guia de personalização do BigBlueButton 2.7 documenta a execução de três processos KMS, um para cada função: áudio (somente escuta), webcam e compartilhamento de tela. O benefício declarado é distribuir as tarefas de iniciar/parar a mídia entre processos separados e limitar o impacto quando um processo KMS falha. A configuração do guia utiliza as enableMultipleKurentosconfigurações do script do BigBlueButton e, em seguida, reinicia o BigBlueButton. Siga as instruções específicas para a sua versão e verifique as unidades de serviço e os logs resultantes após a reinicialização.

Essa separação é uma medida de contenção e distribuição, não um substituto para CPU, memória ou armazenamento suficientes. Ela também pode aumentar o uso de recursos básicos, pois processos adicionais são executados. Agende uma janela de manutenção: sudo bbb-conf --restartinterrompe as sessões ativas. Não edite manualmente os arquivos de serviço gerados nem assuma que um comando documentado para a versão 2.7 se aplica sem alterações a uma instalação mais recente ou modificada pelo fornecedor.

Defina limites de mídia quando o servidor precisar de um limite de admissão.

Para versões baseadas em KMS que suportam a opção documentada, o BigBlueButton permite mediaThresholdsvalores para global, perRoome perUser. O guia da versão 2.7 mostra esses valores em /etc/bigbluebutton/bbb-webrtc-sfu/production.yml, um arquivo de sobrescrita que deve persistir mesmo após atualizações de pacotes. No exemplo documentado, zero significa nenhum limite. Atingir um limite configurado pode causar um erro "Recursos de mídia não disponíveis (2002)" quando um participante tenta compartilhar uma webcam.

Escolha valores com base na capacidade medida e na qualidade de serviço necessária; não copie o exemplo ilustrativo da documentação como um limite seguro universal. Um limite torna a sobrecarga mais previsível, recusando mídias adicionais, mas não corrige uma falha causada por um bug, um vazamento de memória ou uma limitação não relacionada do sistema operacional. Confirme os nomes e o comportamento das configurações na documentação da sua versão antes de implantá-la.

Reduzir a demanda por mídia antes de aumentar as projeções de capacidade.

Quando o monitoramento indicar saturação de recursos, reduza primeiro o pico de trabalho que o serviço precisa executar. Peça aos moderadores que ativem as webcams seletivamente, evitem compartilhamentos de tela simultâneos desnecessários ou dividam uma sessão interativa muito grande em salas menores, se isso se adequar ao formato da aula. Em versões que oferecem suporte à paginação por webcam ou limites de fluxo, ajuste-os por meio do mecanismo de sobreposição documentado. Um número menor de fluxos recebidos pode reduzir a dispersão, enquanto diminuir a resolução da câmera ou a taxa de bits pode reduzir a demanda de processamento e largura de banda. Essas alterações sacrificam detalhes visuais ou espontaneidade em prol da estabilidade; explique essa compensação aos organizadores da reunião e certifique-se de que a experiência resultante seja aceitável.

Considere uma atualização ou mudança de arquitetura quando os limites retornarem.

Se a versão instalada for antiga, confirme o caminho de atualização suportado e a arquitetura de mídia antes de investir mais em ajustes do KMS. Desde o BigBlueButton 2.5, o mediasoup é o padrão para mídia ao vivo, enquanto o papel do Kurento difere das versões anteriores. Uma falha persistente do KMS em um servidor atual pode, portanto, indicar problemas com gravações, uma pilha de mídia personalizada ou uma integração específica. Para uma implantação legada que atinge repetidamente seu limite máximo após ajustes razoáveis ​​e alterações na carga de trabalho, atualizar ou redesenhar a implantação pode ser mais eficaz do que aumentar os limites. O custo operacional inclui testes de compatibilidade, planejamento de migração e uma janela de manutenção.

Valide a alteração em uma reunião comparável.

Altere uma configuração ou prática de carga de trabalho por vez e, em seguida, teste usando uma reunião controlada que simule o uso máximo normal. Observe a versão do BigBlueButton, o número de participantes, o número aproximado de webcams ativas, os compartilhamentos de tela e se a gravação está ativada. Isso fornece uma comparação útil sem considerar o número de participantes como a única variável de carga.

• Confirme se a unidade KMS relevante permanece ativa e não entra em um loop de reinicialização.
• Compare o uso da CPU por núcleo, a memória disponível e o espaço de troca (swap), a atividade do disco e os registros antes e durante o teste.
• Verifique o áudio, a webcam, o compartilhamento de tela e a gravação separadamente, de acordo com a função que o Kurento realmente desempenha.
• Verifique se os erros de 2002, a falha na configuração de mídia ou os relatórios de usuários mudam; nenhuma métrica isolada comprova a correção.
• Repita o procedimento no período de maior movimento previsto antes de declarar a alteração de capacidade como bem-sucedida.

Se o serviço continuar apresentando falhas, capture o log exato do KMS e a janela do journal, as mensagens do kernel, as versões instaladas do BigBlueButton/Kurento e as configurações alternativas ativas para o administrador ou equipe de suporte. Se o serviço permanecer íntegro, mas os usuários ainda não conseguirem se conectar, direcione a investigação para possíveis vulnerabilidades do ICE, regras de firewall, disponibilidade do TURN e diagnósticos do WebRTC no navegador. O resultado ideal é uma carga de trabalho de mídia estável com limites compreendidos — não um número ilimitado de streams ou a garantia de que uma única configuração seja adequada para todos os servidores.

Fontes e notas de versão

• BigBlueButton 2.7: Personalização do servidor — múltiplos processos Kurento, limites de mídia e configurações relacionadas.
• BigBlueButton: Guia de Solução de Problemas — identificação da pilha de mídia atual, configurações padrão do MediaSoup, notas do Kurento e solução de problemas de rede.
• BigBlueButton: Arquivos de Configuração — orientações sobre arquivos de configuração e de substituição.

Documentação revisada em 5 de outubro de 2026. Os exemplos detalhados de carga de trabalho e limite do Kurento acima estão explicitamente vinculados à documentação do BigBlueButton 2.7; verifique as notas de versão e o guia do administrador correspondentes antes de aplicar as configurações em outros locais.