修復 BigBlueButton Kurento 媒體伺服器在高負載下崩潰的問題

在繁忙的 BigBlueButton 會議期間，Kurento 媒體伺服器 (KMS) 進程退出可能會中斷錄製，或者在較舊的版本中，中斷即時音訊和視訊。首要的有用結果並非只是重新啟動服務：而是要知道哪個媒體堆疊正在處理受影響的功能，導致退出的資源或故障是什麼，以及修復後是否能保證下一次類似的會議穩定進行。

首先確認 BigBlueButton 的版本以及 Kurento 在此伺服器上扮演的角色。 BigBlueButton 2.5 及更高版本預設使用 mediasoup 處理即時 WebRTC 媒體；Kurento 可能仍然用於錄製，或者因為管理員保留了舊版/自訂設定。因此，「Kurento 崩潰」本身並不能證明 KMS 承載了過載的網路攝影機。有關版本差異，請參閱官方BigBlueButton 故障排除指南。以下詳細的 KMS 修復方案摘自BigBlueButton 2.7 伺服器自訂指南（已按版本劃分）；在套用這些方案之前，請檢查與您已安裝版本相符的文件。

首先確認失敗的原因。

在重複重啟服務之前，請先收集證據。記錄使用者首次遇到問題的時間、受影響的會議、音訊、攝影機、螢幕分享或錄製功能是否失效，以及是整個伺服器還是只有某個媒體功能故障。重啟服務雖然可以暫時恢復進程，但同時也會抹去區分崩潰與網路或用戶端問題的關鍵時間線索。

在 BigBlueButton 主機上，首先進行唯讀檢查：

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

發布和部署時請使用相關的單元名稱。如果服務被拆分為多個 KMS 單元，請檢查失敗的程序所在的單元並記錄其日誌。將 systemd 日誌的時間戳記與最新的 KMS 日誌進行比較。尋找明確退出、重新啟動循環、失敗的媒體管道或與資源相關的訊息；僅憑一條「警告」行而沒有相應的故障訊息不足以確定原因。

確認使用者是否確實使用 Kurento 處理故障流量。在 Firefox 中，about:webrtc可以查看對等連線詳情；Chrome 提供了相關功能chrome://webrtc-internals。 BigBlueButton 的故障排除文件介紹如何檢查 mediasoup 的協商會話詳情。此外，也要檢查您配置的媒體服務和錄製工作流程。如果即時媒體正在使用 mediasoup，並且僅在 KMS 退出時錄製停止，請調整錄製/Kurento 路徑，而不是盲目地更改即時網路攝影機設定。

找到出口前的壓力。

「負載過重」可能意味著多種不同的瓶頸。在一次代表性的會議進行期間對主機進行採樣，並將採樣結果與會議實際時間進行比較。有用的檢查方法包括：

• free -h以及vmstat 1可用記憶體、交換空間和運行佇列壓力；
• mpstat -P ALL 1sysstat如果安裝了相關工具，則可以進行單核心 CPU 飽和度測試；
• df -h以及iostat -xz 1完整的檔案系統或儲存延遲（如有）。
• journalctl -k --since "1 hour ago"用於內核訊息，包括記憶體不足終止；
• systemd 狀態和 KMS 日誌，用於尋找重複退出、管道故障以及正在運行的媒體操作。

不要只依賴伺服器的平均 CPU 使用率。媒體進程可能受某個核心繁忙的限制，而其他核心卻看似空閒；或者記憶體壓力也可能在沒有長時間高 CPU 使用率的情況下觸發進程終止。反之，用戶報告的「相機卡頓」可能在 KMS 保持正常的情況下發生，原因可能是 UDP 被封鎖或瀏覽器無法建立 WebRTC 路徑。 BigBlueButton 將 TURN 文件中提到，TURN 可以解決網路受限的問題；TURN 可以改善連接性，但不會增加 KMS 的運算能力。如果服務保持運作且日誌中沒有資源事件，請在提高媒體限制之前，先檢查 ICE、防火牆和用戶端連線。

容量取決於實際的視訊串流組合和處理情況，而不僅僅是會議人數。已發布和已接收的網路攝影機數量、螢幕共享、音訊會話、錄製、協商的品質以及會議佈局都會影響容量。因此，可持續的容量限制應該根據組織自身的會議模式來衡量，而不是複製其他伺服器的模式。

選擇符合證據的治療方法

對於傳統的KMS部署，需要分離媒體工作負載。

BigBlueButton 2.7 自訂指南介紹如何運行三個 KMS 進程，分別用於監聽音訊、攝影機和螢幕共享。這樣做的好處是將媒體啟動/停止操作分散到不同的進程中，從而降低某個 KMS 進程崩潰時的影響。該指南的設定使用了 BigBlueButton 配置腳本的enableMultipleKurentos設置，然後重新啟動了 BigBlueButton。請按照適用於您目前版本的說明進行操作，並在重新啟動後檢查產生的服務單元和日誌。

