如何增加 Collabora Online 程式碼容器的記憶體限制

如果 Collabora 線上開發版 (CODE) 容器在高負載下被終止，或者持續接近 Docker 記憶體上限，通常的解決方法是提高容器的 Docker 記憶體限制，而不是更改 Collabora 本身的設定。 Docker 在容器執行時間層級套用記憶體限制，Collabora 在該限制範圍內運作。

本指南通篇使用一個明確的假設範例：假設一個小型團隊code在 Linux Docker 主機上執行一個名為 `<container_name>` 的容器。此容器的記憶體硬性限制為 2 GiB，在編輯高峰期，其記憶體使用量會接近該限制。團隊決定測試 4 GiB 的記憶體上限，同時確保作業系統和其他服務有足夠的可用記憶體。本範例中的數據和使用率僅供參考，並非實際部署的測量結果。

截至 2026 年 10 月，以下命令與目前的 Docker 文件一致。 Collabora 自身的 Docker 文件將 CODE 映像標識為透過 Docker 部署的 Collabora Online 選項；Docker 是負責強制執行容器資源限制的元件。根據您的環境調整步驟時，請參閱Collabora Online CODE Docker 官方文件和 Docker資源限製文件。

提高記憶體限制究竟會改變什麼？

Docker 記憶體限制是指容器可使用的 RAM 容量上限。提高此限制可以為程式碼提供更多緩衝空間，避免容器出現記憶體壓力或記憶體不足的情況。但這並不意味著會預先分配全部內存，也不能保證文件編輯速度會提升。 CPU 飽和度、儲存延遲、網路狀況、文件複雜性、並髮用戶數以及應用程式層面的行為仍然可能成為瓶頸。

Docker 文件--memory（或-m）將記憶體限製作為容器的硬性記憶體限制。 Docker 還提供了一個--memory-swap，用於在設定記憶體限制時控制 RAM 和交換空間的總分配額度。交換空間可以提供一定的緩衝，但頻繁的交換會帶來效能損失。對於辦公室編輯服務而言，應避免將交換空間視為充足實體記憶體的替代品。

第一步：確認記憶壓力是否是真正的問題所在

首先確定正在運行的 CODE 容器，並觀察其目前的資源使用：

docker ps
docker stats code

在假設場景中，docker stats顯示code容器已使用約 1.8 GiB 的內存，而限制為 2.0 GiB。這需要進一步調查，但僅憑單一快照不足以證明進行永久性更改的必要性。應密切注意導致故障的工作負載期間的記憶體使用情況，並檢查容器日誌中是否有終止或重新啟動的跡象。

終端顯示名為 code 的 Collabora CODE 容器的 docker ps 和 docker stats 訊息，該容器即將達到 2 GiB 記憶體限制。 — 步驟 1：檢查正在執行的 CODE 容器，並觀察記憶體使用量相對於其目前限制的情況。

一個有效的決策規則很簡單：如果容器反覆接近其配置的記憶體上限，同時使用者也遇到會話失敗、重啟或記憶體溢位 (OOM) 等問題，那麼提高記憶體上限是合理的下一步嘗試。如果記憶體使用量始終遠低於上限，那麼更改記憶體上限不太可能解決根本問題。

步驟 2：讀取配置的 Docker 記憶體限制

直接檢查容器配置的記憶體值：

docker inspect code --format '{{.HostConfig.Memory}}'

Docker 以位元組為單位報告此值。例如，21474836481 位元組等於 2 GiB。您可以手動轉換，也可以使用 shell 運算進行轉換：

echo $((2147483648 / 1024 / 1024 / 1024))

終端機顯示 docker inspect HostConfig.Memory 傳回 2147483648 字節，並將其轉換為 2 GiB。 — 步驟 2：驗證 Docker 的實際記憶體限制，而不是僅從主機 RAM 推斷。

如果檢查值為 0 0，Docker 通常會將容器視為沒有明確的硬性記憶體限制。在這種情況下，主機層級的記憶體不足、其他編排器或其他限制可能是真正的原因。 Docker 聲明，除非配置了限制，否則容器預設沒有資源限制。

步驟 3：提高現有 Linux 容器的限制

Docker 支援使用以下命令更改現有容器的記憶體限制docker update。例如，假設要將記憶體限制從 2 GiB 更改為 4 GiB：

docker update --memory 4g --memory-swap 4g code

將值設定--memory-swap為與 Docker 文件中規定的記憶體交換規則相同的值，--memory會阻止該容器使用交換空間。如果您的操作策略允許交換空間，請根據實際情況選擇一個值，而不是複製此範例。例如，較大的--memory-swap值允許在 RAM 限制之外進行一些交換，而較大的值則-1允許在主機可用交換空間允許的範圍內進行無限交換。

Docker 目前的Docker 容器更新文件列出了`--update-set` --memory、 `--update- --memory-reservationset` 和--memory-swap`--update-set` 作為可更新設定。 Docker 也指出，`--update-set`docker update不支援 Windows 容器；CODE 部署通常使用 Linux 容器，但如果您在其他環境中使用該命令，則此區別至關重要。

終端機顯示 docker update 指令對程式碼容器的記憶體限制為 4g，隨後 docker stats 指令報告限制為 4 GiB。 — 步驟 3：提高運行容器限制，並立即重新檢查報告的上限。

更新後，請驗證配置和運行時狀態：

docker inspect code --format '{{.HostConfig.Memory}}'
docker stats code

