Collabora Online CODEコンテナのメモリ制限を増やす方法

Collabora Online Development Edition (CODE) コンテナが負荷によって強制終了されたり、Docker のメモリ上限に近い状態で動作し続ける場合、現実的な解決策は通常、Collabora 自体の設定を変更するのではなく、コンテナの Docker メモリ制限を引き上げることです。Docker はコンテナの実行時レベルでメモリ制限を適用し、Collabora はその制限内で動作します。

このガイドでは、全体を通して明らかに架空の例を使用しています。Linux Dockerホスト上でコンテナを実行している小規模チームを想像してくださいcode。コンテナのハードメモリ制限は2 GiBで、編集作業が集中する時間帯にはその制限に近づきます。チームは、オペレーティングシステムやその他のサービスに十分なRAMを確保しつつ、4 GiBの上限をテストすることにしました。この例の数値と使用率は説明のためのものであり、実際のデプロイメントで測定された結果ではありません。

2026年10月現在、以下のコマンドは最新のDockerドキュメントに準拠しています。Collaboraの公式Dockerドキュメントでは、CODEイメージはDockerでデプロイされたCollabora Onlineオプションとして記載されています。Dockerはコンテナのリソース制限を強制するコンポーネントです。手順を環境に合わせて調整する際は、Collabora Online CODEの公式DockerドキュメントとDockerのリソース制約に関するドキュメントを参照してください。

メモリ制限を増やすと実際に何が変わるのか

Dockerのメモリ制限は、コンテナが使用できるRAMの上限です。この制限を引き上げると、コンテナがメモリ不足やメモリ不足に陥る前に、CODEに余裕が生まれます。ただし、メモリ全体を事前に確保するわけではなく、ドキュメント編集が高速化されることを保証するものでもありません。CPUの飽和、ストレージの遅延、ネットワークの状態、ドキュメントの複雑さ、同時ユーザー数、アプリケーションレベルの動作などがボトルネックとなる可能性があります。

Docker のドキュメント--memory(または-m) は、コンテナのハードメモリ制限として定義されています。Docker は--memory-swap、メモリ制限が設定されている場合に、RAM とスワップ領域の合計許容量を制御する も提供しています。スワップ領域は余裕を持たせることができますが、頻繁なスワップはパフォーマンスに影響します。オフィス編集サービスでは、スワップ領域を十分な物理メモリの代わりとして扱うことは避けてください。

ステップ1：メモリ負荷が本当の問題であることを確認する

まず、実行中のCODEコンテナを特定し、その現在のリソース使用状況を確認します。

docker ps
docker stats code

想定されるシナリオでは、コンテナが2.0 GiBの制限のうち約1.8 GiBを使用していることdocker statsが示されていますcode。これはさらに調査する理由にはなりますが、単一のスナップショットだけでは恒久的な変更を正当化するには不十分です。障害を引き起こすワークロード中の使用状況を監視し、コンテナのログを調べて終了または再起動の兆候がないか確認してください。

有用な判断基準は単純です。コンテナが設定された上限に繰り返し近づくと同時に、ユーザーがセッションの失敗、再起動、またはメモリ不足関連のイベントを目撃する場合、制限値を増やすことが妥当な次のテストとなります。メモリが上限値を十分に下回っている場合は、制限値を変更しても根本的な問題は解決しない可能性が高いです。

ステップ2：設定済みのDockerメモリ制限を読み取る

コンテナに設定されているメモリ値を直接確認します。

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

Dockerはこの値をバイト単位で報告します。例えば、21474836481バイトは2GiBに相当します。手動で変換することも、シェル演算で変換することもできます。

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

inspectの値がの場合0、Dockerは通常、コンテナに明示的なハードメモリ制限がないものとして扱います。この場合、ホストレベルのメモリ不足、別のオーケストレーター、または別の制約が実際の原因である可能性があります。Dockerは、制限が設定されていない限り、コンテナにはデフォルトでリソース制約がないと述べています。

ステップ3：既存のLinuxコンテナの制限を増やす

Dockerは、既存のコンテナのメモリ制限を変更する機能をサポートしていますdocker update。例えば、2 GiBから4 GiBへの変更の場合：

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

--memory-swapを と同じ値に設定すると、 --memoryDocker のドキュメントに記載されているメモリ スワップ ルールに従って、そのコンテナがスワップを使用できなくなります。運用ポリシーでスワップが許可されている場合は、この例をコピーするのではなく、意図的に値を選択してください。たとえば、 の--memory-swap値が大きいほど RAM 制限を超えたスワップが一部許可されますが、の値が大きいほど-1ホストの利用可能なスワップの範囲内で無制限のスワップが許可されます。

