Behebung von Abstürzen des BigBlueButton Kurento Media Servers unter Last

Ein Kurento Media Server (KMS)-Prozess, der während einer stark frequentierten BigBlueButton-Besprechung beendet wird, kann die Aufzeichnung oder, bei älteren Installationen, die Live-Audio- und Videoübertragung unterbrechen. Das erste hilfreiche Ergebnis ist nicht nur ein erneuter Start des Dienstes, sondern auch die Kenntnis des Medien-Stacks, der die betroffene Funktion steuert, der Ressource oder des Fehlers, der dem Beenden vorausgeht, und ob die Behebung die Stabilität der nächsten vergleichbaren Besprechung gewährleistet.

Prüfen Sie zunächst die BigBlueButton-Version und die Rolle von Kurento auf diesem Server. BigBlueButton 2.5 und höher verwenden standardmäßig MediaSoup für Live-WebRTC-Medien. Kurento kann weiterhin für Aufnahmen oder aufgrund einer benutzerdefinierten Konfiguration durch einen Administrator vorhanden sein. Die Meldung „Kurento abgestürzt“ beweist daher nicht automatisch, dass KMS die überlasteten Webcams verarbeitet. Informationen zur Versionsunterscheidung finden Sie im offiziellen BigBlueButton-Leitfaden zur Fehlerbehebung . Die unten aufgeführten detaillierten KMS-Lösungen stammen aus dem versionierten BigBlueButton 2.7-Server-Anpassungsleitfaden . Prüfen Sie die Dokumentation Ihrer installierten Version, bevor Sie die Lösungen anwenden.

Zuerst prüfen, was fehlgeschlagen ist.

Sammeln Sie Beweise, bevor Sie Dienste wiederholt neu starten. Notieren Sie, wann die Benutzer das Problem erstmals bemerkten, welches Meeting betroffen war, ob Audio, Webcam, Bildschirmfreigabe oder Aufzeichnung ausfielen und ob der gesamte Server oder nur eine Medienfunktion beeinträchtigt war. Ein Neustart des Dienstes kann einen Prozess zwar vorübergehend wiederherstellen, löscht aber die zeitlichen Hinweise, die einen Absturz von einem Netzwerk- oder Clientproblem unterscheiden.

Auf dem BigBlueButton-Host beginnen Sie mit Prüfungen auf Lesezugriff:

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

Verwenden Sie den entsprechenden Unit-Namen für Release und Deployment. Wenn der Dienst in mehrere KMS-Units aufgeteilt ist, prüfen Sie die Unit und das Log auf den fehlgeschlagenen Prozess. Vergleichen Sie den Zeitstempel des systemd-Journals mit dem neuesten KMS-Log. Achten Sie auf einen expliziten Abbruch, eine Neustartschleife, eine fehlgeschlagene Medienpipeline oder eine ressourcenbezogene Meldung; eine einzelne Warnmeldung ohne zugehörigen Fehler reicht nicht aus, um die Ursache zu ermitteln.

Prüfen Sie, ob die Nutzer Kurento tatsächlich für den fehlerhaften Datenverkehr verwenden. Firefox about:webrtckann die Details der Peer-Verbindung anzeigen; Chrome bietet eine entsprechende Funktion chrome://webrtc-internals. Die Dokumentation zur Fehlerbehebung von BigBlueButton beschreibt die Überprüfung der ausgehandelten Sitzungsdetails für Mediasoup. Überprüfen Sie außerdem Ihre konfigurierten Mediendienste und Ihren Aufzeichnungs-Workflow. Wenn Live-Medien über Mediasoup laufen und die Aufzeichnung erst beim Beenden von KMS stoppt, optimieren Sie den Aufzeichnungs-/Kurento-Pfad, anstatt die Live-Webcam-Einstellungen willkürlich zu ändern.

Ermitteln Sie den Druck, der vor dem Ausgang auftritt.

„Unter Last“ kann verschiedene Engpässe bedeuten. Führen Sie Stichproben auf dem Host durch, während ein repräsentatives Meeting aktiv ist, und vergleichen Sie die Stichprobe mit der Ereigniszeit. Folgende Prüfungen sind hilfreich:

• free -hund vmstat 1für den verfügbaren Speicher, das Auslagern und den Druck auf die Ausführungswarteschlange;
• mpstat -P ALL 1zur CPU-Auslastung pro Kern, sofern die sysstatentsprechenden Tools installiert sind;
• df -hund iostat -xz 1für eine vollständige Dateisystem- oder Speicherlatenz, sofern verfügbar;
• journalctl -k --since "1 hour ago"für Kernel-Meldungen, einschließlich einer Abbruchmeldung aufgrund von Speichermangel;
• Systemd-Status und KMS-Protokolle für wiederholte Beendigungen, Pipeline-Fehler und welche Medienoperation aktiv war.