這種隔離是一種控制和分散措施，不能取代充足的 CPU、記憶體或儲存空間。它還會因為運行更多進程而增加基線資源使用量。請安排維護視窗：sudo bbb-conf --restart會中斷活動會話。請勿手動編輯產生的服務文件，也不要假設 2.7 版本中記錄的命令可以直接應用於更新的或廠商修改過的版本。

當伺服器需要限制准入時，請設定媒體閾值

對於支援文件中所述選項的基於 KMS 的版本，BigBlueButton 允許mediaThresholds為`<value> global`、perRoom`<value>` 和 ` perUser<value>` 設定值。 2.7 版本指南在 `<value>` 檔案中展示了這些值/etc/bigbluebutton/bbb-webrtc-sfu/production.yml，該檔案是一個旨在在軟體包升級後仍然保留的覆蓋檔案。文件範例中的零值表示無限制。達到配置的閾值可能會導致參與者嘗試共享網路攝影機時出現「媒體資源不可用 (2002)」錯誤。

請根據實際容量和所需的服務品質選擇合適的閾值；不要直接將文件中的範例作為通用的安全限制。閾值可以透過拒絕額外的媒體來提高過載的可預測性，但它無法修復程式錯誤、記憶體洩漏或無關的作業系統限制導致的崩潰。在部署版本之前，請務必在文件中確認設定名稱和行為。

在提高容量假設之前，先降低媒體需求

當監控顯示資源飽和時，首先要降低服務的尖峰負載。例如，請主持人選擇性地開啟攝像頭，避免不必要的螢幕共享，或者如果符合教學形式，可以將大型互動會議拆分成多個房間。對於支援攝影機分頁或串流限制的版本，可以透過文件中提供的覆蓋機制進行調整。減少接收的流量數量可以降低扇出，而降低攝影機解析度或位元率則可以降低處理和頻寬需求。這些變更會犧牲一些視覺細節或即時性來換取穩定性；請向會議主持人解釋這種權衡，並確認最終體驗可以接受。

當限制復原時，考慮升級或架構變更。

如果已安裝的版本較舊，請在進一步投入 KMS 調校之前，確認支援的升級路徑和媒體架構。自 BigBlueButton 2.5 起，mediasoup 已成為即時媒體的預設媒體庫，而 Kurento 的角色與舊版本有所不同。因此，目前伺服器上持續存在的 KMS 崩潰可能指向錄製、自訂媒體堆疊或特定整合。對於在合理的限制和工作負載變化後仍反覆達到其設定上限的舊版部署，升級或重新設計部署可能比提高閾值更有效。營運成本包括相容性測試、遷移規劃和維護窗口。

在類似會議上驗證變更。

每次只更改一項設定或工作負載操作，然後使用模擬正常高峰使用量的受控會議進行測試。記錄 BigBlueButton 的釋放時間、參加人數、大致的活躍攝影機數量、螢幕共享情況以及是否啟用錄製功能。這樣可以進行有效的比較，避免將參加人數作為唯一的負荷變數。

• 確認相關的KMS單元保持活動狀態，且不會進入重新啟動循環。
• 測試前後比較每個核心的 CPU 使用率、可用記憶體和交換空間、磁碟活動以及日誌。
• 根據 Kurento 實際發揮的作用，分別驗證音訊、相機、螢幕分享和錄製功能。
• 檢查 2002 錯誤、媒體設定失敗或使用者報告是否有所改變；沒有任何指標可以證明修復成功。
• 在預計繁忙時段重複上述步驟，然後宣布產能變更成功。

如果服務仍然崩潰，請擷取完整的 KMS 日誌和日誌視窗、核心訊息、已安裝的 BigBlueButton/Kurento 版本以及管理員或支援團隊可用的設定覆蓋資訊。如果服務運作正常但使用者仍然無法連接，則應將調查重點轉移到 ICE 候選方案、防火牆規則、TURN 可用性以及瀏覽器端 WebRTC 診斷。理想的結果是實現具有明確限制的穩定媒體工作負載，而不是無限的串流數量或保證一種配置適用於所有伺服器。

來源和版本說明

• BigBlueButton 2.7：伺服器自訂— 多個 Kurento 流程、媒體閾值和相關設定。
• BigBlueButton：故障排除指南－目前媒體堆疊辨識、mediasoup 預設值、Kurento 註解和網路故障排除。
• BigBlueButton：設定檔－設定和覆蓋檔案指南。

文件已於 2026 年 10 月 5 日審核。以上 Kurento 工作負載和門檻的詳細範例與 BigBlueButton 2.7 文件明確相關；在其他地方應用設定之前，請先查看相應的版本說明和管理員指南。