Résolution des plantages du serveur multimédia Kurento BigBlueButton sous charge

Un processus Kurento Media Server (KMS) qui s'arrête pendant une réunion BigBlueButton chargée peut interrompre l'enregistrement ou, sur les installations plus anciennes, la diffusion audio et vidéo en direct. Le premier résultat utile n'est pas simplement le redémarrage du service : il est essentiel de savoir quelle pile multimédia gère la fonctionnalité affectée, quelle ressource ou quelle panne a précédé l'arrêt, et si la correction permet de garantir la stabilité de la prochaine réunion comparable.

Commencez par vérifier la version de BigBlueButton et le rôle de Kurento sur ce serveur. BigBlueButton 2.5 et versions ultérieures utilisent MediaSoup par défaut pour la diffusion en direct via WebRTC ; Kurento peut être conservé pour l’enregistrement ou parce qu’un administrateur a gardé une configuration personnalisée. Par conséquent, un plantage de Kurento ne prouve pas à lui seul que KMS est à l’origine de la surcharge des webcams. Consultez le guide de dépannage officiel de BigBlueButton pour connaître les différences entre les versions. Les solutions KMS détaillées ci-dessous sont issues du guide de personnalisation du serveur BigBlueButton 2.7 ; vérifiez la documentation correspondant à votre version installée avant de les appliquer.

Vérifiez d'abord ce qui a échoué.

Avant de redémarrer les services à plusieurs reprises, recueillez des preuves. Notez l'heure à laquelle les utilisateurs ont constaté le problème pour la première fois, la réunion concernée, si l'audio, la webcam, le partage d'écran ou l'enregistrement ont dysfonctionné, et si c'est tout le serveur ou seulement une fonctionnalité multimédia qui a été affectée. Un redémarrage de service peut rétablir temporairement un processus, mais efface les indices temporels permettant de distinguer un plantage d'un problème réseau ou client.

Sur l'hôte BigBlueButton, commencez par des contrôles en lecture seule :

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

Utilisez le nom d'unité approprié pour la version et le déploiement. Si le service est divisé en plusieurs unités KMS, examinez l'unité et le journal pour identifier le processus ayant échoué. Comparez l'horodatage du journal systemd avec le journal KMS le plus récent. Recherchez une sortie explicite, une boucle de redémarrage, une défaillance du pipeline média ou un message relatif aux ressources ; une simple ligne d'avertissement sans défaillance correspondante ne suffit pas à identifier la cause.

Vérifiez si les utilisateurs utilisent bien Kurento pour le trafic défaillant. Sous Firefox, about:webrtcil est possible d'afficher les détails de connexion du pair ; Chrome propose une autre option chrome://webrtc-internals. La documentation de dépannage de BigBlueButton explique comment vérifier les détails de session négociés pour MediaSoup. Examinez également vos services multimédias configurés et votre flux d'enregistrement. Si la diffusion en direct est assurée par MediaSoup et que l'enregistrement s'arrête uniquement lorsque KMS se ferme, optimisez le chemin d'enregistrement/Kurento plutôt que de modifier à l'aveugle les paramètres de la webcam en direct.

Trouvez la pression qui précède la sortie

Une charge insuffisante peut correspondre à plusieurs goulots d'étranglement. Effectuez un test sur l'hôte pendant une réunion représentative et comparez-le à l'heure de l'événement. Voici quelques vérifications utiles :

• free -het vmstat 1pour la mémoire disponible, le swapping et la pression sur la file d'attente d'exécution ;
• mpstat -P ALL 1pour la saturation du processeur par cœur, si les sysstatoutils sont installés ;
• df -het iostat -xz 1pour une latence complète du système de fichiers ou du stockage, le cas échéant ;
• journalctl -k --since "1 hour ago"pour les messages du noyau, y compris un arrêt dû à une insuffisance de mémoire ;
• État de systemd et journaux KMS pour les sorties répétées, les défaillances de pipeline et l'opération média active.