Verlassen Sie sich nicht allein auf die durchschnittliche CPU-Auslastung des Servers. Ein Medienprozess kann durch einen ausgelasteten Kern eingeschränkt sein, während andere Kerne scheinbar im Leerlauf sind. Auch Speichermangel kann zu einem Abbruch führen, ohne dass die CPU über einen längeren Zeitraum stark beansprucht wird. Umgekehrt kann die Meldung eines Benutzers über eine eingefrorene Kamera auftreten, obwohl KMS weiterhin funktioniert, weil UDP blockiert ist oder der Browser keine WebRTC-Verbindung herstellen kann. BigBlueButton beschreibt TURN als Lösung für restriktive Netzwerke. TURN kann die Konnektivität verbessern, erhöht aber nicht die Rechenkapazität von KMS. Wenn der Dienst aktiv bleibt und die Protokolle keine Ressourcenereignisse anzeigen, überprüfen Sie ICE, Firewall und Client-Konnektivität, bevor Sie die Medienlimits erhöhen.

Die Kapazität hängt von der tatsächlichen Zusammensetzung der Datenströme und der Verarbeitung ab, nicht nur von der Teilnehmerzahl. Die Anzahl der gesendeten und empfangenen Webcams, Bildschirmfreigaben, Audiositzungen, Aufzeichnungen, die vereinbarte Qualität und das Meeting-Layout spielen eine wichtige Rolle. Daher sollte ein nachhaltiges Limit anhand der Meeting-Aktivitäten der Organisation selbst ermittelt und nicht von einem externen Server übernommen werden.

Wählen Sie eine Heilmethode, die den Beweisen entspricht.

Bei einer älteren KMS-Implementierung müssen Medienworkloads getrennt werden.

Die Anpassungsanleitung für BigBlueButton 2.7 beschreibt die Verwendung von drei KMS-Prozessen: jeweils einem für die Audiowiedergabe (nur Hören), die Webcam und die Bildschirmfreigabe. Der Vorteil besteht darin, die Start- und Stoppvorgänge der Medienwiedergabe auf separate Prozesse zu verteilen und die Auswirkungen eines Prozessabsturzes zu minimieren. Die Anleitung verwendet die enableMultipleKurentosEinstellungen des BigBlueButton-Konfigurationsskripts und startet BigBlueButton anschließend neu. Befolgen Sie die Anweisungen für Ihre spezifische Version und überprüfen Sie nach dem Neustart die resultierenden Serviceeinheiten und Protokolle.

Diese Trennung dient der Ressourcenbegrenzung und -verteilung und ersetzt nicht ausreichend CPU, Arbeitsspeicher oder Speicherplatz. Sie kann außerdem den Ressourcenverbrauch erhöhen, da zusätzliche Prozesse ausgeführt werden. Planen Sie ein Wartungsfenster ein: sudo bbb-conf --restartDies unterbricht aktive Sitzungen. Bearbeiten Sie generierte Servicedateien nicht manuell und gehen Sie nicht davon aus, dass ein für Version 2.7 dokumentierter Befehl unverändert auch für neuere oder vom Hersteller modifizierte Installationen gilt.

Legen Sie Medienschwellenwerte fest, wenn der Server eine Zugriffsbegrenzung benötigt.

Bei KMS-basierten Versionen, die die dokumentierte Option unterstützen, erlaubt BigBlueButton mediaThresholdsWerte für global, perRoom, und perUser. Die Anleitung zu Version 2.7 zeigt diese in /etc/bigbluebutton/bbb-webrtc-sfu/production.ymleiner Überschreibungsdatei, die Paketaktualisierungen überstehen soll. Der Wert Null bedeutet im dokumentierten Beispiel, dass keine Begrenzung existiert. Das Erreichen eines konfigurierten Schwellenwerts kann beim Versuch eines Teilnehmers, seine Webcam freizugeben, den Fehler „Medienressourcen nicht verfügbar (2002)“ verursachen.

Wählen Sie die Werte anhand der gemessenen Kapazität und der erforderlichen Dienstqualität. Verwenden Sie das Beispiel aus der Dokumentation nicht als allgemeingültigen Grenzwert. Ein Schwellenwert macht Überlastungen besser vorhersehbar, indem er die Zuweisung weiterer Medien reduziert. Er behebt jedoch keine Abstürze, die durch einen Fehler, ein Speicherleck oder eine nicht damit zusammenhängende Betriebssystembeschränkung verursacht wurden. Überprüfen Sie die Einstellungsnamen und das Verhalten in der Dokumentation für Ihre Version, bevor Sie diese bereitstellen.

Reduzieren Sie die Mediennachfrage, bevor Sie die Kapazitätsannahmen erhöhen.

