ONLYOFFICEドキュメントサーバーがVPSメモリ不足にならないようにする

ONLYOFFICE Document ServerがVPSのメモリ不足でクラッシュまたは再起動する場合は、まずメモリ不足が発生していることを確認し、Dockerのメモリ制限が不足していないか確認してください。次に、ワークロードに必要な物理RAMを確保し、スワップ領域は安全バッファとしてのみ追加してください。エディタを繰り返し再起動しても、根本的な容量不足は解消されません。

1. メモリ負荷が障害の原因であることを証明してください。

ONLYOFFICEの統合設定ではなく、Linux VPS上で開始してください。「ドキュメントを読み込めません」などのブラウザメッセージは、ネットワークや認証の問題によっても発生する可能性があるため、Linuxのメモリ不足（OOM）キラーが実際にプロセスを終了させたかどうかを確認することが重要です。

SSH経由でこれらのコマンドを実行してください。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ホストの利用可能な RAM とスワップを表示します。 はdocker stats実行中のコンテナを測定しますが、inspect コマンドはコンテナの OOM キル状態、最後の終了コード、および設定されたリソース制限をバイト単位で報告します。ゼロ以外の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による終了を示すだけで、その原因を示すものではありません。メモリ不足の証拠がない場合は、RAMを増設する前にログと接続エラーを調査してください。

2. 他の設定を行う前に、VPSに十分なRAMを割り当ててください。

2026年10月現在、ONLYOFFICEの公式DockerドキュメントサーバーのREADMEには、推奨要件として4GB以上のRAMと2GB以上のスワップ領域が記載されています。一方、公式ワンクリックインストーラーのドキュメントでは、Dockerテスト環境向けに4GBのRAM、本番環境向けに8GB以上のRAMを推奨し、インストーラーの要件として4GB以上のスワップ領域を指定しています。これらのドキュメントは異なる導入環境を想定しているため、4GBという容量は本番環境での安定したパフォーマンスを保証するものではありません。

VPSのRAMが1～2GBしかない場合は、プランをアップグレードするのがDockerベースのインストール環境における最も確実な解決策です。すでに4GB搭載している場合は、オペレーティングシステム、データベース、リバースプロキシ、Nextcloud、その他のコンテナがどれだけのRAMを消費しているかを確認してください。アイドル状態では余裕があるように見えるサーバーでも、複数のユーザーが同時にドキュメントを開いたり、大きなスプレッドシートを変換したりすると、メモリ不足に陥る可能性があります。

負荷の高いホストでは、ps aux --sort=-rss | headメモリを大量に消費するプロセスを特定するためにこのツールを使用し、docker stats代表的な編集セッション中に繰り返し実行してください。利用可能なすべてのRAMをONLYOFFICEに割り当てるのではなく、マシンの残りの部分に余裕を持たせてください。継続的な需要がホストの容量を超える場合は、競合するサービスを移動するか、VPSをアップグレードしてください。アプリケーションレベルの調整では、不足している物理メモリを補うことはできません。

意図せずDockerのメモリ上限に達していないか確認してください。

Dockerコンテナにはデフォルトではメモリ制限はありませんが、デプロイメントでDocker--memoryまたはComposeの`Docker Compose`を使用して制限を設定できますmem_limit。たとえば、2GBのコンテナ制限は、8GBのホストに空きRAMがあってもOOMキルを引き起こす可能性があります。制限を変更する前に、実際の制限を確認してください。制限が不必要に低い場合は、測定値とホストの残りの容量に基づいて妥当な値に、元のDocker実行またはCompose構成を調整してください。Dockerのリソース制約に関するドキュメントとComposeサービスの仕様を参照してください。

共有VPSで無制限のメモリ割り当てを安易に設定しないでください。ホスト全体のOOMキルによって他のサービスが危険にさらされる可能性があります。また、--memory-swapComposeの設定も確認してくださいmemswap_limit。Dockerはこの設定でRAMとスワップの合計をカウントします。RAMと合計制限が同じであれば、コンテナのスワップは事実上無効になります。ONLYOFFICEをComposeで管理している場合は、コンテナの再作成後も設定が維持されるように、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が頻繁にスワップする場合は、スワップファイルを大きくするよりも、RAMを増やすことを優先してください。

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 ヘルスチェックに示されている内部情報エンドポイントを使用します。ポート 8000 が VPS 上で公開されていない可能性があるため、コンテナ内で実行してください。エンドポイントが応答することは、サービスの可用性を示すものであり、すべてのストレージ統合や保存コールバックが正常に機能することを意味するものではありません。

メモリの問題が解決されたことを確認してください。

実際の Nextcloud、ownCloud、またはその他の統合ツールを使って、小さなドキュメントを開き、次に代表的な大きなドキュメントを 1 つ開きます。無害な編集を保存し、ファイルを再度開いた後にその編集内容が表示されることを確認します。以前に障害が発生した使用期間中はfree -h、カーネルの OOM ログ、および を監視し続けます。docker stats

修正が成功した場合、通常のドキュメントの開閉と保存が引き続き行われ、メモリ使用量がVPSとコンテナの制限内に収まり、新たなOOMエラーが発生しなくなります。アクティビティが少ないときにのみクラッシュが停止する場合は、VPSにピーク時の使用に対する余裕がまだありません。継続的なスワッピングに頼るのではなく、ピーク時に合わせてRAMのサイズを調整してください。RAMに余裕があり、新たなOOMメッセージが発生しないにもかかわらずドキュメントの読み込みが失敗する場合は、メモリの変更を続けるのではなく、調査対象をONLYOFFICEログ、リバースプロキシ、またはストレージコネクタに切り替えてください。