防止 ONLYOFFICE 文件伺服器耗盡 VPS 內存

如果 ONLYOFFICE 文件伺服器因 VPS 記憶體不足而崩潰或重啟，請先確認記憶體不足事件，並檢查 Docker 記憶體限制是否過低。然後為工作負載提供足夠的物理內存，並僅添加交換空間作為安全緩衝；反覆重啟編輯器無法解決持續存在的容量不足問題。

1. 證明記憶體壓力是導致故障的原因

請先在 Linux VPS 上操作，而不是在 ONLYOFFICE 整合設定中操作。瀏覽器出現「文件無法載入」之類的訊息也可能是網路或身分驗證問題導致的，因此務必確認 Linux 記憶體不足 (OOM) 終止程式是否真的終止了某個進程。

透過 SSH 運行這些命令。將 `<container_name>` 替換onlyoffice-document-server為以下指令顯示的容器名稱docker ps -a：

free -h
docker ps -a
docker stats --no-stream onlyoffice-document-server
docker inspect --format '{{.State.OOMKilled}} {{.State.ExitCode}} {{.HostConfig.Memory}} {{.HostConfig.MemorySwap}}' onlyoffice-document-server

free -h顯示可用主機記憶體和交換空間。docker stats測量正在運行的容器，而 inspect 命令則報告容器的記憶體溢出終止狀態、上次退出代碼以及配置的資源限制（以位元組為單位）。非零HostConfig.Memory值表示明確設定了記憶體上限。 Docker 的記憶體統計資料可能不包含某些檔案緩存，因此應將其與主機測量結果進行比較，而不是將其視為完整的記憶體資訊。請參閱Docker 統計資訊參考文件。

如果容器已停止，docker stats則無法顯示其先前的峰值。請改用檢查內核日誌和最近的應用程式訊息：

sudo journalctl -k --since "-2 hours" | grep -Ei 'out of memory|killed process|oom'
docker logs --tail 100 onlyoffice-document-server

核心訊息中提及「記憶體不足」或「進程已終止」有助於識別相關進程。OOMKilled=true這有力地表明容器發生了記憶體不足事件，但false並不能排除宿主機核心在容器保持運作期間終止子進程的可能性。同樣，退出代碼 137 僅表示進程被 SIGKILL 訊號終止，而非終止原因。如果沒有記憶體不足的證據，請在購買更多記憶體之前，先調查日誌和連線故障。

2. 在調整其他任何設定之前，請確保VPS有足夠的記憶體。

截至 2026 年 10 月，ONLYOFFICE官方 Docker 文件伺服器的 README 文件中建議至少需要 4 GB 記憶體和至少 2 GB 的交換空間。而另一份官方一鍵安裝程式文件則指出，Docker 測試環境需要 4 GB 內存，生產環境建議至少 8 GB 內存，並且安裝程式要求至少需要 4 GB 交換空間。這些文件描述的是不同的部署場景，因此請勿將 4 GB 記憶體視為生產環境效能可靠的保證。

如果您的 VPS 只有 1-2 GB 內存，那麼升級內存套餐是解決基於 Docker 的部署問題的最可靠方案。如果它已經擁有 4 GB 內存，請檢查作業系統、資料庫、反向代理、Nextcloud 和其他容器分別佔用了多少記憶體。即使伺服器在空閒時運作良好，當多人同時開啟文件或轉換大型電子表格時，仍可能出現記憶體不足的情況。

在繁忙的主機上，使用此方法ps aux --sort=-rss | head識別佔用大量記憶體的進程，並docker stats在典型的編輯工作階段中重複此操作。為機器的其他部分預留內存，而不是將所有可用內存都分配給 ONLYOFFICE。如果持續的需求超過主機的容量，請遷移競爭服務或升級 VPS；應用程式層級的調整無法造成實體記憶體不足。

檢查是否意外設定了 Docker 記憶體上限