Wenn die Überwachung eine Ressourcenüberlastung anzeigt, reduzieren Sie zunächst die Spitzenlast des Dienstes. Bitten Sie Moderatoren, Webcams nur bei Bedarf einzuschalten, unnötige gleichzeitige Bildschirmfreigaben zu vermeiden oder eine sehr große interaktive Sitzung in kleinere Räume aufzuteilen, falls dies dem Lehrformat entspricht. Bei Versionen, die die unterstützte Webcam-Seitennummerierung oder Stream-Limits anzeigen, passen Sie diese über den dokumentierten Überschreibungsmechanismus an. Eine geringere Anzahl empfangener Streams kann die Serverlast reduzieren, während eine niedrigere Kameraauflösung oder Bitrate den Verarbeitungs- und Bandbreitenbedarf senken kann. Diese Änderungen gehen auf Kosten von visueller Detailgenauigkeit oder Spontaneität zugunsten der Stabilität; erläutern Sie den Meeting-Organisatoren diesen Kompromiss und stellen Sie sicher, dass das Ergebnis akzeptabel ist.

Erwägen Sie ein Upgrade oder eine Architekturänderung, wenn die Grenzwerte wieder aufgehoben werden.

Ist die installierte Version veraltet, prüfen Sie den unterstützten Upgrade-Pfad und die Medienarchitektur, bevor Sie weitere Investitionen in die KMS-Optimierung tätigen. Seit BigBlueButton 2.5 ist Mediasoup der Standard für Live-Medien, während Kurento eine andere Rolle als in älteren Versionen einnimmt. Ein anhaltender KMS-Absturz auf einem aktuellen Server kann daher auf Probleme mit der Aufzeichnung, einem benutzerdefinierten Medien-Stack oder einer bestimmten Integration hinweisen. Bei einer bestehenden Installation, die trotz sinnvoller Grenzwerte und Workload-Änderungen wiederholt an ihre Leistungsgrenze stößt, kann ein Upgrade oder eine Neugestaltung der Installation effektiver sein als die Erhöhung der Schwellenwerte. Der operative Aufwand umfasst Kompatibilitätstests, Migrationsplanung und ein Wartungsfenster.

Die Änderung sollte im Rahmen eines vergleichbaren Treffens bestätigt werden.

Ändern Sie jeweils nur eine Einstellung oder eine Arbeitslastübung und testen Sie dies anschließend in einem kontrollierten Meeting, das einer normalen Spitzenlast entspricht. Notieren Sie die BigBlueButton-Version, die Teilnehmerzahl, die ungefähre Anzahl aktiver Webcams, Bildschirmfreigaben und ob die Aufzeichnung aktiviert ist. Dies ermöglicht einen aussagekräftigen Vergleich, ohne die Teilnehmerzahl als einzige Lastvariable zu betrachten.

• Prüfen Sie, ob die betreffende KMS-Einheit aktiv bleibt und nicht in eine Neustartschleife gerät.
• Vergleichen Sie die CPU-Auslastung pro Kern, den verfügbaren Arbeitsspeicher und Auslagerungsspeicher, die Festplattenaktivität und die Protokolle vor und während des Tests.
• Überprüfen Sie Audio, Webcam, Bildschirmfreigabe und Aufzeichnung separat, je nachdem, welche Rolle Kurento tatsächlich einnimmt.
• Prüfen Sie, ob sich Fehler aus dem Jahr 2002, fehlgeschlagene Medienkonfigurationen oder Benutzerberichte ändern; keine einzelne Kennzahl beweist die Behebung des Problems.
• Wiederholen Sie den Vorgang während der erwarteten Stoßzeit, bevor Sie die Kapazitätsänderung als erfolgreich erklären.

Sollte der Dienst weiterhin abstürzen, erfassen Sie bitte das genaue KMS-Protokoll und das Journalfenster, Kernelmeldungen, die installierten BigBlueButton/Kurento-Versionen sowie die aktiven Konfigurationsüberschreibungen für den Administrator oder das Support-Team. Bleibt der Dienst hingegen stabil, können sich Benutzer aber weiterhin nicht verbinden, konzentrieren Sie die Untersuchung auf mögliche ICE-Probleme, Firewall-Regeln, die Verfügbarkeit von TURN und browserseitige WebRTC-Diagnose. Ziel ist eine stabile Medienlast mit bekannten Grenzen – nicht eine unbegrenzte Anzahl an Streams oder die Garantie, dass eine einzige Konfiguration für jeden Server geeignet ist.

Quellen und Versionshinweise

• BigBlueButton 2.7: Serveranpassung – mehrere Kurento-Prozesse, Medienschwellenwerte und zugehörige Konfiguration.
• BigBlueButton: Leitfaden zur Fehlerbehebung – Identifizierung des aktuellen Medien-Stacks, Mediasoup-Standardeinstellungen, Kurento-Hinweise und Netzwerk-Fehlerbehebung.
• BigBlueButton: Konfigurationsdateien – Anleitung zu Konfigurations- und Überschreibungsdateien.

Die Dokumentation wurde am 5. Oktober 2026 geprüft. Die oben aufgeführten detaillierten Beispiele für Kurento-Workloads und Schwellenwerte beziehen sich explizit auf die BigBlueButton 2.7-Dokumentation; überprüfen Sie die entsprechenden Versionshinweise und das Administratorhandbuch, bevor Sie Einstellungen an anderer Stelle anwenden.