本番サーバのメモリオーバーコミット設定を段階調整してOOMを制御する｜手順と切り戻し

OOMが「突然」起きる背景：オーバーコミットの仕組みを押さえる

Linuxカーネルはデフォルトでメモリのオーバーコミットを許可しています。プロセスがmalloc()でメモリを要求すると、カーネルは実際の空き物理メモリを確認せずに「割り当て済み」として返答し、実際に書き込みが発生した時点で初めて物理ページを充てます。これはfork+execのコピーオンライト最適化やJavaヒープの事前確保と相性が良く、多くの場面で合理的な設計です。

問題は、コミット済みのメモリ総量が物理RAMとスワップの合計を超えた瞬間に発生します。カーネルは書き込みを受け付けられないと判断し、OOMキラー（Out-Of-Memory Killer）を起動してプロセスを強制終了します。本番環境でこれが起きると、データベースや重要なデーモンが無警告で落ちるという最悪の事態につながります。

この挙動を制御するカーネルパラメータがvm.overcommit_memoryとvm.overcommit_ratioです。設定値を理解せずに「とりあえず1にして全許可」にしている本番サーバは珍しくなく、それが逆にOOM発生のリスクを高めているケースもあります。

3つのモードと選択基準

vm.overcommit_memoryは0・1・2の3値をとります。それぞれの挙動と適切な用途を整理します。

モード0（ヒューリスティック）

カーネルデフォルト値です。要求サイズが「常識的な範囲」かどうかをヒューリスティックで判定し、明らかに無理な要求だけを拒否します。通常のサーバワークロードではこれで十分ですが、判定基準がカーネルバージョンごとに変化するため、挙動の予測が難しいという欠点があります。

モード1（無制限許可）

あらゆるメモリ要求を無条件で受け付けます。Redisの公式ドキュメントや一部のMLフレームワークがこの設定を推奨するため広まっていますが、物理メモリの制約が完全に無視されるため、高負荷時にOOMが不規則に発生しやすくなります。用途を絞って使うべき設定です。

モード2（厳密な上限管理）

コミット可能な上限をswap + RAM × overcommit_ratio / 100で計算し、それを超えるmalloc()を即座に失敗させます。OOMキラーが発火する前にアプリケーション側がエラーを受け取れるため、障害の影響範囲を制御しやすくなります。データベースや金融系システムで採用が増えているモードです。

段階的な調整手順

いきなりモードを切り替えると、アプリケーションがmalloc()失敗に対処していない場合にクラッシュします。次の手順で段階的に進めてください。

ステップ1：現状の把握

まず現在のコミット状況を確認します。

cat /proc/meminfo | grep -E 'CommitLimit|Committed_AS'
sysctl vm.overcommit_memory vm.overcommit_ratio

Committed_ASがCommitLimitに近づいているほどOOMリスクが高い状態です。また、過去のOOM発生履歴はjournaldで確認できます。

journalctl -k --since "7 days ago" | grep -i "oom\|killed process"

ステップ2：overcommit_ratioを先に調整する

モード2に移行する前に、overcommit_ratioの適切な値を計算します。デフォルトは50（RAM×50%）です。スワップを含めた上限の目安として、「全ワークロードのRSS合計 × 1.2」が物理RAM＋スワップに収まる比率を逆算します。

たとえばRAM 64GB、スワップ 16GBのサーバで、常用RSSが48GBであれば：

# 目標CommitLimit = 48GB × 1.2 = 57.6GB
# CommitLimit = swap(16GB) + RAM(64GB) × ratio/100
# 57.6 = 16 + 64 × ratio/100
# ratio ≈ 65

sysctl -w vm.overcommit_ratio=65

この時点ではモード0のままなので、既存の動作には影響しません。まず比率を調整し、/proc/meminfoのCommitLimitが意図した値になっていることを確認します。

ステップ3：非ピーク時間帯にモード2へ切り替える

比率を確認できたら、アクセスが少ない時間帯にモードを切り替えます。

sysctl -w vm.overcommit_memory=2

切り替え直後はアプリケーションログを5〜10分間注視します。malloc() failedやCannot allocate memoryのエラーが出始めた場合は即座に切り戻します（後述）。問題なければ次のステップに進みます。

ステップ4：永続化

動作を確認できたら/etc/sysctl.d/配下に設定ファイルを作成して永続化します。/etc/sysctl.confへの直接書き込みは、ディストリビューションのパッケージアップデートで上書きされるリスクがあるため避けるのが現行のベストプラクティスです。

# /etc/sysctl.d/90-memory-overcommit.conf
vm.overcommit_memory = 2
vm.overcommit_ratio = 65

sysctl --system   # 全sysctl.d/*.confを再読み込み

切り戻し手順と注意点

モード2への移行後にアプリケーションが正常動作しない場合、切り戻しは即時に行えます。

sysctl -w vm.overcommit_memory=0
# 永続化ファイルも同時に削除または修正
rm /etc/sysctl.d/90-memory-overcommit.conf

切り戻しは実行中のプロセスには即時反映されます。ただし、モード2への移行中にmalloc()失敗でクラッシュしたプロセスは自動復旧しないため、systemdのサービスユニットによる自動再起動（Restart=on-failure）が設定されているかどうかをあらかじめ確認しておくことが重要です。

また、overcommit_ratioを低く設定しすぎると、起動時のmalloc()が失敗してサービスが立ち上がらなくなるケースがあります。特にJava系アプリケーションは起動時に大量のヒープを一括コミットするため、比率の計算には起動時ピークも含めて試算する必要があります。

OOMキラーの発火を完全に防ぎたい場合は、/proc/<pid>/oom_score_adjでプロセスごとの優先度を調整する方法もあります。重要プロセスには-1000を設定することでOOMキラーの対象から外せますが、これはあくまで応急処置であり、根本的なメモリ管理の代替にはなりません。

2026年現在の環境差分：cgroupsv2とコンテナとの関係

Ubuntu 22.04以降・RHEL 9系・Debian 12以降ではcgroupsv2がデフォルトになっており、memory.maxによるコンテナ・サービス単位のハードリミットが主流の管理手段になっています。vm.overcommit_memoryはホスト全体のカーネルパラメータであるため、cgroupsv2のリミットと組み合わせることで、より細粒度な制御が可能です。

systemdのサービスユニットではMemoryMax=やMemoryHigh=ディレクティブを使うことで、個々のサービスにcgroupsv2のメモリ上限を設定できます。MemoryHigh=は上限に近づいた時点でプロセスをスロットリングするソフトリミットで、MemoryMax=はOOMキラーを発動させるハードリミットです。この2段構えをホスト全体のオーバーコミット設定と組み合わせると、「サービスAが暴走してもサービスBは生存する」という分離を実現できます。

Kubernetes環境ではvm.overcommit_memoryの設定はノードレベルで行われます。多くのマネージドKubernetes（GKE・EKS・AKS）ではデフォルトでモード1が適用されており、Podのresources.limitsによる上限管理に委ねる設計です。オンプレミスのKubernetesクラスタを自己管理している場合は、ノードのオーバーコミット設定とPodのQoSクラス（Guaranteed/Burstable/BestEffort）の関係を意識した設計が求められます。

また、2025年末にマージされたカーネル6.13系のパッチでは、vm.overcommit_memory=2時のCommitLimit計算にHugePagesの扱いが変更されており、HugePages使用量が多い環境（データベースサーバ等）では期待と異なる上限値になる場合があります。カーネルをアップデートした後は/proc/meminfoのCommitLimitを再確認する習慣をつけておくことが、安定運用につながります。