修復客戶端瀏覽器上 Jitsi Meet 的 CPU 使用率過高問題。

範例場景: Morgan 使用一台舊筆記型電腦進行 Jitsi Meet 通話。當多人開啟相機時,風扇噪音增大,瀏覽器 CPU 使用率居高不下。這是一個虛構的例子,並非真實使用者的回饋或測試結果。它提供了一種實用的方法來區分可能的原因:解碼多個傳入的視訊串流、Morgan 的攝影機編碼、視訊特效,或瀏覽器和圖形處理問題。

首先確定通話中哪個環節消耗資源最多。然後每次更改一個設置,並在類似的會議條件下進行比較。即使 Jitsi 伺服器運作正常,Jitsi Meet 用戶端也可能佔用大量 CPU 資源;本指南著重於瀏覽器和設備,而非伺服器端 Videobridge 的容量。

以下螢幕截圖展示了範例控制項和複選框。控制項的特定外觀和可用性可能因 Jitsi 部署、瀏覽器和版本而異。

1. 檢查瀏覽器進程是否佔用 CPU

系統監視器範例顯示,Jitsi Meet 瀏覽器進程的 CPU 使用率條比附近進程的 CPU 使用率條更長。
系統監視器範例突出顯示了正在運行 Jitsi Meet 的瀏覽器進程,以便您可以將會議負載與其他應用程式分開。

問題發生時,請開啟作業系統任務管理器、活動監視器或系統監視器。尋找瀏覽器進程,如果工具將瀏覽器活動拆分為標籤頁或任務,則尋找 Jitsi Meet 標籤頁。注意 CPU 使用率是持續存在,還是僅在有人加入或切換影片時短暫飆升。同時檢查是否有其他應用程式(例如螢幕錄製軟體、遊戲或影片編輯器)佔用了過多的處理器資源。

對摩根來說,這第一項檢查回答了一個有用的問題:瀏覽器是否承擔了大部分負載,還是風扇在回應其他應用程式?記錄會議規模、本地攝影機是否開啟以及特效是否啟用。這些細節有助於後續的比較。

2. 確定傳入的視訊區塊是否為觸發因素

Jitsi 風格的瀏覽器通話介面,顯示六個參與者的視訊區塊和會議控制。
多人平鋪視圖說明了為什麼具有多個可見視訊串流的通話比簡單的佈局要求更高。

如果條件允許,請將同一裝置在單人通話和多人通話中的表現進行比較。在多人會議中,注意隨著更多攝影機畫面顯示或切換到多圖塊佈局,CPU 使用率是否會上升。渲染和解碼多個動態視訊串流會比單一遠端視訊串流為客戶端帶來更大的負載。但這只是一個診斷線索,本身並不能作為確鑿的證據:通話規模、視訊解析度、裝置驅動程式和其他應用程式也會影響負載。

如果即使在關閉視訊特效的一對一通話中,CPU 使用率仍然居高不下,則下一步應專注於檢查本地相機、瀏覽器和圖形處理路徑。如果 CPU 使用率主要在接收大量視訊區塊時上升,則應優先檢查接收品質控制、佈局或主機策略。

3. 當控制選項可用時,降低輸入影片的質量

以下是一個 Jitsi 會議選單範例,其中「管理視訊品質」已選中,並顯示了「低」、「標準」和「高」三個滑桿。
範例選單在「管理視訊品質」下顯示了低接收品質選項;可用選項取決於會議部署情況。

開啟會議的「更多操作」選單,找到「管理視訊品質」。如果您的部署方案中顯示了品質滑桿,請選擇較低的設置,並觀察接收到的視訊畫面是否變得模糊,瀏覽器響應速度是否加快。此控制僅控制您接收的視頻,不一定會降低您自身攝影機視訊串流的解析度。

Jitsi 目前的配置指南將其描述startLastN為控制接收的參與者影片數量,並指出品質滑桿在channelLastN配置後生效。因此,不要想當然地認為每個 Jitsi 會議室都具備此控制功能,或者其行為在所有地方都完全相同。如果缺少此功能,請繼續執行其他步驟,或詢問會議管理員該部署是否支援接收品質管理。

4. 單獨測試本地攝影機

一個類似 Jitsi 的會議介面,本地參與者的攝影機已關閉,而其他參與者的攝影機仍然可見。
關閉本機攝影機是快速檢查擷取和編碼您自己的視訊是否會增加系統負載的一種方法。

在盡量保持通話其他部分不變的情況下,短暫關閉相機。如果效果明顯,則可能是設備負載較高,例如相機拍攝或視訊編碼。但這並不能消除解碼其他參與者影片的負擔,因此,在人多的直播間裡,設備仍然可能比較吃力。