Ne vous fiez pas uniquement à l'utilisation moyenne du processeur du serveur. Un processus multimédia peut être ralenti par un cœur occupé tandis que d'autres semblent inactifs, ou une saturation de la mémoire peut entraîner une interruption sans période prolongée d'utilisation élevée du processeur. Inversement, un utilisateur peut signaler un blocage de sa caméra alors que KMS fonctionne correctement, car le protocole UDP est bloqué ou le navigateur ne parvient pas à établir une connexion WebRTC. BigBlueButton recommande l'utilisation de TURN pour les réseaux restrictifs ; TURN peut améliorer la connectivité, mais n'augmente pas la capacité de calcul de KMS. Si le service reste actif et que les journaux ne signalent aucun événement lié aux ressources, examinez ICE, le pare-feu et la connectivité du client avant d'augmenter les limites multimédias.

La capacité dépend de la combinaison réelle des flux et de la puissance de traitement, et non pas seulement du nombre de participants. Le nombre de webcams émises et reçues, de partages d'écran, de sessions audio, d'enregistrements, la qualité négociée et la configuration de la réunion sont autant d'éléments importants. C'est pourquoi une limite durable doit être définie en fonction des habitudes de réunion propres à l'organisation, plutôt que d'être calquée sur un serveur externe.

Choisissez un remède qui corresponde aux preuves.

Pour un déploiement KMS existant, séparer les charges de travail multimédias

Le guide de personnalisation de BigBlueButton 2.7 explique comment exécuter trois processus KMS : un pour l’audio (écoute seule), un pour la webcam et un pour le partage d’écran. L’avantage principal est de répartir la gestion des flux multimédias sur plusieurs processus et de limiter l’impact d’une panne de l’un d’eux. La configuration décrite dans le guide utilise les enableMultipleKurentosparamètres du script de configuration de BigBlueButton, puis redémarre le service. Suivez les instructions correspondant à votre version et examinez les unités de service et les journaux après le redémarrage.

Cette séparation est une mesure de confinement et de distribution, et non un substitut à une puissance de calcul, une mémoire ou un espace de stockage suffisants. Elle peut également augmenter l'utilisation des ressources de base en raison de l'exécution de processus supplémentaires. Planifiez une fenêtre de maintenance : sudo bbb-conf --restartelle interrompt les sessions actives. Ne modifiez pas manuellement les fichiers de service générés et ne présumez pas qu'une commande documentée pour la version 2.7 s'applique sans modification à une installation plus récente ou modifiée par le fournisseur.

Définissez des seuils de média lorsque le serveur a besoin d'une limite d'admission.

Pour les versions KMS prenant en charge l'option documentée, BigBlueButton accepte mediaThresholdsdes valeurs pour `limit` global, perRoom`limit` et ` perUsermax`. Le guide 2.7 les présente dans ` /etc/bigbluebutton/bbb-webrtc-sfu/production.yml<nom_du_fichier_de_configuration>`, un fichier de remplacement conçu pour être conservé après les mises à jour du package. Dans l'exemple documenté, la valeur zéro signifie qu'il n'y a pas de limite. Atteindre un seuil configuré peut provoquer une erreur « Ressources multimédias non disponibles (2002) » lorsqu'un participant tente de partager sa webcam.

Choisissez des valeurs en fonction de la capacité mesurée et de la qualité de service requise ; ne vous basez pas sur l’exemple illustratif de la documentation comme limite de sécurité universelle. Un seuil permet de mieux prévoir les surcharges en limitant l’utilisation de supports supplémentaires, mais il ne résout pas les problèmes liés à un bug, une fuite de mémoire ou une limitation du système d’exploitation. Avant de déployer votre version, vérifiez la signification des paramètres et leur comportement dans la documentation.

Réduire la demande des médias avant de revoir à la hausse les hypothèses de capacité

