Inicio
» ADMINISTRADOR DE RED
»
Solucionar los fallos del servidor multimedia BigBlueButton Kurento bajo carga
Solucionar los fallos del servidor multimedia BigBlueButton Kurento bajo carga
Un proceso de Kurento Media Server (KMS) que finaliza durante reuniones concurridas de BigBlueButton puede interrumpir la grabación o, en instalaciones más antiguas, el audio y el vídeo en directo. El primer resultado útil no es simplemente que el servicio se reinicie, sino saber qué pila de medios gestiona la función afectada, qué recurso o fallo precede a la finalización y si la solución mantiene la estabilidad de la siguiente reunión similar.
Para empezar, confirme la versión de BigBlueButton y el rol que desempeña Kurento en este servidor. BigBlueButton 2.5 y versiones posteriores utilizan mediasoup de forma predeterminada para la transmisión de contenido WebRTC en directo; Kurento podría estar presente para la grabación o porque un administrador conservó una configuración antigua o personalizada. Por lo tanto, que Kurento se haya bloqueado no demuestra por sí solo que KMS esté gestionando las cámaras web sobrecargadas. Consulte la guía oficial de solución de problemas de BigBlueButton para conocer las diferencias entre versiones. Las soluciones detalladas para KMS que se describen a continuación se basan en la guía de personalización del servidor BigBlueButton 2.7 ; consulte la documentación correspondiente a su versión instalada antes de aplicarlas.
Utilice esta herramienta sudo bbb-conf --checkpara determinar la versión instalada de BigBlueButton y revisar la configuración antes de cambiar la pila de medios.
Primero, confirma qué falló.
Recopile pruebas antes de reiniciar los servicios repetidamente. Registre la hora en que los usuarios detectaron el problema por primera vez, la reunión afectada, si falló el audio, la cámara web, la pantalla compartida o la grabación, y si se degradó todo el servidor o solo una función multimedia. Reiniciar un servicio puede restaurar un proceso temporalmente, pero borra las pistas temporales que distinguen un fallo de un problema de red o del cliente.
En el host de BigBlueButton, comience con comprobaciones de solo lectura:
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
Utilice el nombre de unidad correspondiente para la versión y el despliegue. Si el servicio se divide en varias unidades KMS, inspeccione la unidad y el registro del proceso que falló. Compare la marca de tiempo del registro de systemd con el registro KMS más reciente. Busque una salida explícita, un bucle de reinicio, una canalización de medios fallida o un mensaje relacionado con los recursos; una sola línea de advertencia sin un fallo correspondiente no es suficiente para identificar la causa.
Confirma si los usuarios realmente usan Kurento para el tráfico que falla. En Firefox, about:webrtcse pueden exponer los detalles de la conexión entre pares; Chrome ofrece chrome://webrtc-internals. La documentación de solución de problemas de BigBlueButton describe cómo verificar los detalles de la sesión negociada para mediasoup. Inspecciona también tus servicios de medios configurados y el flujo de trabajo de grabación. Si el contenido multimedia en vivo está en mediasoup y la grabación solo se detiene cuando sale KMS, ajusta la ruta de grabación/Kurento en lugar de cambiar a ciegas la configuración de la cámara web en vivo.
Compare la presión sobre la CPU y la memoria del proceso multimedia correspondiente con el momento en que finaliza el servicio; este panel es una vista esquemática del monitor, no datos del servidor en tiempo real.
Encuentra la presión que precede a la salida.
El término “bajo carga” puede referirse a varios cuellos de botella diferentes. Tome muestras del servidor mientras se desarrolla una reunión representativa y compare la muestra con el tiempo del evento. Las comprobaciones útiles incluyen:
free -hy vmstat 1para la memoria disponible, el intercambio y la presión de la cola de ejecución;
mpstat -P ALL 1para la saturación de la CPU por núcleo, si las sysstatherramientas están instaladas;
df -hy iostat -xz 1para una latencia completa del sistema de archivos o almacenamiento, cuando esté disponible;
journalctl -k --since "1 hour ago"para mensajes del kernel, incluyendo una terminación por falta de memoria;
Registros de estado de systemd y KMS para salidas repetidas, fallos en la canalización y qué operación de medios estaba activa.
No confíe únicamente en el rendimiento promedio de la CPU del servidor. Un proceso multimedia puede verse limitado por un núcleo ocupado mientras otros núcleos parecen inactivos, o la presión de la memoria puede provocar un cierre inesperado sin un período prolongado de alta actividad de la CPU. Por el contrario, el informe de "cámara congelada" de un usuario puede ocurrir mientras KMS permanece en buen estado porque UDP está bloqueado o el navegador no puede establecer una ruta WebRTC. BigBlueButton documenta TURN como una solución para redes restrictivas; TURN puede mejorar la conectividad, pero no aumenta la capacidad de procesamiento de KMS. Si el servicio permanece activo y los registros no muestran ningún evento de recursos, investigue ICE, el firewall y la conectividad del cliente antes de aumentar los límites de medios.
La capacidad depende de la combinación real de transmisiones y procesamiento, no solo del número de participantes en la reunión. La cantidad de cámaras web publicadas y recibidas, pantallas compartidas, sesiones de audio, grabaciones, calidad negociada y el diseño de la reunión son factores importantes. Por ello, el límite sostenible debe medirse en función del patrón de reuniones propio de la organización, en lugar de copiarlo de un servidor externo.
Observe las tendencias de la CPU, la memoria, la E/S del disco y la red de forma conjunta durante una reproducción controlada; las líneas ascendentes ilustran las categorías que se deben supervisar, no el rendimiento medido de BigBlueButton.
Elija un remedio que se ajuste a la evidencia.
Para una implementación de KMS heredada, separe las cargas de trabajo de medios.
La guía de personalización de BigBlueButton 2.7 documenta la ejecución de tres procesos KMS: uno para audio de solo escucha, otro para la cámara web y otro para la gestión de pantalla compartida. Su principal ventaja es distribuir las tareas de inicio y detención de medios entre procesos independientes, minimizando así el impacto en caso de que un proceso KMS falle. La configuración descrita en la guía utiliza la enableMultipleKurentosconfiguración del script de configuración de BigBlueButton y, a continuación, reinicia BigBlueButton. Siga las instrucciones correspondientes a su versión y revise las unidades de servicio y los registros resultantes tras el reinicio.
Esta separación es una medida de contención y distribución, no un sustituto de suficiente CPU, memoria o almacenamiento. También puede aumentar el uso de recursos base debido a la ejecución de procesos adicionales. Programe una ventana de mantenimiento: sudo bbb-conf --restartinterrumpe las sesiones activas. No edite manualmente los archivos de servicio generados ni asuma que un comando documentado para la versión 2.7 se aplica sin cambios a una instalación más reciente o modificada por el proveedor.
Establezca umbrales de medios cuando el servidor necesite un límite de admisión.
Para las versiones basadas en KMS que admiten la opción documentada, BigBlueButton permite mediaThresholdsvalores para global, perRoom, y perUser. La guía 2.7 muestra estos en /etc/bigbluebutton/bbb-webrtc-sfu/production.yml, un archivo de anulación diseñado para sobrevivir a las actualizaciones del paquete. Un cero significa que no hay límite en el ejemplo documentado. Alcanzar un umbral configurado puede causar un error de "Recursos multimedia no disponibles (2002)" cuando un participante intenta compartir una cámara web.
Seleccione valores que se ajusten a la capacidad medida y a la calidad de servicio requerida; no copie el ejemplo ilustrativo de la documentación como límite seguro universal. Un umbral permite predecir mejor la sobrecarga al reducir el uso de medios adicionales, pero no soluciona un fallo causado por un error, una fuga de memoria o un límite del sistema operativo no relacionado. Confirme los nombres y el comportamiento de la configuración en la documentación de su versión antes de implementarla.
El ejemplo de configuración identifica únicamente las claves de umbral; seleccione valores compatibles con la versión a partir de la carga medida y la documentación correspondiente de BigBlueButton.
Reduzca la demanda de medios antes de aumentar las previsiones de capacidad.
Cuando el monitoreo muestre saturación de recursos, primero reduzca la carga máxima de trabajo del servicio. Pida a los moderadores que activen las cámaras web de forma selectiva, evite compartir pantallas simultáneamente innecesariamente o divida una sesión interactiva muy grande en salas más pequeñas si esto se ajusta al formato de la clase. En las versiones que permiten paginación de cámaras web o límites de transmisión, ajústelos mediante el mecanismo de anulación documentado. Un menor número de transmisiones recibidas puede reducir la dispersión, mientras que disminuir la resolución o la tasa de bits de la cámara puede reducir el procesamiento y la demanda de ancho de banda. Estos cambios implican sacrificar detalle visual o espontaneidad a cambio de estabilidad; explique esta compensación a los anfitriones de la reunión y verifique que la experiencia resultante sea aceptable.
Considere una actualización o un cambio de arquitectura cuando regresen los límites.
Si la versión instalada es antigua, confirme la ruta de actualización compatible y la arquitectura de medios antes de invertir más en la optimización de KMS. Desde BigBlueButton 2.5, mediasoup es la opción predeterminada para medios en directo, mientras que la función de Kurento difiere de versiones anteriores. Por lo tanto, un fallo persistente de KMS en un servidor actual puede indicar problemas con la grabación, una pila de medios personalizada o una integración específica. Para una implementación heredada que alcanza repetidamente su límite máximo tras establecer límites razonables y realizar cambios en la carga de trabajo, actualizar o rediseñar la implementación puede ser más eficaz que aumentar los umbrales. El coste operativo reside en las pruebas de compatibilidad, la planificación de la migración y una ventana de mantenimiento.
Validar el cambio en una reunión comparable.
Modifique una configuración o práctica de carga de trabajo a la vez y luego realice una prueba con una reunión controlada que simule un uso máximo normal. Anote la liberación del botón BigBlueButton, el número de participantes, la cantidad aproximada de cámaras web activas, las pantallas compartidas y si la grabación está habilitada. Esto permite una comparación útil sin considerar el número de participantes como la única variable de carga.
Confirme que la unidad KMS correspondiente permanece activa y no entra en un bucle de reinicio.
Compare el uso de CPU por núcleo, la memoria disponible y el espacio de intercambio, la actividad del disco y los registros antes y durante la prueba.
Verifique el audio, la cámara web, la función de compartir pantalla y la grabación por separado, según el rol que Kurento desempeñe realmente.
Compruebe si cambian los errores de 2002, la configuración fallida de los medios o los informes de los usuarios; ninguna métrica por sí sola demuestra que la solución es correcta.
Repita el procedimiento durante el período de mayor afluencia previsto antes de declarar que el cambio de capacidad ha sido exitoso.
Si el servicio sigue fallando, capture el registro KMS exacto, la ventana de registro, los mensajes del kernel, las versiones instaladas de BigBlueButton/Kurento y las anulaciones de configuración activas para el administrador o el equipo de soporte. Si el servicio se mantiene en buen estado, pero los usuarios aún no pueden conectarse, centre la investigación en posibles errores ICE, reglas de firewall, disponibilidad de TURN y diagnósticos de WebRTC del navegador. El resultado ideal es una carga de trabajo multimedia estable con límites definidos, no un número ilimitado de transmisiones ni la garantía de que una configuración se adapte a todos los servidores.
BigBlueButton: Guía de solución de problemas : identificación actual de la pila de medios, valores predeterminados de mediasoup, notas de Kurento y solución de problemas de red.
Documentación revisada el 5 de octubre de 2026. Los ejemplos detallados de carga de trabajo y umbrales de Kurento que se muestran arriba están vinculados explícitamente a la documentación de BigBlueButton 2.7; verifique las notas de la versión y la guía del administrador correspondientes antes de aplicar la configuración en otros lugares.