無需猜測即可提高程式碼容器的記憶體上限

若要為 Collabora Online CODE 容器分配更多內存，請在建立該容器的配置中提高 Docker 的限制，然後重新建立容器並使用 `docker limit` 或 `docker limit` 命令確認生效的限制docker inspect。docker stats提高應用程式設定不會增加 Docker 容器的記憶體上限，主機或 Docker Desktop 虛擬機器必須有足夠的可用記憶體才能滿足更高的限制。

本文通篇使用假設範例： Riley 管理一個單主機 Docker Compose 部署。假設docker stats記憶體上限為 2 GiB，且在開啟多個文件時，記憶體使用量接近上限。 Riley 正在考慮將上限設為 4 GiB。這些數字僅為範例，並非 Collabora 的容量規劃建議、效能聲明或測試結果；您的實際限制應根據觀察到的負載和主機容量而定。

1. 確認容器確實已達到其上限。

在 Docker 主機上執行以下命令，並將 `<container_name>` 替換collabora為實際的容器名稱：

docker stats --no-stream collabora
docker inspect --format 'Memory={{.HostConfig.Memory}} OOMKilled={{.State.OOMKilled}}' collabora

docker stats顯示目前記憶體使用情況和容器限制。檢查輸出報告配置的記憶體限制（以位元組為單位），以及 Docker 是否記錄容器因記憶體不足而終止。檢查值為00 表示 Docker 沒有為此容器設定明確的硬性限制；但這並不表示機器擁有無限的記憶體。僅憑較高的讀數並不能證明發生了記憶體不足事件，因此需要將其與重啟歷史記錄、日誌以及使用者遇到故障的時間進行比較。

在提高記憶體上限之前，請檢查作業系統和其他服務剩餘的記憶體量。 Docker資源指南建議測試應用程式的需求，並在資源充足的主機上執行容器。對於 Docker Desktop，還需檢查「設定」>「資源」：分配給 Docker 虛擬機器的記憶體上限是其容器共享的獨立上限。將 CODE 的記憶體上限提高到超出此分配範圍並不能增加實體記憶體；請參閱Docker Desktop 資源設定。

2. 更改 Compose 服務限制

編輯 Compose 文件中現有的 CODE 服務。保留其目前的鏡像標籤、連接埠、環境、磁碟區、網路和重新啟動策略；僅新增或更新記憶體設定。以 Riley 假設的 4 GiB 記憶體範例為例：

services:
  collabora:
    image: collabora/code:your-current-tag
    mem_limit: 4g
    # Keep the service’s existing settings below

本範例使用 Collabora 官方的CODE Docker 映像；請保留部署中已使用的標籤。mem_limit這是一個硬性上限，而非預留：Docker 允許容器使用最多該容量，但此設定不會在主機上預留那麼多記憶體。 Docker Compose 服務參考文件對此進行了定義mem_limit，並指出如果兩者都存在，則必須保持一致deploy.resources.limits.memory。如果您的部署使用編排器或平台管理的 Compose 文件，請使用該平台支援的資源字段，並確保重複的限制值保持一致。

如果您直接使用 `docker run` 命令啟動了 CODE docker run，請使用 `docker run` 命令從原始命令重新建立它--memory=4g，並保留其所有目前選項。對於現有 Linux 容器的快速執行時間更改，Docker 也支援 `docker run` 命令docker update --memory 4g <container_name>。請將 Compose 檔案或原始運行命令視為最終依據，以避免後續替換恢復舊的配置。請參閱Docker 容器更新參考。

3. 重新建立程式碼，使已儲存的限制生效。

從包含目前 Compose 檔案的目錄中，驗證合併後的配置，然後僅重新建立 CODE 服務：

docker compose config
docker compose up -d --no-deps --force-recreate collabora

請使用文件中的服務密鑰代替collabora。在套用新限制前，請檢查渲染後的配置。重新建立程式碼會短暫中斷依賴該容器的編輯會話，因此請在可以接受短暫服務中斷的情況下安排變更。請勿刪除磁碟區或運行docker compose down -v；這些操作對於記憶體限制變更是不必要的，並且可能會刪除其他服務的持久資料。

4. 驗證新電容並檢查其在負載下的效能。

服務恢復後，要驗證實際的容器，而不僅僅是 YAML 檔案：

docker inspect --format 'Memory={{.HostConfig.Memory}} OOMKilled={{.State.OOMKilled}}' collabora
docker stats --no-stream collabora

對於範例值4g，檢查輸出應顯示約 4 GiB 字節，並docker stats顯示接近 4 GiB 的限制。下圖僅使用範例輸出進行說明。然後，在開啟與您的部署相關的文件類型和大致並發會話數時觀察程式碼。確認容器保持運行，用戶可見的錯誤停止，並且主機為其其他進程保留記憶體。

如果問題持續存在

如果新的記憶體上限已生效，但 CODE 仍然重啟，請檢查docker inspect狀態docker logs、主機核心或 Docker 事件是否有記憶體不足記錄。如果容器保持健康狀態，但文件處理仍然觸發清理，則 Docker 可能並非瓶頸所在。 Collabora 本身的coolwsd記憶體管理行為獨立於 Docker cgroup 限制；專案的設定範本中記錄了其伺服器端控制。在變更配置之前，請檢查您已安裝的 CODE 版本的配置。

不要透過將容器記憶體設定為無限製或停用記憶體溢位保護機制來解決不確定性。 Docker 警告稱，無限的容器記憶體會導致主機記憶體耗盡，並影響其他服務。如果主機沒有足夠的記憶體餘裕，真正的解決方法是增加主機或 Docker 虛擬機器的容量、減少並發工作負載或分配工作負載，而不是將記憶體上限提高到超出可用 RAM 的範圍。