Lorsque la surveillance révèle une saturation des ressources, commencez par réduire la charge de travail maximale du service. Demandez aux modérateurs d'activer les webcams de manière sélective, d'éviter les partages d'écran simultanés inutiles ou de diviser une session interactive très importante en plusieurs salles plus petites si cela convient au format pédagogique. Sur les versions prenant en charge la pagination des webcams ou les limites de flux, ajustez ces paramètres via le mécanisme de remplacement documenté. Un nombre réduit de flux reçus peut diminuer la diffusion, tandis qu'une réduction de la résolution ou du débit binaire de la caméra peut diminuer la demande de traitement et de bande passante. Ces modifications impliquent un compromis entre la qualité visuelle ou la spontanéité et la stabilité ; expliquez ce compromis aux organisateurs de la réunion et assurez-vous que l'expérience utilisateur est satisfaisante.

Envisagez une mise à niveau ou une modification de l'architecture lorsque les limites seront rétablies.

Si la version installée est ancienne, vérifiez la procédure de mise à niveau et l'architecture média prises en charge avant d'investir davantage dans l'optimisation du KMS. Depuis BigBlueButton 2.5, MediaSoup est le système par défaut pour la diffusion en direct, tandis que le rôle de Kurento diffère des versions précédentes. Un plantage persistant du KMS sur un serveur actuel peut donc indiquer un problème d'enregistrement, une configuration média personnalisée ou une intégration spécifique. Pour un déploiement existant qui atteint régulièrement sa limite maximale après des ajustements raisonnables de la charge de travail, une mise à niveau ou une refonte du déploiement peut s'avérer plus efficace que l'augmentation des seuils. Le coût opérationnel comprend les tests de compatibilité, la planification de la migration et une fenêtre de maintenance.

Valider la modification lors d'une réunion comparable

Modifiez un paramètre ou une pratique de charge de travail à la fois, puis effectuez un test lors d'une réunion contrôlée simulant une utilisation intensive habituelle. Notez la fréquence de lancement de BigBlueButton, le nombre de participants, le nombre approximatif de webcams actives, les partages d'écran et si l'enregistrement est activé. Cela permet une comparaison pertinente sans considérer le nombre de participants comme la seule variable de charge.

• Vérifiez que l'unité KMS concernée reste active et n'entre pas dans une boucle de redémarrage.
• Comparez le processeur par cœur, la mémoire disponible et le swap, l'activité du disque et les journaux avant et pendant le test.
• Vérifiez séparément les fonctions audio, webcam, partage d'écran et enregistrement, en fonction du rôle que joue réellement Kurento.
• Vérifiez si les erreurs 2002, les échecs de configuration des supports ou les rapports des utilisateurs changent ; aucun indicateur unique ne prouve la résolution du problème.
• Répétez l'opération pendant la période de forte activité prévue avant de déclarer le changement de capacité réussi.

Si le service continue de planter, capturez le journal KMS et la fenêtre de journalisation, les messages du noyau, les versions installées de BigBlueButton/Kurento, ainsi que les configurations spécifiques à l'administrateur ou à l'équipe de support. Si le service reste opérationnel mais que les utilisateurs ne peuvent toujours pas se connecter, examinez les vulnérabilités ICE potentielles, les règles de pare-feu, la disponibilité de TURN et les diagnostics WebRTC côté navigateur. L'objectif est d'obtenir une charge de travail multimédia stable avec des limites bien définies, et non un nombre de flux illimité ou la garantie qu'une seule configuration convienne à tous les serveurs.

Sources et notes de version

• BigBlueButton 2.7 : Personnalisation du serveur — plusieurs processus Kurento, seuils de médias et configuration associée.
• BigBlueButton : Guide de dépannage — identification de la pile média actuelle, paramètres par défaut de mediasoup, notes Kurento et dépannage réseau.
• BigBlueButton : Fichiers de configuration — instructions pour les fichiers de configuration et de remplacement.

Documentation révisée le 5 octobre 2026. Les exemples détaillés de charge de travail et de seuil Kurento ci-dessus sont explicitement liés à la documentation BigBlueButton 2.7 ; veuillez consulter les notes de version et le guide de l’administrateur correspondants avant d’appliquer les paramètres ailleurs.