推測せずにCODEコンテナのメモリ上限を引き上げる

Collabora Online CODEコンテナにメモリを増やすには、コンテナを作成する構成でDockerの制限値を引き上げ、コンテナを再作成して、docker inspectまたはを使用して有効な制限値を確認しますdocker stats。アプリケーション設定を増やしてもDockerのコンテナの上限値は上がりません。また、ホストまたはDocker Desktop仮想マシンには、より高い制限値に対応できるだけの十分なメモリが確保されている必要があります。

以下では、架空の例を使用します。ライリーは、単一ホストのDocker Composeデプロイメントを管理しています。docker stats複数のドキュメントを開いている状態で、2 GiBの上限が設定され、使用量がその上限に近いとします。ライリーは、4 GiBの上限を検討しています。これらの数値はあくまで例であり、Collaboraのサイジング推奨事項、パフォーマンスに関する主張、またはテスト結果ではありません。実際の制限値は、負荷とホストの容量に基づいて決定する必要があります。

1. 容器が実際に蓋に当たっていることを確認してください。

以下のコマンドをDockerホスト上で実行してください。`<コンテナ名>`はcollabora実際のコンテナ名に置き換えてください。

docker stats --no-stream collabora
docker inspect --format 'Memory={{.HostConfig.Memory}} OOMKilled={{.State.OOMKilled}}' collabora

docker stats現在の使用状況とコンテナの制限が表示されます。inspect の出力では、設定されたメモリ制限がバイト単位で報告され、Docker がコンテナを OOM キルとして記録しているかどうかも報告されます。inspect の値が の場合0、Docker はそのコンテナに対して明示的なハード制限を設定していないことを意味します。マシンに無制限の RAM があるという意味ではありません。高い値だけではメモリ不足イベントの証拠にはならないため、再起動履歴、ログ、およびユーザーが障害を確認した時刻と比較してください。

上限を増やす前に、オペレーティングシステムやその他のサービスにどれだけのRAMが残っているかを確認してください。Dockerのリソースガイダンスでは、アプリケーションの要求をテストし、十分なリソースを備えたホストでコンテナを実行することを推奨しています。Docker Desktopでは、[設定] > [リソース]も確認してください。Docker VMに割り当てられるメモリは、コンテナ間で共有される個別の上限です。CODEの制限をその割り当てを超えて引き上げても、物理メモリを増やすことはできません。Docker Desktopのリソース設定を参照してください。

2. Composeサービスの制限を変更する

Compose ファイル内の既存の CODE サービスを編集します。現在のイメージ タグ、ポート、環境、ボリューム、ネットワーク、および再起動ポリシーはそのまま保持し、メモリ設定のみを追加または更新します。Riley の仮説上の 4 GiB の例では次のようになります。

services:
  collabora:
    image: collabora/code:your-current-tag
    mem_limit: 4g
    # Keep the service’s existing settings below

この例では Collabora の公式CODE Docker イメージを使用します。デプロイメントですでに使用されているタグはそのままにしておいてください。mem_limitは上限値であり、予約ではありません。Docker はコンテナがその量まで使用できるようにしますが、この設定ではホスト上でその量の RAM を予約しません。Docker Compose サービスリファレンスではを定義しmem_limit、両方が存在する場合は と一致する必要があると述べていますdeploy.resources.limits.memory。デプロイメントでオーケストレーターまたはプラットフォーム管理の Compose ファイルを使用する場合は、そのプラットフォームでサポートされているリソース フィールドを使用し、重複する制限値を一貫してください。

CODE を直接 で起動した場合はdocker run、 で元のコマンドから再作成し--memory=4g、現在のオプションをすべて保持します。既存の Linux コンテナをランタイムで素早く変更するには、Docker は もサポートしていますdocker update --memory 4g <container_name>。Compose ファイルまたは元の実行コマンドを真のソースとして扱い、後で置き換えても古い cap が復元されないようにします。Dockerコンテナの更新リファレンスを参照してください。

3. コードを再作成して、保存した制限を有効にします。

アクティブなComposeファイルを含むディレクトリから、マージされた構成を検証し、CODEサービスのみを再作成します。

docker compose config
docker compose up -d --no-deps --force-recreate collabora

の代わりに、ファイルからサービス キーを使用してくださいcollabora。新しい制限を適用する前に、レンダリングされた構成を確認してください。CODE を再作成すると、そのコンテナに依存する編集セッションが一時的に中断されるため、短時間のサービス中断が許容できるときに変更をスケジュールしてください。ボリュームを削除したり、を実行したりしないでください。docker compose down -vこれらの操作はメモリ制限の変更には不要であり、他のサービスに属する永続データを削除する可能性があります。

4. 新しいコンデンサを検証し、負荷がかかった状態での動作を確認します。

サービスが復旧したら、YAMLファイルだけでなく、実際のコンテナも確認してください。

docker inspect --format 'Memory={{.HostConfig.Memory}} OOMKilled={{.State.OOMKilled}}' collabora
docker stats --no-stream collabora

例の値の場合4g、inspect の出力は約 4 GiB バイトを表し、docker stats4 GiB 付近に制限が表示されるはずです。下の画像は、説明のためにサンプル出力を使用しています。次に、デプロイメントに関係するドキュメントの種類と同時セッションのおおよその数を開きながら CODE を監視します。コンテナが実行状態を維持し、ユーザーに表示されるエラーが停止し、ホストが他のプロセス用のメモリを保持していることを確認します。

問題が続く場合

新しい制限が設定されているにもかかわらずCODEが再起動する場合は、docker inspect状態、docker logsおよびホストのカーネルまたはDockerイベントを調べて、メモリ不足の記録がないか確認してください。コンテナが正常な状態を維持しているにもかかわらず、ドキュメント処理によってクリーンアップがトリガーされる場合は、Dockerがボトルネックになっているとは限りません。Collabora独自のcoolwsd構成には、Dockerのcgroup制限とは別のメモリ管理動作があります。プロジェクトの構成テンプレートには、サーバー側の制御に関するドキュメントがあります。変更する前に、インストールされているCODEリリースの構成を確認してください。

コンテナのメモリを無制限に設定したり、メモリ不足キラーを無効にしたりして、不確実性を解消しようとしないでください。Dockerは、無制限のコンテナはホストのメモリを枯渇させ、無関係なサービスに影響を与える可能性があると警告しています。ホストに安全な余裕がない場合は、ホストまたはDocker VMの容量を追加するか、同時実行ワークロードを減らすか、作業を分散させることが真の解決策であり、利用可能なRAMの上限を超えて上限を上げるべきではありません。