無需猜測即可提高程式碼容器的記憶體上限
檢查 Docker 是否限制了 Collabora CODE 的記憶體使用,安全地提高 Compose 記憶體限制,並確認正在運行的容器已收到新的限制。
CPU 使用率過高coolwsd,尤其是來自較舊loolwsd進程的進程,並不一定意味著故障:Collabora 會建立文件處理工作進程,而開啟或編輯複雜文件會佔用 CPU 資源。首先要確定哪個進程正在消耗 CPU,然後將其與管理控制台中開啟的文件和使用者關聯起來。如果某個文件在空閒時仍然佔用一個工作進程,請在重啟任何進程之前檢查日誌和清理設定;終止工作進程可能會中斷正在進行的編輯操作。
新安裝版本使用此coolwsd名稱;舊安裝版本可能仍顯示舊名稱loolwsd。 Collabora 21.11 升級說明/etc/loolwsd/loolwsd.xml描述了從舊名稱到新名稱的一次性遷移/etc/coolwsd/coolwsd.xml。請核對主機上安裝的服務和設定名稱,不要假設每個部署都相同。
在 systemd 主機上,檢查服務,然後按 CPU 使用率列出進程:
systemctl status coolwsd
ps -eo pid,ppid,%cpu,%mem,etime,cmd --sort=-%cpu | head -n 20
如果服務名稱為 `<service_name>` loolwsd,請在 `systemctl` 指令中取代該名稱。使用 `systemctl` 指令查看一段時間內的多個讀數,top而不是將一次短暫的峰值視為持續性問題。檢查程序樹:CPU 可能被守護程序下的文件工作程序佔用,而不是被父程序本身佔用。在 Docker 中,使用 `systemctl` 指令檢查容器總資源docker stats --no-stream CONTAINER_NAME;在 Kubernetes 中,使用相關的 Pod 資源指標。這些讀數描述的是不同的範圍,因此請仔細比較主機、容器和工作進程的值。
登入 Collabora 管理控制台,查看已連線使用者、開啟的文件、資源使用情況和最近查看的圖表。 Collabora 的官方常見問題中介紹了這些監控功能。如果在開啟或轉換大型電子表格、簡報、PDF 或文件時負載上升,請觀察活動結束後負載是否下降。與實際工作負載相關的臨時負載激增需要進行容量規劃或減少工作負載;它本身並不能證明進程失控。
如果使用者關閉某個文件後,該文件仍佔用大量 CPU 資源,請確認沒有瀏覽器工作階段或整合程式仍在開啟該文件。記錄控制台中顯示的文件識別碼、進程 ID、持續時間、記憶體佔用以及文件處於活動狀態還是空閒狀態。請勿在公開的支援請求中提及個人或機密文件的名稱。

將守護程序與其子程序進行比較;最繁忙的工作進程可能不是 coolwsd 父進程。

在變更伺服器設定之前,請將 CPU 歷史記錄與活躍使用者和文件進行關聯。
對於基於軟體包的 systemd 安裝,請檢查最近的服務訊息:
journalctl -u coolwsd --since "15 minutes ago"
如果這是您系統上的服務名稱,請使用它loolwsd。尋找重複的文件載入或轉換錯誤、工作進程重新啟動以及 CPU 使用率上升前後出現的訊息。如果您的部署將日誌寫入檔案而不是系統日誌,請使用配置的日誌目標位置。對於容器,請使用運行時環境的日誌命令檢查 Collabora 容器日誌。相關位置和可用訊息因安裝方法和版本而異。
如果某個文件重複出現錯誤,則應隔離該文件的副本,並測試是否出現相同的錯誤模式。如果多個文件都出現類似錯誤,則可能表示並發或伺服器容量不足。如果日誌指向已知缺陷,請透過您安裝的官方管道更新 Collabora;請查閱您版本對應的發行說明,而不是使用不相關的變通方法。
Collabora 的設定方案per_document.max_concurrency將處理文件時使用的最大執行緒數定義為 np。目前官方的 coolwsd 配置範本也記錄了對閒置文件進行清理檢查,這些文件會超出配置的資源閾值。特定的預設值和可用欄位可能因版本而異,因此coolwsd.xml在進行任何變更之前,請檢查已安裝版本附帶的舊版配置。
降低此設定max_concurrency可能會限制單一文件的 CPU 使用量,但會降低編輯、載入或轉換速度。它並非限制使用者或文件數量。只有在將負載與單一文件的工作量關聯起來後才能更改此設置,每次只進行一項調整,並在具有代表性的工作負載下比較響應時間和 CPU 使用率。切勿在未驗證其結構和支援的設定的情況下,直接將其他版本的程式碼片段貼到生產環境中。
清理配置旨在識別已閒置一段時間的資源消耗型文檔,並在滿足相應條件時終止相關文檔程序。它並非通用的 CPU 限制器,也無法解決因活躍編輯或重複轉換而導致的 CPU 使用率過高的問題。請根據您已安裝的配置檢查其啟用狀態和閾值;過於激進的策略可能會關閉使用者仍在使用的會話。如果您的變更需要重新啟動服務,請備份配置並規劃一次受控的服務重新啟動。

將服務狀態與最近的日誌訊息進行比較,以查看 CPU 上升是否與錯誤或工作進程重新啟動同時發生。

在變更並發或清除閾值之前,請檢查已安裝版本的架構。
如果 CPU 使用率在沒有活動文件的情況下仍然很高,或者在受控重啟後仍然存在,或者伴隨反复崩潰,請收集 Collabora 版本、安裝方法、服務/容器日誌、進程樹以及經過脫敏處理的文檔詳細信息,以便提供給維護者或供應商。避免重複終止子進程:Collabora 會管理這些工作進程,手動終止可能會中斷使用者體驗,無法解決根本原因。
檢查 Docker 是否限制了 Collabora CODE 的記憶體使用,安全地提高 Compose 記憶體限制,並確認正在運行的容器已收到新的限制。
使用緊湊模式或選項卡模式和 WOPI PostMessage 控制項簡化 Collabora CODE,安全地隱藏選定的按鈕、命令和選項卡。
讓 Nginx 負責 Collabora CODE 容器的 HTTPS,正確轉送編輯 WebSocket,並在不暴露連接埠 9980 的情況下驗證公共端點。
解決 Collabora Online 中行動瀏覽器鍵盤遮擋文字的問題,提供快速解決方法,並對瀏覽器、嵌入式 WebView 和宿主頁面進行單獨檢查。
為 ONLYOFFICE 連結、會議室成員或 Docs API 會話設定列印和下載限制,然後從收件者帳戶驗證限制。
在 ONLYOFFICE Workspace 中設定備份目標、計畫、郵件覆蓋範圍和保留期限,然後驗證檔案是否已準備好進行復原。
啟動企業版 Docker Compose 堆疊,持久化其授權和數據,安全地配置 JWT,並確認編輯器已準備好整合。
使用 ONLYOFFICE JavaScript 巨集,透過安全的審閱工作流程,從指定的電子表格區域中刪除非列印字元並移除多餘的空格。
將入口網站資料從預設磁碟移至支援的雲端儲存供應商,或透過變更主機磁碟區來對應安全地遷移 Docker 資料。
確定文件伺服器使用的是 Linux 軟體包還是 Docker,僅刪除其元件,並檢查剩餘數據,避免誤刪共享服務。