修復客戶端瀏覽器上 Jitsi Meet 的 CPU 使用率過高問題。
透過檢查視訊圖塊、相機效果、瀏覽器圖形和主機設定來診斷 Jitsi Meet 瀏覽器 CPU 峰值並降低客戶端負載。
範例場景: Morgan 使用一台舊筆記型電腦進行 Jitsi Meet 通話。當多人開啟相機時,風扇噪音增大,瀏覽器 CPU 使用率居高不下。這是一個虛構的例子,並非真實使用者的回饋或測試結果。它提供了一種實用的方法來區分可能的原因:解碼多個傳入的視訊串流、Morgan 的攝影機編碼、視訊特效,或瀏覽器和圖形處理問題。
首先確定通話中哪個環節消耗資源最多。然後每次更改一個設置,並在類似的會議條件下進行比較。即使 Jitsi 伺服器運作正常,Jitsi Meet 用戶端也可能佔用大量 CPU 資源;本指南著重於瀏覽器和設備,而非伺服器端 Videobridge 的容量。
以下螢幕截圖展示了範例控制項和複選框。控制項的特定外觀和可用性可能因 Jitsi 部署、瀏覽器和版本而異。

問題發生時,請開啟作業系統任務管理器、活動監視器或系統監視器。尋找瀏覽器進程,如果工具將瀏覽器活動拆分為標籤頁或任務,則尋找 Jitsi Meet 標籤頁。注意 CPU 使用率是持續存在,還是僅在有人加入或切換影片時短暫飆升。同時檢查是否有其他應用程式(例如螢幕錄製軟體、遊戲或影片編輯器)佔用了過多的處理器資源。
對摩根來說,這第一項檢查回答了一個有用的問題:瀏覽器是否承擔了大部分負載,還是風扇在回應其他應用程式?記錄會議規模、本地攝影機是否開啟以及特效是否啟用。這些細節有助於後續的比較。

如果條件允許,請將同一裝置在單人通話和多人通話中的表現進行比較。在多人會議中,注意隨著更多攝影機畫面顯示或切換到多圖塊佈局,CPU 使用率是否會上升。渲染和解碼多個動態視訊串流會比單一遠端視訊串流為客戶端帶來更大的負載。但這只是一個診斷線索,本身並不能作為確鑿的證據:通話規模、視訊解析度、裝置驅動程式和其他應用程式也會影響負載。
如果即使在關閉視訊特效的一對一通話中,CPU 使用率仍然居高不下,則下一步應專注於檢查本地相機、瀏覽器和圖形處理路徑。如果 CPU 使用率主要在接收大量視訊區塊時上升,則應優先檢查接收品質控制、佈局或主機策略。

開啟會議的「更多操作」選單,找到「管理視訊品質」。如果您的部署方案中顯示了品質滑桿,請選擇較低的設置,並觀察接收到的視訊畫面是否變得模糊,瀏覽器響應速度是否加快。此控制僅控制您接收的視頻,不一定會降低您自身攝影機視訊串流的解析度。
Jitsi 目前的配置指南將其描述startLastN為控制接收的參與者影片數量,並指出品質滑桿在channelLastN配置後生效。因此,不要想當然地認為每個 Jitsi 會議室都具備此控制功能,或者其行為在所有地方都完全相同。如果缺少此功能,請繼續執行其他步驟,或詢問會議管理員該部署是否支援接收品質管理。

在盡量保持通話其他部分不變的情況下,短暫關閉相機。如果效果明顯,則可能是設備負載較高,例如相機拍攝或視訊編碼。但這並不能消除解碼其他參與者影片的負擔,因此,在人多的直播間裡,設備仍然可能比較吃力。
如果視訊並非必需,請關閉攝影機。如果需要發送視頻,請改善光線並保持攝像頭穩定,以便在較低分辨率下也能獲得清晰的圖像;避免同時調整多個質量設置,因為這會使結果難以解讀。

如果啟用了模糊效果或虛擬背景,請先將其關閉以便進行簡短的比較。特效會增加本地視訊處理量,可能不太適合老舊設備。 Jitsi 配置參考文件中包含一個禁用虛擬背景的選項,但參與者是否可以切換此功能取決於網站設定。
Morgan應該在相機對比測試之後進行以下測試:首先關閉相機,然後打開相機但關閉特效。如果第二種狀態比先前的設定對筆記型電腦的負擔更小,那麼該特效就可以考慮停用。如果差異無法重現,不要斷定該特效是造成問題的原因。

關閉無關的高負載標籤頁和應用程序,然後確保您使用的是 Jitsi 部署支援的最新版本瀏覽器。 Jitsi 的瀏覽器支援頁面列出了支援的桌面瀏覽器,但支援清單可能會變更;請確認您使用的瀏覽器版本是否在支援清單中。如果問題仍然存在,請在組織策略允許的情況下,暫時停用瀏覽器擴充程序,並在乾淨的設定檔中進行測試。
硬體加速只是診斷指標,並非萬能的解決方案。在 Chrome 瀏覽器中,Google的支援指南建議關閉圖形加速並重新啟動瀏覽器作為故障排除步驟。如果您懷疑是 GPU 或驅動程式問題,請記錄原始設置,更改設置,重新啟動瀏覽器,然後再次比較結果。軟體渲染可能會將部分工作轉移回 CPU,因此如果效能下降,請恢復先前的設定。透過您常用的更新程式更新瀏覽器和顯示卡驅動程式;避免從不可信的來源安裝驅動程式。