如果視訊並非必需,請關閉攝影機。如果需要發送視頻,請改善光線並保持攝像頭穩定,以便在較低分辨率下也能獲得清晰的圖像;避免同時調整多個質量設置,因為這會使結果難以解讀。

5. 關閉虛擬背景和其他視訊特效

Jitsi風格的視訊設定面板,“虛擬背景”欄位設定為“關閉”
視訊設定範例顯示虛擬背景設定為“關閉”,這在啟用背景效果時是一個有用的診斷資訊。

如果啟用了模糊效果或虛擬背景,請先將其關閉以便進行簡短的比較。特效會增加本地視訊處理量,可能不太適合老舊設備。 Jitsi 配置參考文件中包含一個禁用虛擬背景的選項,但參與者是否可以切換此功能取決於網站設定。

Morgan應該在相機對比測試之後進行以下測試:首先關閉相機,然後打開相機但關閉特效。如果第二種狀態比先前的設定對筆記型電腦的負擔更小,那麼該特效就可以考慮停用。如果差異無法重現,不要斷定該特效是造成問題的原因。

6. 有條不紊地檢查瀏覽器和圖形設置

Chromium 系統設定頁面,顯示「如果可用,使用圖形加速」複選框和「重新啟動」按鈕。
瀏覽器系統設定範例顯示了圖形加速選項;更改此選項需要重新啟動瀏覽器。

關閉無關的高負載標籤頁和應用程序,然後確保您使用的是 Jitsi 部署支援的最新版本瀏覽器。 Jitsi 的瀏覽器支援頁面列出了支援的桌面瀏覽器,但支援清單可能會變更;請確認您使用的瀏覽器版本是否在支援清單中。如果問題仍然存在,請在組織策略允許的情況下,暫時停用瀏覽器擴充程序,並在乾淨的設定檔中進行測試。

硬體加速只是診斷指標,並非萬能的解決方案。在 Chrome 瀏覽器中,Google的支援指南建議關閉圖形加速並重新啟動瀏覽器作為故障排除步驟。如果您懷疑是 GPU 或驅動程式問題,請記錄原始設置,更改設置,重新啟動瀏覽器,然後再次比較結果。軟體渲染可能會將部分工作轉移回 CPU,因此如果效能下降,請恢復先前的設定。透過您常用的更新程式更新瀏覽器和顯示卡驅動程式;避免從不可信的來源安裝驅動程式。

7. 對於自架網站,請考慮降低相機拍攝解析度。

以下是 Jitsi config.js 程式碼片段範例,用於設定首選影片解析度和 360 像素高度限制。
範例 config.js 程式碼片段設定了本機擷取的首選和最大影片高度為 360 像素。

自託管 Jitsi 部署的管理員可以在測試參與者端選項後查看視訊配置。配置參考文件會分別resolution記錄首選的本機視訊高度和視訊擷取目標constraints。例如,管理員可以在有效的配置物件中測試較低的視訊擷取目標,如下所示:

resolution: 360,
constraints: {
  video: {
    height: { ideal: 360, max: 360, min: 240 }
  }
},

這是一個範例,並非通用的即插即用修補程式:請根據您部署所使用的 Jitsi 版本和設定確認語法和支援的選項。較低的捕捉目標值會犧牲影像細節,以換取較少的視訊資料進行處理和發送。在廣泛應用此變更之前,請在代表性裝置上測試影像品質、相機行為和用戶端 CPU 使用情況。參考文件指出,捕獲限制與此resolution設定無關。

8. 減少以全解析度播放的遠端影片數量

一個將 maxFullResolutionParticipants 設定為四個的 config.js 條目範例
範例配置條目限制了平鋪視圖中保持全接收解析度的參與者數量;所選值僅供參考。

對於使用者反映 CPU 使用率過高(尤其是在大圖塊視圖中)的管理員,請查看maxFullResolutionParticipantsJitsi 的相關文件。 Jitsi 將此選項描述為在接收到的影片從高清 (HD) 降至標清 (SD) 之前,以全解析度顯示的參與者數量。此處的配置maxFullResolutionParticipants: 4僅為範例值,並非建議所有組織都採用的設定。

此設定會影響參與者的視訊質量,應作為全站策略進行評估。請查閱當前配置文檔,了解您版本中的具體含義,逐步實施更改,並請使用者在相同大小和佈局的房間內進行比較。請勿將此設定與伺服器容量的增加混淆;它會改變客戶端接收到的視訊內容。

如何判斷修復是否有效?

