修正 ONLYOFFICE 文件伺服器在 VPS 上記憶體不足的問題

首先檢查 Linux 主機或 ONLYOFFICE 容器是否達到記憶體限制。 ONLYOFFICE Docs 社群版目前的指南建議基本配置為 4 GB 記憶體和至少 4 GB 交換空間。其 Docker 故障排除頁面指出，對於數十個活躍用戶，2-4 GB 的記憶體使用量屬於正常範圍，因為記憶體使用量會隨著開啟的文件數量和並髮用戶數的增加而增加。硬體配置表建議，對於同時活躍用戶數超過 400 的部署，應使用 Kubernetes。這些只是參考值，並非保證每個 VPS 都能處理相同的負載：主機作業系統、其他容器、文件大小以及 VPS 提供者的限制也會影響負載。

本指南重點在於 Linux VPS 上常見的 Docker 安裝。請按以下四個步驟操作：測量主機和容器壓力、檢查日誌和遺忘檔案快取、降低不必要的負載或修正過低的容器容量限制，然後僅在必要時重新啟動並驗證正常使用情況。在命令範例中使用 `<id>`<CONTAINER_ID>作為佔位符；請將其替換為 `<id>` 中的 ID 或名稱docker ps。在停止具有活躍用戶的編輯器之前，請務必備份並安排維護。

1. 確認記憶壓力發生的位置。

首先在 VPS 主機上執行這些命令，而不是在 ONLYOFFICE 容器內執行：

free -h
swapon --show
docker stats --no-stream

free -h顯示可用主機記憶體和交換空間。swapon --show確認交換空間是否處於作用中狀態。在「顯示可用主機記憶體和交換空間」中docker stats，將 ONLYOFFICE 的記憶體使用量與其顯示的限制進行比較。如果主機幾乎沒有可用內存，且多個服務正在使用 RAM，則 VPS 可能配置不足。如果主機仍有剩餘內存，但 ONLYOFFICE 容器已接近更小的限制，則容器容量限制可能是直接原因。交換空間接近滿、持續交換或磁碟活動頻繁都可能導致編輯速度變慢，即使在主機終止進程之前也是如此。

同時檢查已配置的 Docker 限制：

docker inspect --format '{{.HostConfig.Memory}} {{.HostConfig.MemorySwap}}' <CONTAINER_ID>
docker inspect --format '{{.State.OOMKilled}} {{.State.ExitCode}}' <CONTAINER_ID>

第一條指令以位元組為單位列印記憶體和記憶體加交換空間的設定。記憶體限制為零通常意味著沒有明確配置容器記憶體上限；但這並不意味著 VPS 擁有無限的 RAM。 Docker 的記憶體交換空間設定是記憶體和交換空間的總和，因此不要將其理解為單獨的交換空間限制。第二條指令報告 Docker 是否記錄了容器的 OOM 終止事件及其最後的退出代碼。 Docker 將這些限制說明為 Linux 主機強制執行的控制措施，而主機範圍內的 OOM 壓力可能會影響多個容器。

2. 檢查容器日誌和 ONLYOFFICE 已知的高使用率案例

在更改設定或刪除檔案前，請先閱讀最近的日誌：

docker logs --since 1h <CONTAINER_ID>

尋找重複重新啟動、資料庫啟動錯誤以及編輯器無法使用前後出現的錯誤訊息。如果您有權限，也應檢查主機核心日誌中是否有記憶體不足事件：

sudo dmesg -T | grep -Ei 'out of memory|killed process|oom' | tail -n 30

ONLYOFFICE 的 Docker 故障排除頁面特別建議，當記憶體使用率異常高時，應檢查是否有卡住或遺忘的文件/var/lib/onlyoffice/documentserver/App_Data/cache/files/forgotten/。首先檢查目錄的大小和內容；不要盲目刪除其中的檔案。這些文件可能與系統恢復或故障排除相關。如果目錄很大或持續成長，請保留檔案和日誌，然後按照官方故障排除指南進行操作，或諮詢 ONLYOFFICE 支持，以了解您的版本可以安全清理哪些檔案。

3. 減少不必要的需求，並修正 Docker 容量過小的問題

