Composeファイルを変更した後も、実行中のコンテナが古いメモリ制限を維持するのはなぜですか？
実行中のコンテナが古いメモリ制限を保持している場合、編集した Compose 設定がそのコンテナの実行中の cgroup に適用されていない可能性があります。
YAML を変更しただけでは既存のコンテナは変更されず、通常の再起動では同じコンテナが作成時と同じ設定で起動します。また、ハードメモリ制限と予約値、スワップ許容量、親 systemd スコープ、アプリケーションのヒープ設定を比較していることが混乱の原因になる場合もあります。Docker が変更を無視したと判断する前に、実効 cgroup 値とコンテナ ID を確認してください。
YAML を信頼するのではなく、実行中の cgroup 制限を確認する
コンテナ ID、作成時刻、Docker の inspect 出力、cgroup のバージョン、実行中のプロセスが使用しているメモリ制御ファイルを記録します。
Linux カーネルでは、memory.max が cgroup のハード制限として定義されている一方、memory.high は同じ絶対上限として機能するのではなく、メモリ回収の圧力を適用します。
実行中の cgroup に古い値が残っている場合、設定は適用されていません。新しい値が入っているのに監視結果が一致しない場合は、単位、キャッシュの計上、スワップ、アプリケーションレベルのメトリクスを確認してください。
再起動とコンテナの再作成を区別する
変更をデプロイするために使用したコマンドの前後で、コンテナ ID を比較します。コマンドが restart、up、create、NAS の UI 操作、または Docker の直接更新のいずれだったかを記録してください。
Docker の説明によると、Compose の restart は設定変更を適用しません。既存のサービスコンテナを再起動するだけだからです。
サービスを再作成する制御された Compose 更新を使用するか、適切な場合はサポートされているライブリソース更新を使用してください。変更されたフィールドを検証できるよう、変更前の inspect 出力を保存しておきます。
最終的な Compose モデルとメモリフィールドを検証する
すべてのファイル、プロファイル、環境変数の置換を適用した後、実効 Compose 設定を展開して確認します。制限がアクティブなサービスに属しているかを確認してください。
Compose 仕様では、mem_limit をサービスのメモリ制限として定義しており、同等の deploy 制限も宣言されている場合は整合性が必要です。
使用されていない override ファイル、無効なプロファイル、スペルミスのあるサービス名、または別の Stack UI に設定された値は、デプロイ済みのモデルを変更しません。展開した設定と Docker の inspect 結果を比較してください。
ハード制限、予約値、スワップを分けて考える
ハードメモリ制限、予約値またはソフト制限、スワップ制限、現在の使用量、ピーク使用量、OOM イベントを記録します。メモリに関係するすべての値を同じ上限として扱わないでください。
systemd のリソース制御ドキュメントでは、MemoryHigh と MemoryMax を区別しており、親 cgroup がサービスやコンテナに追加の制限を課せることも示しています。
予約値はハード上限と同じではないため、コンテナが予約値を超えているように見えることがあります。また、ダッシュボードによっては除外されたり、別項目として報告されたりするスワップやページキャッシュを使用することもあります。
ランタイムのヒープが独自の上限を使用していないか確認する
Java アプリケーションでは、コンテナ対応の JVM 検出、最大ヒープ、ダイレクトメモリ、メタスペース、スレッドスタック、イメージまたはアプリケーション設定から渡されるフラグを記録します。
Oracle のドキュメントでは、JVM が利用可能なメモリ制約を基にヒープサイズを決定し、MaxRAMPercentage でヒープの割合を設定できることが説明されています。
明示的な -Xmx または割合の設定が残っている場合、コンテナ制限を変更しても、アプリケーションのヒープが期待どおりにならないことがあります。また、ヒープメモリはプロセス全体のメモリ使用量ではありません。
Node.js などのアプリケーションレベルの制限を確認する
ランタイムフラグ、環境変数、ワーカー数、キャッシュ、内部メモリ目標を調べます。それらをオペレーティングシステムの制限と比較してください。
Node.js のドキュメントでは、max-old-space-size を V8 ヒープ制限として説明しています。この値は、コンテナに許可される cgroup のメモリ量が増減しても変わらない場合があります。
コンテナの制限はホストを保護するものであり、すべてのアプリケーションを自動的に調整するものではありません。ネイティブ割り当てとファイルシステムキャッシュのための余裕を残し、ランタイムの上限をコンテナの上限より低く設定してください。
1 つの変更を適用し、制御された負荷で検証する
最終的な Compose モデルを展開し、影響を受けるサービスだけを再作成して、新しいコンテナ ID と実行中の cgroup を確認します。その後、使用量と OOM イベントを監視しながら、上限を設定した負荷を実行してください。
ZimaSpace Tech & AI Hub の記事 アクティブなコンテナ制限に達したときに起こることを解説しています。この記事では、変更した制限が実際にデプロイされたことの証明に焦点を当てています。
再起動後に、展開した設定、コンテナの inspect 結果、cgroup ファイル、ランタイムのヒープ、観測された障害の境界がすべて意図したポリシーと一致すれば、問題は解決しています。
よくある質問
コンテナを再起動すると、変更した Compose のメモリ制限は適用されますか？
いいえ。通常、再起動では既存のコンテナ設定がそのまま使用されます。サービスを再作成するか、サポートされているライブ更新を使用してください。
コンテナはハードメモリ制限を一時的に超えることがありますか？
カーネルの計上やメモリ回収により、境界付近またはわずかに境界を超えた値が短時間表示されることはあります。ただし、ハード制限に達した状態で回収できない使用が続くと、cgroup の OOM 処理が発生します。
アプリケーションに古いヒープサイズが表示されるのはなぜですか？
アプリケーションのランタイムに明示的なヒープフラグが設定されているか、起動時にのみ割合を計算している可能性があります。コンテナの制限を検証した後、コンテナを再作成または再起動してください。
おすすめ商品
サポートとヒント
もっと読む
ライブTV録画の容量・保存期間・クリーンアップガイド
実際の録音を測定し、ヘッドルームを確保し、経過時間と容量の制限を組み合わせ、ストレージが満杯になる前に最も古い対象プログラムが削除されることを確認する。
データベース復元後のホームメディアメタデータ復旧ワークフロー
復元した状態を保護し、メディアの識別情報とパスを確認してから、メタデータを広範囲に変更する前に、パイロットライブラリで不足しているアートワークや一致項目を修復します。
オーディオ、ビデオ、字幕のJellyfinクライアント互換性チェックリスト
代表的なファイルを一度に1つの変数だけテストし、すべてのクライアントについて、ダイレクトプレイ、リマックス、音声変換、動画トランスコード、または失敗を記録します。