Dockerの現在のDockerコンテナ更新に関するドキュメントでは--memory、、、--memory-reservationおよび--memory-swapが更新可能な設定として挙げられています。また、Dockerはdocker update、がWindowsコンテナではサポートされていないことも指摘しています。CODEデプロイメントでは通常Linuxコンテナが使用されますが、このコマンドを他の場所で適用する場合は、その違いが重要になります。

アップデート後、設定と実行時状態の両方を確認してください。

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

変更後の割合が低下したからといって、サービスが必要とするRAMが少なくなったと解釈しないでください。割合が下がったのは、分母が大きくなったためです。重要なのは、以前はメモリ不足を引き起こしていたワークロードの下で、コンテナが安定した状態を維持できるかどうかです。

ステップ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

どれくらいのメモリを割り当てるべきですか？

CODEのインストールごとに、安全な数値は一つとして存在しません。適切な制限値は、同時エディター数、ドキュメントのサイズと複雑さ、ホストの容量、他のコンテナ、およびサービスの統合方法によって異なります。Collaboraの現在のSDKマニュアルには、マルチギガバイトのメモリ要求と制限を含む、本番環境向けのKubernetesリソース構成例が記載されていますが、これをDockerのサイジングの普遍的な公式として扱うべきではありません。

想定されるサーバーの場合、2 GiB から 4 GiB への変更は、制御された容量変更として扱うのが最適です。チームは、ホストに十分な空き RAM があり、他の重要なサービスにメモリ負荷をかけることなく、より高いピーク負荷を吸収できることを確認する必要があります。予備の RAM が少量しかないホストでは、CODE 制限を増やすと、障害がコンテナからホストに移動してしまう可能性があります。

実用的なサイズ決定プロセス

• 代表的な混雑時間帯における現在の使用量制限と最大使用量を記録してください。
• 制限を事実上無制限にするのではなく、段階的に緩やかに引き上げる。
• ホストOS、リバースプロキシ、Nextcloudなどの統合サービス、データベース、監視エージェントのための余裕を残しておいてください。
• ワークロードを繰り返し実行し、実際のメモリ消費量、コンテナの再起動、およびユーザーに表示される障害を監視してください。
• 使用量が新しい制限値に近づくにつれて増加し続ける場合は、RAMを繰り返し追加するのではなく、アプリケーションの動作を調査し、パターンとログを記録してください。

メモリ予約とスワップについてはどうでしょうか？

Dockerでは、ハードメモリ制限とソフトメモリ予約を区別しています。予約はホストが競合状態にあるときに動作に影響を与える可能性がありますが、ハード制限は絶対的な上限値として維持されます。多くのシングルホストCODE環境では、明示的なハード制限から始める方が理解しやすいでしょう。明確なホストレベルのリソース共有ポリシーがある場合にのみ、予約を追加してください。

スワップ領域には特に注意が必要です。Dockerのドキュメントによると、--memory-swap正の値に設定した場合、スワップ領域を含めた合計メモリ容量を表します。--memory=4gと の場合--memory-swap=6g、コンテナは最大4 GiBのRAMと最大2 GiBの追加スワップ領域を使用できます。これにより、状況によっては突然の障害を防ぐことができますが、スワップ領域が継続的に使用されると、対話型編集が遅くなる可能性があります。スワップ領域が増えることを前提とするのではなく、監視する方が安全です。

変更がうまくいったかどうかを確認する方法

成功とは、単に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の設定とは別物です。
• 証拠として1つのスナップショットを使用する：代表的な需要時に測定を行い、変更前と変更後の行動を比較する。

結論

Collabora Online CODEコンテナのメモリ制限を増やすには、まず既存のDocker制限が実際に達しているかどうかを確認してください。既存のLinuxコンテナの場合は、docker update --memory ...実行時に上限を変更できます。Composeで管理されているデプロイメントの場合は、mem_limitまたは一貫性のあるComposeリソース構成を使用して制限を永続化し、サービスを再作成または更新して結果を確認してください。

2GiBから4GiBへの仮想的な例は、負荷を監視し、設定された制限を確認し、意図的に制限を増やし、設定を永続化し、同じワークロードで検証するという、意思決定のループ全体を示すため有用です。このプロセスは、単に大きな数値を割り当てて問題が解決したとみなすよりも信頼性が高いと言えます。