在相似條件下重複比較:使用相同的設備、瀏覽器、會議規模、佈局和攝影機狀態。檢查瀏覽器 CPU 使用率是否穩定,音訊是否清晰,遠端視訊是否可用,以及您自己的視訊是否仍符合會議需求。每次更改一項設定並記錄結果。如果在相機關閉、特效停用且只有少量遠端視訊的情況下,CPU 使用率仍然很高,請嘗試使用受支援的瀏覽器設定文件,並檢查系統圖形或散熱限制;這種情況表明問題可能並非僅出在 Jitsi 的某個視訊選項上,可能需要進行裝置或瀏覽器診斷。

對於客戶端問題,通常情況下,幹擾最小的解決方法是降低傳入視訊的品質(如果可用)、移除不必要的本地視訊處理,並關閉其他並行工作負載。如果問題影響到許多參與者,則自行配置變更可能會有所幫助,但這也會改變所有人的體驗。有關進階會議控制、Jitsi 配置參考和支援的瀏覽器列表,請參閱官方 Jitsi 使用者指南。有關 Chrome 加速故障排除,請遵循Google Chrome 的官方圖形加速指南。這些頁面已於 2026 年 10 月 6 日檢查;Jitsi 手冊會不時更新,因此請根據您安裝的版本驗證相關選項。

留下評論

修復客戶端瀏覽器上 Jitsi Meet 的 CPU 使用率過高問題。

修復客戶端瀏覽器上 Jitsi Meet 的 CPU 使用率過高問題。

透過檢查視訊圖塊、相機效果、瀏覽器圖形和主機設定來診斷 Jitsi Meet 瀏覽器 CPU 峰值並降低客戶端負載。

如何使用 Prometheus 和 Grafana 監控 Jitsi Videobridge 指標

如何使用 Prometheus 和 Grafana 監控 Jitsi Videobridge 指標

使用 Jitsi Videobridge 內建的 Prometheus 端點追蹤其運作狀況、會議負載和流量,然後在 Grafana 中探索和繪製資料圖表。

如何為 Jitsi Meet Docker 配置自訂域名

如何為 Jitsi Meet Docker 配置自訂域名

為 Jitsi Meet Docker 配置自訂網域,包括 DNS、PUBLIC_URL、HTTPS、Let's Encrypt、防火牆連接埠、NAT 設定和端對端驗證。

修正 SSL 續期後 Zimbra 管理控制台 404 未找到錯誤

修正 SSL 續期後 Zimbra 管理控制台 404 未找到錯誤

透過檢查正確的 URL 和連接埠、代理程式路由、服務狀態、已部署的憑證和日誌,修復 SSL 續訂後 Zimbra 管理控制台的 404 錯誤。

修復 Nextcloud 警告“PHP OPcache 配置不正確”

修復 Nextcloud 警告“PHP OPcache 配置不正確”

透過檢查活動的 PHP SAPI、大小限制、註解和重新驗證設置,了解如何診斷和修復 Nextcloud 的 PHP OPcache 配置警告。

修復 MySQL 版本升級後 Kopano 資料庫遷移錯誤

修復 MySQL 版本升級後 Kopano 資料庫遷移錯誤

透過檢查備份、伺服器版本、SQL 模式、字元集、模式狀態和日誌,追蹤 MySQL 或 MariaDB 升級後 Kopano 資料庫遷移失敗的問題。

如何在 Nextcloud 中設定 LDAP 和 Active Directory 驗證

如何在 Nextcloud 中設定 LDAP 和 Active Directory 驗證

透過安全傳輸、使用者和群組篩選器、登入屬性以及經過測試的部署,將 Nextcloud 連接到 LDAP 或 Active Directory。

修復 Android Element 通知(無需 Google 服務):UnifiedPush 指南

修復 Android Element 通知(無需 Google 服務):UnifiedPush 指南

透過設定 UnifiedPush、Android 權限、電池設定和可靠的驗證測試,修復已移除 Google 的手機上的 Element Android 通知問題。

修復 Nextcloud “資料庫缺少某些索引”警告

修復 Nextcloud “資料庫缺少某些索引”警告

使用官方的 occ 指令清除 Nextcloud 的資料庫索引缺少警告。請先備份,預覽更改,執行修復,然後驗證結果。

如何在 Element Web 中設定 Keycloak 單一登入 (SSO)

如何在 Element Web 中設定 Keycloak 單一登入 (SSO)

透過將 OIDC 連接到 Synapse、設定確切的回呼 URL、映射使用者聲明和測試登出來設定 Element Web 的 Keycloak SSO。