不要將變更後百分比的降低解讀為服務現在需要的記憶體更少。百分比下降是因為分母變大了。真正重要的是容器在先前導致其記憶體壓力的負載下是否保持穩定。

步驟 4：在 Docker Compose 中使變更永久生效

如果容器由 Docker Compose 管理，請以 Compose 配置為準。否則，將來重新建立服務時，可能會恢復先前的限製或移除僅在執行時生效的變更。

對於現代 Docker Compose，服務等級的mem_limit屬性設定容器可以分配的記憶體量：

services:
  collabora:
    image: collabora/code
    container_name: code
    restart: unless-stopped
    mem_limit: 4g
    ports:
      - "9980:9980"

Docker Compose 服務參考文件中關於 mem_limit 的說明指出，該參數mem_limit用於配置服務容器的記憶體限制。 Compose 也支援資源限制deploy.resources.limits.memory；如果同時使用這兩種形式，Docker 指出它們的記憶體值必須保持一致。

應用程式配置：

docker compose up -d

然後驗證重新建立或重新啟動的服務：

docker inspect code --format '{{.HostConfig.Memory}}'
docker stats code

終端顯示 collabora/code 的 compose.yaml 服務，mem_limit 為 4g，docker compose up -d，以及 4 GiB Docker 記憶體驗證。 — 範例步驟 4：將新的記憶體上限儲存在 Compose 中，以便稍後重新建立容器時保留預期的設定。

應該分配多少記憶體？

對於每個 CODE 安裝，並沒有一個絕對安全的容器數量。適當的限制取決於並發編輯器數量、文件大小和複雜度、主機容量、其他容器以及服務的整合方式。 Collabora 目前的 SDK 手冊包含 Kubernetes 資源配置範例，其中包括一個面向生產環境的範例，該範例涉及數 GB 的記憶體請求和限制，但這不應被視為通用的 Docker 容量規劃公式。

對於假設的伺服器而言，從 2 GiB 增加到 4 GiB 最好視為可控的容量變更。團隊應確認主機有足夠的可用 RAM 來應對更高的峰值，而不會對其他關鍵服務造成記憶體壓力。在可用 RAM 較少的主機上，增加 CODE 限制可能會將故障從容器轉移到主機。

實用尺寸測量過程

記錄典型繁忙時段的目前限值和峰值使用量。
逐步提高限額，而不是直接放寬限額。
為主機作業系統、反向代理、Nextcloud 或其他整合服務、資料庫和監控代理程式預留空間。
重複執行工作負載，並觀察實際記憶體消耗、容器重新啟動和使用者可見的故障。
如果使用量持續成長並接近新的限制，則應調查應用程式行為、記錄模式和日誌，而不是重複添加 RAM。

記憶體預留和交換機制又如何呢？

Docker 區分了硬性記憶體限制和軟性記憶體預留。當主機資源爭用時，預留記憶體可以影響 Docker 的行為，而硬性限制則總是絕對上限。對於許多單主機 CODE 環境來說，一開始就明確設定硬性限制更容易理解。只有當您擁有清晰的主機級資源共享策略時，您才應該添加預留記憶體。

交換空間的使用需要格外謹慎。 Docker 文件解釋說，當`Switch_ --memory-swap...--memory=4g--memory-swap=6g

如何判斷改變是否奏效

成功不僅體現4 GiB在外表上docker stats。真正有意義的標誌是實際行動：

報告的配置限制與docker inspect預期值相符。
在先前造成問題的工作負載期間，貨櫃仍然位於新天花板下方。
在類似條件下，意外重新啟動或與記憶體不足相關的故障將不再發生。
Docker 主機仍保持著充足的記憶體空間，不會開始大量使用記憶體交換。
編輯工作應保持回應性，而不僅僅是避免終止。

如果容器在遠低於新限制的情況下仍然出現故障，則需要調整方向。檢查docker logs code主機核心日誌、反向代理錯誤、整合伺服器日誌以及 CPU 或 I/O 飽和度。記憶體限制只是 Collabora 部署的一個層次。

避免的常見錯誤

僅更改正在運行的容器： docker update可以解決當前的限制，但 Compose 管理的服務也應該在 Compose 檔案中進行更新。
給 CODE 分配所有主機記憶體：主機和相鄰服務需要足夠的記憶體空間。不受限制的容器可能會導致主機範圍的不穩定。
假設交換空間是空閒記憶體：交換空間比 RAM 慢，Docker 會明確警告應用程式頻繁交換記憶體會導致效能下降。
將容器記憶體與 PHP 記憶體混淆： Docker CODE 容器的限制與 Nextcloud 等應用程式使用的 PHP 設定是分開的。
以一次快照作為證據：在代表性的需求期間進行測量，並比較變化前後的行為。

結論

若要提高 Collabora Online CODE 容器的記憶體限制，首先要確認是否已達到現有的 Docker 限制。對於現有的 Linux 容器，docker update --memory ...可以在運行時更改上限。對於 Compose 管理的部署，請使用一致的 Compose 資源配置來持久化此限制mem_limit，然後重新建立或更新服務並驗證結果。

假設記憶體從 2 GiB 增加到 4 GiB 的例子很有用，因為它展示了完整的決策流程：觀察壓力、確認配置的限制、有意識地增加限制、保存配置，並在相同的工作負載下進行驗證。這個過程比簡單地分配一個較大的數值並假設問題就解決了要可靠得多。