ONLYOFFICE 的容量規劃指南中，「活躍用戶」是指在編輯器中開啟文件的用戶，包括僅查看文件的用戶。僅登入整合平台但未開啟文件的使用者不計入活躍使用者數量。請使用者關閉不使用的文件標籤頁，並避免在小型 VPS 上安排大量編輯活動。如果負載主要來自同時開啟多個大型電子表格或複雜文件，則應比較低活動量和實際峰值時的記憶體使用情況，而不是僅根據帳戶數量進行估算。

如果 VPS 停用了交換空間，新增交換空間可以為應對突發流量高峰提供短期緩衝。 ONLYOFFICE 目前的 Docker 安裝指南建議至少使用 4 GB 的交換空間，並指出具體大小取決於主機作業系統。交換空間基於磁碟，速度遠低於 RAM，因此不能取代足夠的實體記憶體。在建立交換文件之前，請檢查是否已存在交換文件，確認磁碟空間是否充足，並確認您的檔案系統和 VPS 提供者支援此方法。在支援交換檔案的典型 Linux 檔案系統中，範例如下：

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

請勿在現有交換文件上執行這些命令/swapfile。若要在重新啟動後保留新建立的交換文件，請/etc/fstab在檢查是否存在符合項目後，再新增一個符合項目：

/swapfile none swap sw 0 0

如果 Docker 顯示容器記憶體限制過低，請檢查建立容器的 Compose 檔案或部署面板。只有在檢查過 VPS 的總記憶體以及作業系統、資料庫、整合平台和其他服務所使用的記憶體後，才能增加或移除此限制。請勿將所有主機記憶體分配給 ONLYOFFICE。如果主機本身記憶體已耗盡，更改 Docker 限制不會增加實體記憶體；請調整 VPS 的配置或將其他服務移轉到其他主機。 Compose 支援記憶體限制，但配置的限制必須與實際部署模式和可用主機記憶體相符。

一台運行 ONLYOFFICE 並同時運行 Nextcloud 或其他服務的 2GB VPS 低於供應商標稱的 4GB 內存基準。即使是 4GB 記憶體的 VPS，當主機作業系統和整合堆疊共享記憶體時，也可能出現記憶體不足的情況。在這種情況下，使用更大的 VPS 或專用的文件伺服器主機比反覆重新啟動容器更可靠。對於超過 400 個並發活躍用戶，ONLYOFFICE 目前的配置建議是部署在 Kubernetes 上，並聯繫 ONLYOFFICE 獲取容量規劃方面的建議；這種工作負載無法透過在單一 VPS 上添加一個小的交換文件來解決。

4. 安全重啟，然後驗證結果

除非中斷不可避免，否則請勿在使用者正在編輯文件時重新啟動文件伺服器。 ONLYOFFICE 解釋說，文件會在所有編輯用戶關閉後才保存。在計劃內的容器停止運作之前，其故障排除指南建議使用如下所示的準備腳本；此過程可能需要長達五分鐘，期間使用者會中斷連線。請先通知用戶，保留備份，並遵循正常的維護流程。

sudo docker exec <CONTAINER_ID> documentserver-prepare4shutdown.sh
sudo docker restart <CONTAINER_ID>

如果您使用 Docker Compose，請在 Compose 配置或控制台中進行持久性更改，並使用專案的正常重新啟動流程。對正在運行的容器進行的一次性更改可能會在容器重新建立時遺失。請勿使用--oom-kill-disable過高的 OOM 優先權來維持 ONLYOFFICE 的運作；Docker 會警告說，主機記憶體耗盡可能會危及 VPS 和其他服務。

VPS 或容器恢復後，請確認容器運作狀況良好，編輯器可以開啟並儲存測試文檔，主機記憶體可用，且容器沒有重複重新啟動。在典型的繁忙時段觀察主機和容器的記憶體使用情況。如果文件關閉後記憶體持續攀升，遺忘文件目錄增大，或再次出現 OOM 事件，請收集 `<command>`、`<command>`、`<command>`、`<command>` 的輸出free -h以及swapon --show最近docker stats的docker inspect日誌以供技術支援。不要將一次成功的重啟視為容量已修復的證明。

快速決策指南

官方參考資料

• ONLYOFFICE Docs 社群版 Docker 系統需求和並髮使用者指南
• ONLYOFFICE Docs Docker 故障排除：記憶體使用情況、遺漏文件、日誌和安全關機
• ONLYOFFICE Docs 社群版 Docker 安裝指南
• Docker 文件：容器記憶體和交換空間限制
• Docker Compose 服務資源設置