Docker 容器預設沒有硬性記憶體限制，但部署時可以透過 Docker--memory或 Compose 的配置設定限制mem_limit。例如，即使 8GB 主機有剩餘內存，2GB 的容器內存限制也可能導致 OOM 終止。在更改限制之前，請務必檢查實際的限制值。如果限制值過低，請根據實際測量結果和主機剩餘記憶體容量，調整原始的 Docker 運行配置或 Compose 配置，使其達到合理的值。請參閱 Docker 的資源約束文件和Compose 服務規範。

不要盲目地在共享 VPS 上設定無限記憶體分配：這可能會導致其他服務因主機層級記憶體不足 (OOM) 而被終止。此外，請檢查--memory-swapCompose 的配置memswap_limit；Docker 在該設定中會計算 RAM 和交換空間的總和。 RAM 和交換空間總限制相等實際上會停用容器的交換空間。如果您使用 Compose 管理 ONLYOFFICE，請在其 Compose 檔案中進行更改，以確保該設定在容器重建後仍然有效。

3. 如果VPS沒有交換緩衝區，則加入交換緩衝區。

交換空間可以吸收臨時的記憶體峰值，但它儲存在磁碟上，速度比 RAM 慢得多。請先檢查swapon --show並df -h /確認。以下範例使用相容的本機檔案系統（例如 ext4）為 VPS 新增一個 2 GiB 的交換文件，前提是該文件/swapfile尚不存在且服務提供者允許使用交換空間：

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show
free -h

只有在操作成功後才將新的交換文件永久保存swapon。檢查是否存在已存在的條目grep -F '/swapfile' /etc/fstab；如果不存在，則新增一次：

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

在 Btrfs、網路檔案系統和其他一些設定上建立交換檔案需要不同的處理方式。不要在已有的交換文件上執行這些命令，也不要假設它們fallocate在所有地方都能正常運作。 Linux swapon 手冊解釋了檔案系統的限制。如果 VPS 在正常的編輯負載下頻繁使用交換空間，則應優先增加內存，而不是增大交換文件的大小。

4. 在實際編輯工作負載下重新檢查伺服器。

更改 VPS 套餐或啟用交換分區通常無需編輯 ONLYOFFICE 配置。如果您變更了 Docker 部署設置，請安排維護並在套用變更時保留現有的掛載點、金鑰、憑證路徑和整合設定。 ONLYOFFICE Docker README 文件中記錄documentserver-prepare4shutdown.sh了計劃內關閉操作，並警告斷開編輯器連接可能需要幾分鐘。請勿隨意重新建立或重新啟動正在使用的文件伺服器，因為未儲存的變更可能會受到影響。

服務準備就緒後，驗證容器是否正在運行並再次檢查其記憶體：

docker ps --filter name=onlyoffice-document-server
docker stats --no-stream onlyoffice-document-server
docker inspect --format '{{.State.OOMKilled}}' onlyoffice-document-server
docker exec onlyoffice-document-server curl -fsS http://localhost:8000/info/info.json

最後一項檢查使用ONLYOFFICE 官方 Docker Compose 健康檢查中顯示的內部資訊端點；請在容器內執行此檢查，因為 VPS 上可能未公開 8000 連接埠。端點回應表示服務可用，但不一定意味著每個儲存整合或保存回調都正常運作。

確認記憶體問題已解決

透過您實際使用的 Nextcloud、ownCloud 或其他集成，重新開啟一個小文檔，然後再開啟一個具有代表性的大文檔。儲存一個無害的編輯，並在重新開啟檔案後確認該編輯是否生效。在先前觸發故障的使用期間，持續監控 `<command>`、`<command>` 和核心 OOM 日誌free -h。docker stats

成功修復意味著文件可以正常開啟和保存，記憶體使用量保持在 VPS 和容器的限制範圍內，並且沒有出現新的 OOM 錯誤。如果崩潰僅在活動較少時停止，則表示 VPS 仍然沒有足夠的記憶體空間來應對高峰使用；應根據高峰使用量調整 RAM 容量，而不是依賴持續的記憶體交換。如果 RAM 仍然可用且沒有出現新的 OOM 錯誤，但文件仍然無法打開，則應將調查重點轉移到 ONLYOFFICE 日誌、反向代理或儲存連接器，而不是進一步更改記憶體配置。