自託管 Jitsi 部署的管理員可以在測試參與者端選項後查看視訊配置。配置參考文件會分別resolution記錄首選的本機視訊高度和視訊擷取目標constraints。例如,管理員可以在有效的配置物件中測試較低的視訊擷取目標,如下所示:
resolution: 360,
constraints: {
video: {
height: { ideal: 360, max: 360, min: 240 }
}
},
這是一個範例,並非通用的即插即用修補程式:請根據您部署所使用的 Jitsi 版本和設定確認語法和支援的選項。較低的捕捉目標值會犧牲影像細節,以換取較少的視訊資料進行處理和發送。在廣泛應用此變更之前,請在代表性裝置上測試影像品質、相機行為和用戶端 CPU 使用情況。參考文件指出,捕獲限制與此resolution設定無關。

對於使用者反映 CPU 使用率過高(尤其是在大圖塊視圖中)的管理員,請查看maxFullResolutionParticipantsJitsi 的相關文件。 Jitsi 將此選項描述為在接收到的影片從高清 (HD) 降至標清 (SD) 之前,以全解析度顯示的參與者數量。此處的配置maxFullResolutionParticipants: 4僅為範例值,並非建議所有組織都採用的設定。
此設定會影響參與者的視訊質量,應作為全站策略進行評估。請查閱當前配置文檔,了解您版本中的具體含義,逐步實施更改,並請使用者在相同大小和佈局的房間內進行比較。請勿將此設定與伺服器容量的增加混淆;它會改變客戶端接收到的視訊內容。
在相似條件下重複比較:使用相同的設備、瀏覽器、會議規模、佈局和攝影機狀態。檢查瀏覽器 CPU 使用率是否穩定,音訊是否清晰,遠端視訊是否可用,以及您自己的視訊是否仍符合會議需求。每次更改一項設定並記錄結果。如果在相機關閉、特效停用且只有少量遠端視訊的情況下,CPU 使用率仍然很高,請嘗試使用受支援的瀏覽器設定文件,並檢查系統圖形或散熱限制;這種情況表明問題可能並非僅出在 Jitsi 的某個視訊選項上,可能需要進行裝置或瀏覽器診斷。
對於客戶端問題,通常情況下,幹擾最小的解決方法是降低傳入視訊的品質(如果可用)、移除不必要的本地視訊處理,並關閉其他並行工作負載。如果問題影響到許多參與者,則自行配置變更可能會有所幫助,但這也會改變所有人的體驗。有關進階會議控制、Jitsi 配置參考和支援的瀏覽器列表,請參閱官方 Jitsi 使用者指南。有關 Chrome 加速故障排除,請遵循Google Chrome 的官方圖形加速指南。這些頁面已於 2026 年 10 月 6 日檢查;Jitsi 手冊會不時更新,因此請根據您安裝的版本驗證相關選項。
透過檢查視訊圖塊、相機效果、瀏覽器圖形和主機設定來診斷 Jitsi Meet 瀏覽器 CPU 峰值並降低客戶端負載。
使用 Jitsi Videobridge 內建的 Prometheus 端點追蹤其運作狀況、會議負載和流量,然後在 Grafana 中探索和繪製資料圖表。
為 Jitsi Meet Docker 配置自訂網域,包括 DNS、PUBLIC_URL、HTTPS、Let's Encrypt、防火牆連接埠、NAT 設定和端對端驗證。
透過檢查正確的 URL 和連接埠、代理程式路由、服務狀態、已部署的憑證和日誌,修復 SSL 續訂後 Zimbra 管理控制台的 404 錯誤。
透過檢查活動的 PHP SAPI、大小限制、註解和重新驗證設置,了解如何診斷和修復 Nextcloud 的 PHP OPcache 配置警告。
透過檢查備份、伺服器版本、SQL 模式、字元集、模式狀態和日誌,追蹤 MySQL 或 MariaDB 升級後 Kopano 資料庫遷移失敗的問題。
透過安全傳輸、使用者和群組篩選器、登入屬性以及經過測試的部署,將 Nextcloud 連接到 LDAP 或 Active Directory。
透過設定 UnifiedPush、Android 權限、電池設定和可靠的驗證測試,修復已移除 Google 的手機上的 Element Android 通知問題。
使用官方的 occ 指令清除 Nextcloud 的資料庫索引缺少警告。請先備份,預覽更改,執行修復,然後驗證結果。
透過將 OIDC 連接到 Synapse、設定確切的回呼 URL、映射使用者聲明和測試登出來設定 Element Web 的 Keycloak SSO。