VPS上でONLYOFFICEドキュメントサーバーのメモリ不足を修正する

まず、LinuxホストまたはONLYOFFICEコンテナがメモリ制限に達していないか確認してください。現在のONLYOFFICE Docs Community Editionのガイドラインでは、4GBのRAMと少なくとも4GBのスワップ領域を基本要件として挙げています。Dockerのトラブルシューティングページには、開いているドキュメントや同時接続ユーザー数が増えるにつれてメモリ使用量が増加するため、数十人のアクティブユーザーの場合、2～4GBのRAM使用量は正常であると記載されています。ハードウェア表では、同時接続アクティブユーザーが400人を超えるデプロイメントにはKubernetesを推奨しています。これらは参考値であり、すべてのVPSが同じ負荷を処理できることを保証するものではありません。ホストOS、他のコンテナ、ドキュメントサイズ、VPSプロバイダの制限なども影響します。

このガイドでは、Linux VPS への一般的な Docker インストールに焦点を当てています。次の 4 つの手順を順番に実行してください。ホストとコンテナの負荷を測定し、ログと forgotten-files キャッシュを確認し、回避可能な負荷を減らすか、コンテナの上限が低すぎる場合は修正し、必要な場合にのみ再起動して、通常の使用で検証します。コマンドの例では<CONTAINER_ID>、プレースホルダーとして を使用しています。 を の ID または名前に置き換えてくださいdocker ps。アクティブなユーザーがいるエディタを停止する前に、バックアップを取得し、メンテナンスをスケジュールしてください。

1. メモリ負荷が発生している箇所を確認する

最初のコマンドは、ONLYOFFICEコンテナ内ではなく、VPSホスト上で実行してください。

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 のメモリスワップ設定は、メモリとスワップの上限を組み合わせたものであるため、スワップのみと解釈しないでください。2 番目のコマンドは、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インストールガイドでは、少なくとも4GBのスワップが必要とされており、その量はホストOSによって異なると記載されています。スワップはディスクベースであり、RAMよりもはるかに低速であるため、十分な物理メモリの代わりにはなりません。スワップファイルを作成する前に、既にスワップファイルが存在しないこと、ディスクの空き容量があること、ファイルシステムとVPSプロバイダがこの方法をサポートしていることを確認してください。スワップファイルをサポートする一般的なLinuxファイルシステムの例を以下に示します。

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

既存のファイルに対してこれらのコマンドを実行しないでください/swapfile。再起動後も新しく作成されたスワップファイルを保持するには、/etc/fstab既存のエントリを確認した後で、一致するエントリを1つだけに追加してください。

/swapfile none swap sw 0 0

Dockerでコンテナのメモリ制限が低いと表示される場合は、コンテナを作成したComposeファイルまたはデプロイメントパネルを確認してください。制限を増やすか削除するには、VPSの合計RAMと、OS、データベース、統合プラットフォーム、その他のサービスで使用されているメモリを確認してください。ホストのRAMをすべてONLYOFFICEに割り当てないでください。ホスト自体がメモリを使い果たしている場合、Dockerの制限を変更しても物理メモリは増えません。VPSのサイズを変更するか、他のサービスを別のホストに移動してください。Composeはメモリ制限をサポートしていますが、設定する制限は実際のデプロイメントモードと使用可能なホストメモリと一致している必要があります。

ONLYOFFICEをNextcloudなどのサービスと並行して実行する2GBのVPSは、ベンダーが提示する4GBのRAMの基準を下回っています。4GBのVPSでも、ホストOSと統合スタックがメモリを共有する場合、メモリ不足になることがあります。そのような場合は、コンテナを繰り返し再起動するよりも、より大きなVPSまたは専用のドキュメントサーバーホストを使用する方が確実です。400人以上の同時アクティブユーザーの場合、現在のONLYOFFICEの表ではKubernetesの導入と、サイジングに関するアドバイスについてはONLYOFFICEへの問い合わせを推奨しています。これは、1つのVPSに小さなスワップファイルを追加するだけで解決できるワークロードではありません。

4. 安全に再起動し、結果を確認してください。

ユーザーが編集作業を行っている間は、やむを得ない停止がない限り、ドキュメントサーバーを再起動しないでください。ONLYOFFICEでは、編集中のすべてのユーザーがドキュメントを閉じた後にドキュメントが保存されると説明しています。計画的なコンテナ停止の前に、トラブルシューティングガイドでは以下の準備スクリプトを実行することを推奨しています。この準備には、ユーザーが切断している間、最大5分かかる場合があります。事前にユーザーに警告し、バックアップを保持し、通常のメンテナンス手順に従ってください。

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

Docker Compose を使用する場合は、Compose の設定またはコントロール パネルで永続的な変更を行い、プロジェクトの通常の再起動ワークフローを使用してください。実行中のコンテナに対する一時的な変更は、コンテナが再作成されると失われる可能性があります。ONLYOFFICE--oom-kill-disableを維持するために OOM 優先度を極端に設定しないでください。Docker は、ホストのメモリが枯渇すると VPS や他のサービスが危険にさらされる可能性があると警告しています。

VPSまたはコンテナが復旧したら、コンテナが正常な状態を維持し、エディタでテストドキュメントを開いて保存でき、ホストメモリが利用可能であり、コンテナが繰り返し再起動していないことを確認してください。代表的なビジー期間中に、ホストとコンテナの両方のメモリを監視してください。ドキュメントを閉じた後もメモリが継続的に増加したり、forgotten-filesディレクトリが肥大化したり、OOMイベントが再び発生したりする場合は、サポートのためにfree -h、、、、、および最近のログの出力を収集してください。1回の正常な再起動をswapon --show、容量が固定されている証拠とみなさないでください。docker statsdocker inspect

クイック決定ガイド

公式資料

• ONLYOFFICE Docs Community EditionのDockerシステム要件と同時ユーザーに関するガイダンス
• ONLYOFFICE DocsのDockerトラブルシューティング：メモリ使用量、忘れられたドキュメント、ログ、および安全なシャットダウン
• ONLYOFFICE Docs Community Edition Docker インストールガイド
• Dockerドキュメント：コンテナのメモリとスワップの制限
• Docker Composeサービスリソース設定