Home
» AMMINISTRAZIONE DI RETE
»
Risolvere i problemi di arresto anomalo di BigBlueButton Kurento Media Server sotto carico
Risolvere i problemi di arresto anomalo di BigBlueButton Kurento Media Server sotto carico
Un processo di Kurento Media Server (KMS) che si arresta durante riunioni BigBlueButton molto trafficate può interrompere la registrazione o, nelle installazioni più vecchie, l'audio e il video in diretta. Il primo risultato utile non è semplicemente il riavvio del servizio: è sapere quale stack multimediale sta gestendo la funzionalità interessata, quale risorsa o errore precede l'arresto e se la soluzione mantiene stabile la successiva riunione comparabile.
Innanzitutto, verificate la versione di BigBlueButton e il ruolo di Kurento su questo server. BigBlueButton 2.5 e versioni successive utilizzano MediaSoup per impostazione predefinita per i contenuti multimediali WebRTC in diretta; Kurento potrebbe essere ancora presente per la registrazione o perché un amministratore ha mantenuto una configurazione precedente/personalizzata. Pertanto, il messaggio "Kurento si è bloccato" non dimostra di per sé che KMS stia gestendo le webcam sovraccariche. Consultate la guida ufficiale alla risoluzione dei problemi di BigBlueButton per la distinzione tra le versioni. Le soluzioni dettagliate per KMS riportate di seguito sono tratte dalla guida alla personalizzazione del server BigBlueButton 2.7 ; verificate la documentazione corrispondente alla versione installata prima di applicarle.
Utilizzare questa funzione sudo bbb-conf --checkper verificare la versione di BigBlueButton installata e per esaminare la configurazione prima di modificare lo stack multimediale.
Innanzitutto, accerta cosa non ha funzionato
Raccogli prove prima di riavviare ripetutamente i servizi. Registra l'ora in cui gli utenti hanno riscontrato il problema per la prima volta, la riunione interessata, se si sono verificati problemi con l'audio, la webcam, la condivisione dello schermo o la registrazione e se il problema ha interessato l'intero server o solo una singola funzionalità multimediale. Il riavvio di un servizio può ripristinare temporaneamente un processo, cancellando però gli indizi temporali che distinguono un arresto anomalo da un problema di rete o del client.
Sull'host BigBlueButton, iniziare con i controlli di sola lettura:
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
Utilizzare il nome dell'unità pertinente per il rilascio e la distribuzione. Se il servizio è suddiviso in più unità KMS, esaminare l'unità e il log per individuare il processo che ha generato l'errore. Confrontare il timestamp del journal di systemd con il log KMS più recente. Cercare un'uscita esplicita, un ciclo di riavvio, un errore nella pipeline multimediale o un messaggio relativo alle risorse; una sola riga di "avviso" senza un errore corrispondente non è sufficiente per identificare la causa.
Verifica se gli utenti utilizzano effettivamente Kurento per il traffico problematico. In Firefox, about:webrtcè possibile visualizzare i dettagli della connessione peer; Chrome offre chrome://webrtc-internals. La documentazione di risoluzione dei problemi di BigBlueButton descrive come verificare i dettagli della sessione negoziata per mediasoup. Controlla anche i servizi multimediali configurati e il flusso di lavoro di registrazione. Se i contenuti multimediali in diretta sono su mediasoup e la registrazione si interrompe solo quando KMS esce, ottimizza il percorso di registrazione/Kurento anziché modificare a caso le impostazioni della webcam in diretta.
Confronta la pressione della CPU e della memoria per il processo multimediale pertinente con il momento in cui il servizio termina; questo pannello è una visualizzazione schematica del monitor, non dati in tempo reale del server.
Individua la pressione che precede l'uscita
"Sotto carico" può significare diversi colli di bottiglia. Esegui un campionamento dell'host mentre è in corso una riunione rappresentativa e confronta il campione con il tempo dell'evento. I controlli utili includono:
free -he vmstat 1per la memoria disponibile, lo swapping e la pressione della coda di esecuzione;
mpstat -P ALL 1per la saturazione della CPU per singolo core, se gli sysstatstrumenti sono installati;
df -he iostat -xz 1per la latenza completa del filesystem o dello storage, ove disponibile;
journalctl -k --since "1 hour ago"per i messaggi del kernel, incluso un messaggio di terminazione per esaurimento della memoria;
Stato di systemd e log KMS per uscite ripetute, errori della pipeline e quale operazione multimediale era attiva.
Non affidatevi esclusivamente all'utilizzo medio della CPU del server. Un processo multimediale può essere limitato da un singolo core occupato mentre altri core risultano inattivi, oppure la pressione sulla memoria può causare un'interruzione del processo anche senza un lungo periodo di utilizzo elevato della CPU. Al contrario, la segnalazione di un utente di "fotocamera bloccata" potrebbe verificarsi anche se KMS rimane attivo, perché il protocollo UDP è bloccato o il browser non riesce a stabilire un percorso WebRTC. BigBlueButton documenta TURN come soluzione per le reti restrittive; TURN può migliorare la connettività, ma non aumenta la capacità di calcolo di KMS. Se il servizio rimane attivo e i log non mostrano eventi relativi alle risorse, verificate ICE, il firewall e la connettività del client prima di aumentare i limiti multimediali.
La capacità dipende dall'effettiva combinazione di flussi e processi di elaborazione, non solo dal numero di partecipanti alla riunione. Il numero di webcam pubblicate e ricevute, le condivisioni dello schermo, le sessioni audio, le registrazioni, la qualità negoziata e la struttura della riunione sono tutti fattori importanti. Per questo motivo, un limite sostenibile dovrebbe essere misurato in base al modello di riunione specifico dell'organizzazione, piuttosto che essere copiato da un server esterno.
Osservate contemporaneamente l'andamento di CPU, memoria, I/O del disco e rete durante una riproduzione controllata; le linee in aumento qui illustrano le categorie da monitorare, non le prestazioni misurate di BigBlueButton.
Scegliete un rimedio che corrisponda alle prove.
Per una distribuzione KMS legacy, carichi di lavoro multimediali separati
La guida alla personalizzazione di BigBlueButton 2.7 descrive l'esecuzione di tre processi KMS, uno per l'audio in sola lettura, uno per la webcam e uno per la condivisione dello schermo. Il vantaggio dichiarato è quello di distribuire l'avvio/arresto dei contenuti multimediali su processi separati e limitare l'impatto in caso di arresto anomalo di un processo KMS. La configurazione descritta nella guida utilizza le enableMultipleKurentosimpostazioni dello script di configurazione di BigBlueButton e quindi riavvia BigBlueButton. Segui le istruzioni specifiche per la tua versione e controlla le unità di servizio e i log risultanti dopo il riavvio.
Questa separazione è una misura di contenimento e distribuzione, non un sostituto di CPU, memoria o spazio di archiviazione sufficienti. Può anche aumentare l'utilizzo di base delle risorse a causa dell'esecuzione di processi aggiuntivi. Pianifica una finestra di manutenzione: sudo bbb-conf --restartinterrompe le sessioni attive. Non modificare manualmente i file di servizio generati né presumere che un comando documentato per la versione 2.7 si applichi senza modifiche a un'installazione più recente o modificata dal fornitore.
Imposta le soglie multimediali quando il server necessita di un limite di ammissione
Per le versioni basate su KMS che supportano l'opzione documentata, BigBlueButton consente mediaThresholdsvalori per global, perRoom, e perUser. La guida 2.7 li mostra in /etc/bigbluebutton/bbb-webrtc-sfu/production.yml, un file di override destinato a sopravvivere agli aggiornamenti del pacchetto. Nell'esempio documentato, zero significa nessun limite. Il raggiungimento di una soglia configurata può causare un errore "Risorse multimediali non disponibili (2002)" quando un partecipante tenta di condividere una webcam.
Scegliete i valori in base alla capacità misurata e alla qualità del servizio richiesta; non copiate l'esempio illustrativo della documentazione come limite di sicurezza universale. Una soglia rende il sovraccarico più prevedibile, rifiutando supporti aggiuntivi, ma non risolve un arresto anomalo causato da un bug, una perdita di memoria o un limite del sistema operativo non correlato. Prima di implementare la vostra versione, verificate i nomi e il comportamento delle impostazioni nella documentazione.
L'esempio di configurazione identifica solo le chiavi di soglia; selezionare i valori compatibili con la versione in base al carico misurato e alla relativa documentazione di BigBlueButton.
Ridurre la domanda di contenuti multimediali prima di aumentare le ipotesi di capacità.
Quando il monitoraggio mostra una saturazione delle risorse, innanzitutto riducete il carico di lavoro massimo richiesto al servizio. Chiedete ai moderatori di attivare le webcam in modo selettivo, evitate condivisioni dello schermo simultanee non necessarie o suddividete una sessione interattiva molto ampia in stanze più piccole, se ciò si adatta al formato didattico. Nelle versioni che supportano la paginazione o i limiti di flusso delle webcam, regolateli tramite il meccanismo di override documentato. Un numero inferiore di flussi ricevuti può ridurre il fan-out, mentre la riduzione della risoluzione o del bitrate della telecamera può ridurre la richiesta di elaborazione e di larghezza di banda. Queste modifiche comportano un compromesso tra dettaglio visivo e spontaneità a favore della stabilità; spiegate il compromesso agli organizzatori della riunione e verificate che l'esperienza risultante sia accettabile.
Valutare un aggiornamento o una modifica dell'architettura quando i limiti tornano
Se la versione installata è obsoleta, prima di investire ulteriormente nell'ottimizzazione di KMS, è necessario verificare il percorso di aggiornamento supportato e l'architettura multimediale. Dalla versione 2.5 di BigBlueButton, mediasoup è l'impostazione predefinita per i contenuti multimediali in diretta, mentre il ruolo di Kurento è diverso rispetto alle versioni precedenti. Un arresto anomalo persistente di KMS su un server corrente potrebbe quindi essere dovuto alla registrazione, a uno stack multimediale personalizzato o a una specifica integrazione. Per un'implementazione legacy che raggiunge ripetutamente il limite massimo misurato dopo aver applicato limiti ragionevoli e aver modificato il carico di lavoro, l'aggiornamento o la riprogettazione dell'implementazione potrebbero essere più efficaci rispetto all'aumento delle soglie. I costi operativi comprendono test di compatibilità, pianificazione della migrazione e una finestra di manutenzione.
Convalidare la modifica in una riunione comparabile
Modificate un'impostazione o una pratica di gestione del carico di lavoro alla volta, quindi eseguite un test utilizzando una riunione controllata che simuli il normale utilizzo di picco. Annotate la versione di BigBlueButton, il numero di partecipanti, il numero approssimativo di webcam attive, le condivisioni dello schermo e se la registrazione è abilitata. Questo permette un confronto utile senza considerare il numero di partecipanti come unica variabile di carico.
Verificare che l'unità KMS pertinente rimanga attiva e non entri in un ciclo di riavvio.
Confronta l'utilizzo della CPU per core, la memoria disponibile e lo spazio di swap, l'attività del disco e i log prima e durante il test.
Verifica separatamente le impostazioni relative ad audio, webcam, condivisione schermo e registrazione, in base al ruolo effettivamente svolto da Kurento.
Verifica se gli errori del 2002, i problemi di configurazione dei supporti o le segnalazioni degli utenti cambiano; nessun singolo parametro dimostra la soluzione.
Ripetere la procedura durante il periodo di maggiore affluenza previsto, prima di dichiarare completata con successo la modifica della capacità.
Se il servizio continua a bloccarsi, acquisire il log KMS e la finestra di journal esatti, i messaggi del kernel, le versioni di BigBlueButton/Kurento installate e le impostazioni di configurazione attive per l'amministratore o il team di supporto. Se il servizio rimane funzionante ma gli utenti non riescono ancora a connettersi, spostare l'indagine sui candidati ICE, le regole del firewall, la disponibilità di TURN e la diagnostica WebRTC lato browser. L'obiettivo è un carico di lavoro multimediale stabile con limiti ben definiti, non un numero illimitato di stream o la garanzia che una singola configurazione sia adatta a tutti i server.
Documentazione rivista il 5 ottobre 2026. Gli esempi dettagliati di carico di lavoro e soglie di Kurento sopra riportati sono esplicitamente collegati alla documentazione di BigBlueButton 2.7; verificare le note di rilascio e la guida per l'amministratore corrispondenti prima di applicare le impostazioni altrove.