Ubuntu ENOMEM (12) 解説：システム・プロセスのメモリ不足エラーの原因解析と改善策編

【注意】 Ubuntuで ENOMEM(12) が出たとき、原因が確定しないまま再起動・負荷試験・設定変更・復旧作業を繰り返すと、障害が連鎖して被害が拡大することがあります。まずはログと設定の保全、業務影響のダメージコントロール（被害最小化）を優先し、個別のシステム構成・契約・可用性要件に即した判断は、株式会社情報工学研究所の様な専門事業者に相談する事を推奨します（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983 ／ 電話：0120-838-831）。

　

第1章：またメモリ不足か…現場のため息と ENOMEM(12) の正体

「昨日まで動いてたのに、今日は ENOMEM。メモリ増設で片づく話じゃない気がする…」——この“嫌な予感”はだいたい当たります。ENOMEM(12) は単なる空きRAM不足だけでなく、プロセスの上限、コンテナの制限、アドレス空間、カーネルの割り当て方針など、“どこかの契約条件に引っかかった”ときにも同じように現れます。

ここで焦ってやりがちな行動（何度も再起動して様子を見る／監視を切って軽くする／とりあえずメモリを盛る）ほど、原因の手がかりを消したり、負荷の波を作って二次障害を誘発します。まずは「場を整える」こと、つまり再現より先に“証拠”を確保し、影響を抑え込み、判断材料を揃えるのが最短です。

冒頭30秒：まずやる“安全な初動”

• 直近のエラーログとカーネルログを退避（例：journalctl、dmesg、アプリログ）。
• 現在の制限・実行形態を記録（ulimit、systemd unit、コンテナ設定、起動引数、環境変数）。
• 負荷を増やす操作（ベンチ、全台一斉再起動、スケール操作の連打）を避け、影響範囲を固定する。
• 「復旧作業」より先に、業務継続の代替経路（縮退運転・機能制限・一時的な隔離）を検討する。

---

症状 → 取るべき行動（被害最小化のための早見表）

よくある症状	まず取るべき行動（順番が重要）	避けたい行動
アプリが突然 ENOMEM で落ちる／起動しない	ログ退避 → 実行ユーザーの ulimit 記録 → unit/コンテナ制限の確認	原因不明のままメモリ増設／再デプロイ連打
OOM Killer らしき痕跡がある（突然プロセスが消える）	dmesg/journalctl で該当時刻を特定 → kill対象と理由を確認 → cgroups上限を疑う	ログローテ・再起動で痕跡を流す
コンテナ内だけ不安定、ホストは余裕がある	cgroupsの memory.max / memory.current を確認 → 設定差分を洗い出す	ホスト側のfreeだけ見て「余裕」と断定
スレッド増加・fork失敗・mmap失敗が絡む	プロセス上限（nproc）や仮想メモリ上限（as）を確認 → 設計側の上限も点検	“たまたま”扱いで放置

---

このブログのゴールは「ENOMEMの正体を“不足”ではなく“制約の衝突”として捉え直し、再発を防ぐ設計・運用に落とし込む」ことです。ただし、現実の現場は契約・SLO・ピークトラフィック・他システム依存が絡み、一般論だけでは軟着陸できません。具体的な案件として整理する段階では、株式会社情報工学研究所のように運用と保全をセットで見られる専門家へ相談するのが、結果として最短距離になります。

　

第2章：ENOMEM が出る瞬間──malloc/alloc とカーネルの「No」の返事

アプリ側で ENOMEM を見る典型は、C/C++なら malloc/new、RustならVec拡張、Goなら大きな割り当て、Javaならネイティブ領域やDirectBuffer、Pythonなら巨大な配列確保など、“どこかで確保が失敗した”局面です。ここで重要なのは、ENOMEM は「RAMが枯れた」だけのサインではなく、カーネルが“その確保要求を満たせない（満たさない）”と判断したという事実だという点です。

ENOMEMの代表的な発生パターン

• 仮想メモリ（アドレス空間）を確保できない：mmap/munmapの繰り返しで断片化、32bitプロセスの上限、巨大連続領域が取れない等。
• リソース制限に抵触：RLIMIT_AS（仮想メモリ上限）、RLIMIT_STACK（スタック上限）、プロセス数制限、systemd/cgroupsの制限。
• コミット制御（overcommit）と整合しない：確保要求に対し、将来の実メモリ裏付けが見込めないと判断される。
• カーネル側で特定種別のメモリが不足：ページキャッシュや匿名メモリとは別に、割り当て条件（連続性、ピン留め、低メモリ領域など）で失敗する。

---

ここでよくある“勘違い”は、free -h の空きが残っているのに ENOMEM が出ると「Linuxのメモリ表示は当てにならない」と結論づけてしまうことです。実際には、表示上の空きと、プロセスが今必要としている“確保条件を満たせる空き”は別物です。特にコンテナ運用では、ホストの余裕があっても、コンテナの上限（cgroups）で確保が拒否されることがあります。

まず押さえるべき観点：ENOMEMは“どの層”で返ってきたか

アプリが errno=ENOMEM を受け取る経路は、ざっくり「ユーザー空間のランタイムが失敗した」のではなく、最後はカーネルのメモリ管理判断に行き着きます。つまり、次章の切り分けは「RAM」「swap」「上限」「アドレス空間」「コンテナ制限」「OOMの痕跡」という複数レイヤを順番に潰す作業になります。闇雲に“増やす”前に、“どの天井に頭をぶつけたか”を確定させましょう。

　

第3章：まず切り分け──本当に“物理メモリ不足”なのか、制限なのか

切り分けは、再現実験よりも先に「現場の状態を壊さずに読む」ことから始めます。具体的には、1) 事象時刻、2) 対象プロセス、3) 実行形態（ホスト/コンテナ/systemd）を揃え、そこから順に観測します。

観測の順番（壊しにくい順）

1. ログ：アプリログ、journalctl、dmesg（事象時刻の前後を中心に）。
2. 現在値：free -h / vmstat / /proc/meminfo / /proc/pressure（PSIが使える環境）。
3. 制限：ulimit -a、/etc/security/limits.conf、systemd unit、cgroups。
4. 構成差分：デプロイ差分、起動引数、環境変数、依存ライブラリ差分。

---

OOM Killerの痕跡を最優先で探す理由

「ENOMEMが出た」と同時にプロセスが消えている場合、ENOMEMを“見た”のは別プロセスで、本体はOOMにより強制終了されていることがあります。OOMは「メモリが足りない」よりも「制限やコミットの条件を満たせず、カーネルが選別してプロセスを終了させた」イベントです。dmesg/journalctl に対象プロセス名やPID、killされた旨が残ることが多く、ここが取れると原因解像度が一段上がります。

コンテナ／systemd運用なら“見えない上限”を疑う

ホストのfreeだけを見て判断すると、コンテナ内の memory.max（または類似の制限）に気づけません。systemdであれば MemoryMax などのユニット設定、Kubernetesなら requests/limits、Dockerなら --memory 等、実行形態ごとに制限の入口が変わります。ENOMEMの多くは、この入口の違いを見落としたときに長引きます。

---

「不足」か「制限」かを分けるチェックポイント

観点	不足寄りのサイン	制限寄りのサイン
ホストの状態	swap多用、kswapdが忙しい、PSIが高い、全体的に遅い	ホストは余裕、特定ワークロードだけ落ちる
対象範囲	複数サービスに波及しやすい	特定コンテナ／特定ユニットに限定
ログ	OOMが複数、メモリ圧迫の兆候が広い	unit/コンテナに紐づくkill、制限超過の痕跡
再現性	ピーク負荷・同時実行で再現	設定変更・デプロイ差分で急に出る

ここまでで「不足か／制限か」の当たりが付いたら、次は具体的な制限（ulimit、cgroups、systemd、アドレス空間）を潰し込みます。ここから先は“現場の契約条件”と直結します。たとえば、同じENOMEMでも「夜間バッチなら落としてリトライで良い」ケースと、「決済のクリティカルパスで落ちるので設計から見直す」ケースでは、採るべき改善策がまったく違います。個別判断が必要になった時点で、株式会社情報工学研究所のような専門家と一緒に整理した方が、遠回りを避けやすくなります。

　

第4章：ulimit / limits.conf の罠──意外と効いてる as / stack の話

「メモリは十分あるはずなのに ENOMEM」——このとき、真っ先に疑うべき“分かりやすい天井”が ulimit（RLIMIT系）です。特に、サービスを systemd 経由で起動していたり、ログインシェルと異なる実行ユーザーで動かしていると、開発者の想定と違う制限値が入りがちです。

よく効いてしまう制限の代表例

• RLIMIT_AS（ulimit -v / as）：プロセスが使える仮想メモリの上限。mmapや巨大確保で ENOMEM を誘発しやすい。
• RLIMIT_STACK（ulimit -s）：スレッドが多い、深い再帰、巨大スタックフレーム等で問題化。
• RLIMIT_MEMLOCK：ロックメモリ上限。特定用途（リアルタイム、暗号、DBの一部設定）で影響。
• nproc：fork/スレッド生成が詰まり、結果として別の箇所で確保失敗に見えることがある。

---

“ログイン時に見たulimit”と“実運用のulimit”が違う問題

SSHで入って ulimit -a を見て「問題ない」と判断しても、実際にサービスを起動しているのが systemd の場合、LimitAS/LimitSTACK 等で別の値が適用されていることがあります。また、PAM経由の limits.conf は「ログインセッション」に効いても、サービス起動には反映されないことがあります。つまり、切り分けで重要なのは“そのプロセスが実際に受けている制限値”です。

アドレス空間の観点：RAMは余っていてもASが足りない

ENOMEMが仮想メモリ（アドレス空間）起因で出るケースは、コンテナやulimitだけでなく、32bitプロセスや、断片化によって「連続した大きな領域が取れない」場合にも起きます。たとえば、大きな連続バッファを確保する実装、巨大なメモリマップ、極端に多いmmap領域などは、AS制約の影響を受けます。ここは“メモリ使用量（RSS）”だけ追っていると見落としやすいポイントです。

---

改善の方向性：上限を上げる前に“なぜ必要か”を説明可能にする

制限値を上げれば一旦は収束することがあります。しかし、上限の引き上げは「どこか別のボトルネックへ押し出す」だけになりがちです。たとえば RLIMIT_AS を無制限にしても、次は cgroups の memory.max で落ちる、あるいはOOMで別プロセスが巻き込まれる、といった形で不安定さが移動することがあります。

現場で腹落ちする改善は、「このサービスは最大同時◯件で、1件あたり最大◯MBのピークを持つ。だから上限は◯GB必要で、さらに異常系でのスパイクを◯%まで許容する」といった説明可能な設計に落とし込むことです。ここから先は、ワークロード、SLO、周辺システムの余力、契約条件を含む“個別案件”になります。一般論の範囲を超えた時点で、株式会社情報工学研究所のような専門家に状況を整理してもらう方が、追加のトラブルを増やさずに軟着陸しやすくなります。

　

第5章：cgroups・コンテナ・systemd の MemoryMax──見えない天井を疑う

「ホストは空いてるのに、コンテナだけ落ちる。free -h だと余裕なのに…」——この状況は、ほぼ“見えない天井”です。コンテナや systemd サービスは、ホスト全体のメモリとは別に、cgroups（制御グループ）という仕組みでメモリ上限を課されます。ここを見落とすと、原因調査が「アプリのリーク」か「OSの不調」かの二択になり、いつまでも収束しません。

cgroupsで何が起きるか（直感）

cgroups は「このグループのプロセス群が使える資源は、ここまで」というルールをカーネルに与えます。つまり、ホスト全体では余裕があっても、対象プロセスが所属する cgroup の上限（たとえば memory.max）を超えると、確保が失敗して ENOMEM になったり、OOM で落とされたりします。現場的には“同じマシン上で、別の財布を渡されている”感覚が近いです。

---

cgroups v2（現行で多い）の確認ポイント

cgroups v2 では、概ね次のファイルが観測の軸になります（配置は環境により異なりますが考え方は同じです）。

• memory.current：今どれくらい使っているか（そのcgroupの現在値）。
• memory.max：上限（ここを超えると確保が通りにくくなり、最終的にOOMへ）。
• memory.high：ソフト上限（超え始めると抑制がかかり、遅延やスロットリングの兆候になり得る）。
• memory.events：上限到達やOOM関連のイベント回数が記録される。

ここで大事なのは、「上限があるかどうか」ではなく「上限が、いつ・どれだけ・誰に効いたか」です。単に上限を上げると一時的に収束しても、ピーク時に別の箇所で同じ形の事故が再発します。

---

systemdの MemoryMax は “cgroupsの天井” そのもの

systemd で起動しているサービスは、unit ファイル（または drop-in）に MemoryMax などが設定されている場合があります。これが入っていると、サービスはその枠の中でしか動けません。開発端末では問題が出ず、本番だけで ENOMEM が出る典型がこれです。

現場の独り言としては、こうなりがちです。

「え、今まで普通に動いてたのに…昨日のデプロイ何も変えてないのに…」

実際には、アプリは変えていなくても、unit の制限値、起動ユーザー、コンテナの limits、同居サービスの増減など、“枠”の方が変わっていることが珍しくありません。SREが「アプリは触ってない」と言い、情シスが「サーバは余裕」と言い、でも障害は続く——このねじれは、枠の存在を見える化すると一気にほどけます。

---

Kubernetes/Dockerで起きやすい“ズレ”

• requests と limits の混同：予約（requests）と上限（limits）は別で、上限に当たると落ち方が変わります。
• 横展開で総量が増える：Pod数を増やすと、ノード全体の余力が減り、別Podまで巻き込むことがある。
• 同一イメージでもノード差が出る：ノードごとに同居状況が違い、ピーク時だけ特定ノードで再現する。

改善策としては、単純に“上限を上げる”のではなく、ピークの根拠（同時実行数、最大バッファ、キャッシュ戦略、ワーカー数）を言語化し、上限とアラートをセットで設計するのが王道です。さらに、落ちるなら落ちるで、落ち方を制御する（縮退、キュー、バックプレッシャー、レート制御）まで設計に入れると、運用はかなり楽になります。

ただし、この設計はサービスごとのSLOや業務影響、契約条件によって最適解が変わります。「このシステムは夜間に落ちても許されるのか」「落ちた瞬間に損失が出るのか」で、必要な余裕率も監視も別物です。一般論の範囲を超えた判断が必要になったら、株式会社情報工学研究所のような専門家と一緒に“枠・実態・落ち方”を整理して、軟着陸させるのが現実的です（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983 ／ 電話：0120-838-831）。

　

第6章：OOM Killer の動き方──dmesg/journalctl で「殺された証拠」を拾う

ENOMEM の裏で、実は OOM（Out Of Memory）イベントが起きていることがあります。OOM は「メモリが足りない」というより、カーネルが“このままだと全体が危ない”と判断して、どれかを終了させる挙動です。現場感としては、障害対応中に一番しんどいやつです。

「落ちたのはアプリなのか、誰かがkillしたのか、クラッシュなのか…」

この曖昧さが残ると、対策が毎回“お祈りの再起動”になり、収束しません。だからこそ、OOMの証拠は最優先で拾う価値があります。

OOMのログが重要な理由

• 原因の層が確定する：アプリの例外ではなく、カーネルのメモリ管理問題だと分かる。
• いつ・誰が・どの条件で落ちたかが残りやすい：時刻、対象プロセス、場合によってはメモリ使用量の断片情報。
• cgroups上限との関係が見える：コンテナ／サービス単位の上限到達が示唆される。

---

“OOMっぽい”ときの観測ポイント

代表的には、カーネルログ（dmesg）や systemd journal（journalctl）に痕跡が出ます。環境により文言は異なりますが、着目点は共通です。

• 対象プロセス名、PID、終了理由があるか
• cgroup単位のOOMが示唆されるか（コンテナ内だけ落ちている等）
• 事象直前にメモリ圧迫（スワップ急増、PSI上昇、スローダウン）があったか

また、アプリ側のログが「突然途切れる」「最後が通常終了っぽい」のにプロセスが消えている場合、OOMの可能性が上がります。JavaなどはOOM例外を吐くケースもありますが、プロセスがOSにより終了させられた場合は、アプリが“綺麗に”ログを残せないことが多いです。

---

OOMは「誰かが悪い」ではなく「設計の押し出し」

OOMを「アプリが重いから」「インフラが弱いから」と犯人探しにすると、対策は荒れます。実態は、要求（ピーク時の必要メモリ）と、供給（枠・実メモリ・swap・コミット方針）が噛み合っていないだけです。噛み合っていない以上、どこかの時点で落ちます。問題は「どこで落ちるか」「誰を巻き込むか」「落ちる前に減速できるか」です。

落ち方を制御する、という発想

現場を救うのは、根性論ではなく設計です。たとえば次のような“落ち方の制御”は、ENOMEM/ＯＯＭを事故から運用設計へ引き戻します。

• ワーカー数・並列度の上限を設ける（同時実行を抑え込み、ピークを切る）。
• キューイングとバックプレッシャー（受ける量を制御し、過負荷を穏やかにする）。
• キャッシュ戦略の見直し（無制限キャッシュをやめ、上限と追い出しを設計する）。
• 縮退運転（一部機能停止、低品質モード、再試行抑制などで“サービス全体の鎮火”を優先）。

---

ここまで来ると、単なるOS設定の話ではなく「どの機能を守り、どの機能は落として良いか」という業務判断が絡みます。さらに、クラウド費用、冗長化、監視の粒度、障害時のエスカレーション設計まで連動します。一般論で済ませるほど、現場にとっては“運用だけが増える”結果になりがちです。個別の条件に合わせて整理するなら、株式会社情報工学研究所のような専門家と一緒に、ログ保全から再発防止まで一気通貫で設計した方が、結果として余計な手戻りを減らせます（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983 ／ 電話：0120-838-831）。

　

第7章：swap と overcommit──増やすべきか、減らすべきかの判断軸

ENOMEM/ＯＯＭの議論で、だいたい揉めるのが swap と overcommit です。結論から言うと、どちらも“善悪”ではなく、ワークロードとSLO次第です。ここを一般論で決めると、別の場所で痛みが出ます。

swapの役割を雑に言うと

• メモリの延命：一時的なピークをやり過ごせる可能性がある。
• ただし遅くなる：スワップアウトが増えるとI/O待ちが増え、レイテンシやタイムアウトが悪化しやすい。
• “落ちない代わりに遅い”を選ぶのか、“速い代わりに落ちる”を選ぶのか、選択が必要。

現場の本音はこうです。

「落ちるのは困る。でも、遅くなると結局クレームが来る。どっちなんだよ…」

だから判断軸は「落ちる/落ちない」ではなく、どの症状が許容できて、どの症状が致命的かです。バッチ処理なら遅延は許容できるが落ちるのは困る、オンライン処理なら遅延が致命的なのでスワップは悪手、など。

---

overcommitとは何か（誤解しやすいポイント）

Linuxは、プロセスが要求したメモリを「すぐに物理メモリで裏付ける」とは限りません。要求の段階で“将来使うかもしれない”量を見積もって許可する仕組みがあり、この方針が overcommit と呼ばれます。ここで起きる現象はざっくり二系統です。

• 早めに拒否される（ENOMEMが返る）：将来の裏付けが見込めないと判断され、割り当て要求が通らない。
• いったん通るが後で詰む（OOMに寄りやすい）：要求は通るが、実際に触った瞬間に裏付けが足りず、どこかが落ちる。

どちらが良いかは一概に言えません。重要なのは「いつ失敗させるか」を設計することです。早めに失敗させれば、アプリ側でリトライや縮退に回せる可能性が上がります。遅く失敗させると、ピークで突然落ち、巻き込みが増えることがあります。

---

実務的な判断の作り方：3つの質問

1. ピークは短時間か、継続か：短時間ピークなら延命（swap等）が効く可能性がある。
2. 遅延は許容できるか：許容できないなら、延命よりも“早めに拒否して縮退”が向く。
3. 誰を守るか：単体サービスを守るのか、ノード全体・同居サービスを守るのかで方針が変わる。

---

「とりあえずswap増やす」で収束しないケース

• スワップI/Oが増えてタイムアウト→再試行が増え→さらに負荷が増える（負のループ）。
• コンテナ上限が原因で、ホストswapの増減が効かない。
• リークやキャッシュ無制限が原因で、延命しても結局枯渇まで走る。

逆に、短時間スパイクで落ちるだけのケースでは、延命が効いて“鎮火”することもあります。ただし、その場合でも「なぜスパイクが起きるのか」「どの機能がスパイクを作るのか」を潰さない限り、次のピークで再燃します。

swap/overcommitは、設定の是非よりも、サービスの壊れ方をどう設計するかの話です。ここは業務・契約・SLOが絡むため、一般論のコピペで決めると危険です。具体的な案件として“許容できる遅延”や“守る機能”を整理し、運用と設計をセットで決めたいなら、株式会社情報工学研究所のような専門家に相談して、最短で収束させるのが現実的です（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983 ／ 電話：0120-838-831）。

　

第8章：メモリリーク・断片化・巨大ページ──アプリ側でできる“先回り”

OS側の制限（ulimit、cgroups、swap/overcommit）を確認してもなお ENOMEM が出るなら、次に疑うべきは「アプリが要求するメモリの形」です。ここでのポイントは、“合計量”だけではなく“割り当てのパターン”が ENOMEM を引き起こすという事実です。メモリが残っているように見えても、必要な形で確保できず失敗することがあります。

まず分ける：リーク／一時スパイク／断片化

分類	現象の特徴	初動の観測ポイント
メモリリーク	負荷が落ちても使用量が戻らず、時間とともに右肩上がり	RSS/heapのトレンド、プロセス再起動で一旦回復するか
一時スパイク	ピーク時だけ跳ね、平常時は戻る／同時実行数と相関	並列度・バッチ同時実行・リクエストサイズ分布
断片化/確保形状	合計は足りていそうでも、大きな連続領域が取れずに失敗	mmapの増減、smaps、巨大割り当ての頻度

---

「何が増えているか」をOS視点で掴む

アプリが「メモリ不足」と言っても、増えているのがヒープとは限りません。匿名メモリ、ページキャッシュ、mmap領域、スレッドスタック、JITやネイティブバッファなど、内訳を切らないと対策がズレます。Linuxではプロセスごとの内訳を見る手段がいくつかあります。

• /proc/<pid>/status：VmRSS/VmSizeなどの概要（粒度は粗いが早い）。
• /proc/<pid>/smaps：領域ごとの詳細（重いが“何が膨らんだか”が見える）。
• pmap：mmap領域の俯瞰（断片化や巨大領域の有無の当たりを付けやすい）。

---

言語/ランタイム別に起きやすい“増え方”

ここは事実として「言語が悪い」という話ではなく、メモリの使い方のクセが違うという話です。ENOMEM対策は、クセに合わせて“先回り”した方が収束が早いです。

• C/C++：リーク、二重管理、巨大連続確保、アロケータの挙動（断片化、arena）。
• Java：ヒープ以外（DirectBuffer、メタスペース、ネイティブ領域）、コンテナ上限とJVM設定の不整合。
• Go：ワーカ増加、保持参照による回収遅延、巨大スライスの保持、goroutineの増殖。
• Python：オブジェクト保持、キャッシュ/辞書肥大、参照サイクル、バッチ処理での一時巨大データ。
• Node.js：ヒープ上限のデフォルト、バッファやストリームの滞留、同時処理の設計。

---

「上限を上げる」前にできる設計的ブレーキ

ピークで ENOMEM が出るとき、メモリ上限を上げるのは最も簡単ですが、同時に“別のどこかを巻き込む”リスクも上がります。現場で効きやすいのは、メモリ消費を直接減らすだけでなく、ピークを作らない設計です。

• 並列度に上限：ワーカ数・同時リクエスト数・バッチ同時実行数を固定し、ピークを抑え込む。
• 入力サイズの上限：巨大リクエストや巨大ファイルを早めに拒否し、メモリ圧迫を予防する。
• ストリーミング/チャンク化：一括読み込みを避け、固定サイズで処理する。
• キャッシュの上限と追い出し：無制限キャッシュをやめ、上限・TTL・サイズベースの設計にする。

---

“原因究明の道具”を選び間違えない

メモリ問題の調査は、重いプロファイルを本番で常時回すほど危険になります。だからこそ、段階を踏むのが安全です。まずは軽い観測で当たりを付け、必要な範囲だけ深掘りします。

目的	軽い手段	深掘り手段（慎重に）
増えている領域の当たり	/proc、pmap、smapsの抜粋	詳細なヒープ解析、領域別の連続サンプリング
リークの疑い	トレンド監視、再起動で戻るか	言語別プロファイラ、サニタイザ等
ピーク要因の特定	並列度・入力分布・キュー長の相関	負荷再現、シナリオ別の計測

ここまでの改善は「手を動かす現場」に効きますが、同時に「どこまでやるか」の線引きが必要です。停止できないレガシー、複数チームの境界、契約上の制約が絡むと、一般論の最適化はむしろトラブルを増やすことがあります。具体的な構成・可用性要件・保全方針を踏まえて、収束までのルートを短くしたいなら、株式会社情報工学研究所に相談し、ログ保全と改善案をセットで整理するのが現実的です（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983 ／ 電話：0120-838-831）。

　

第9章：監視と再発防止──RSSだけ見ても足りない（PSI, vmstat, p95）

ENOMEMは、発生した瞬間だけ追っても再発します。理由は単純で、メモリは「溜まる」「波が来る」「急に跳ねる」からです。だから再発防止は、原因の修正と同じくらい観測とアラートの設計が重要になります。ここでの落とし穴は、RSSやfreeだけを見て安心してしまうことです。

見たいのは「残量」ではなく「圧力」と「兆候」

メモリ関連の事故は、残量がゼロになる直前より前に“兆候”が出ます。代表例は、リクレーム（回収）が増える、スワップが動き始める、スケジューリングが詰まる、レイテンシが悪化する、などです。Linuxではこれらの兆候を捉える指標があります。

• vmstat：スワップ入出（si/so）、リクレームの雰囲気、ランキューの増減。
• PSI（Pressure Stall Information）：メモリ圧迫で“待たされている時間”を捉えやすい。
• cgroupsのevents：上限到達やOOM関連のイベントが増えていないか。
• p95/p99レイテンシ：平均ではなく上位遅延が伸びると、圧迫の実害に直結しやすい。

---

アラートの作り方：落ちる前に“クールダウン”させる

アラートは「落ちた」通知では遅すぎます。理想は、落ちる前に縮退や制限をかけるための“合図”にすることです。たとえば次のような構成は、現場でのダメージコントロールに効きます。

• 注意（黄）：cgroup使用率が高止まり／PSIが上昇／p95が伸び始める → 並列度を下げる、バッチ開始を遅らせる判断材料。
• 警戒（橙）：memory.high超過やevents増加 → 自動で一部機能制限、レート制御、キューの取り込み抑制。
• 危険（赤）：OOM発生、memory.max付近、swap激増 → 影響範囲の隔離、緊急縮退、原因ログの保全を優先。

---

「どれを監視すればいいか分からない」問題への現実解

監視は増やしすぎると、結局だれも見なくなります。だから、まずは“原因の層”ごとに最小セットを決めるのが現実的です。

原因の層	最小セット（例）	見落としやすい罠
ホスト全体の圧迫	PSI、swap入出、主要サービスのp95	平均レイテンシだけ見て安心する
コンテナ/サービス上限	memory.current/max、events、OOM回数	ホストのfreeだけ見て判断する
アプリの増え方	プロセスRSS/heapのトレンド、ワーカ数、キュー長	瞬間値だけ見て“たまたま”扱いする

---

再発防止は「運用Runbook」までセット

ENOMEMは、現場対応がバラバラだと同じ事故を繰り返します。だから、最低限のRunbook（手順書）を作っておくと、収束が早くなります。内容は派手でなくて良いです。重要なのは、誰が見ても同じ順番で“証拠を残し、影響を抑え込み、判断する”ことです。

1. 事象時刻・対象PID/Pod/Unitを特定
2. ログ保全（journal/dmesg/アプリログ）
3. 制限の確認（ulimit、unit、cgroups）
4. 圧迫の確認（PSI、swap、レイテンシ）
5. 縮退判断（並列度・レート制御・機能制限）
6. 恒久対策の仮説（リーク／ピーク／制限値の不整合）

ここまで整うと、ENOMEMは“突然の事故”ではなく、“予兆が取れる運用課題”になります。ただし、監視・縮退・Runbookは、組織の役割分担や契約、システム境界の事情で最適解が変わります。一般論をそのまま当てはめると「監視は増えたのに、現場は楽にならない」状態になりがちです。具体的な構成と責任分界を踏まえて、最小コストで収束させたいなら、株式会社情報工学研究所に相談し、監視設計と改善案を一緒に固めるのが現実的です（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983 ／ 電話：0120-838-831）。

　

第10章：帰結：ENOMEMは「不足」ではなく「契約違反」──上限を可視化し、壊れ方を制御する

ここまで読んだあなたが、たぶん一番「なるほど」と感じるのは、ENOMEMが“メモリが足りない”という単純な不足ではなく、どこかの上限（契約条件）に触れた結果として表面化するケースがとても多い、という点だと思います。ホストの空き、コンテナの上限、systemdの制限、ulimit、overcommit、アドレス空間、そしてアプリの割り当てパターン。これらは全部、同じ「ENOMEM」という顔をして現れます。

だから、結論はこうです。ENOMEMに強い現場は、メモリを“量”としてだけ扱いません。枠（上限）と実態（使い方）と壊れ方（落ち方）をセットで設計します。逆に、ここが曖昧な現場は「とりあえず増やす」「とりあえず再起動」の往復になり、次のピークで再燃します。

最後に整理：ENOMEMを収束させるための3点セット

観点	やること	腹落ちする理由
枠（上限）	ulimit / systemd / cgroups の上限を一覧化し、実運用の値を確定する	ホストに余裕があっても落ちる“見えない天井”を消せる
実態（使い方）	ピークの原因を分解（並列度・入力サイズ・キャッシュ・リーク・断片化）し、内訳を掴む	増設で逃げる前に、減らせる・抑え込めるポイントが見える
壊れ方（落ち方）	縮退運転・レート制御・バックプレッシャー・キュー設計で“落ちる前に減速”を用意する	落ち方を制御できると、事故が運用の範囲に戻る

---

「自分で直せそう」に見える瞬間が、いちばん危ない

ENOMEMは、原因の層を見誤ると対策が逆効果になりやすい障害です。たとえば、コンテナ上限が原因なのにホスト側だけ増設する、overcommitとワークロードが噛み合っていないのにswapだけ増やす、リークなのに上限を上げて延命する——こうした手当ては、短期的に収束したように見えても、ピーク時に別の形で再燃します。

現場の本音としては、こうですよね。

「分かってる。分かってるけど、いま止められないんだよ」

だからこそ、最初にやるべきは“完全解決”ではなく、ダメージコントロール（被害最小化）です。ログを守り、影響を固定し、縮退させ、再発を防ぐ観測を入れる。これができると、現場の温度が下がり、判断がクリアになります。

---

依頼判断：今すぐ相談すべき条件

• OOMが発生し、プロセスが突然消える／同居サービスまで巻き込み始めている
• コンテナやsystemdの上限が絡み、設定差分の追跡が複数チームに跨っている
• ピーク時の同時実行・バッチ・外部API遅延が絡み、原因が一つに絞れない
• レガシーで停止できず、調査のための計測や変更自体がリスクになっている
• 契約・SLO・業務影響が絡み、「遅くなる」か「落ちる」かの許容判断が必要

---

一般論の限界と、専門家に任せる意味

ここまでの内容は、現場でよく効く“原理原則”です。ただ、あなたの環境には必ず固有条件があります。契約、業務ピーク、冗長化、監視基盤、リリース手順、責任分界、そして「止められない」という現実。こうした前提がある以上、一般論だけで最適解を断言することはできません。

だから最終的な帰結はこうなります。ENOMEMを“技術課題”としてだけ処理しようとすると、現場は疲弊します。ENOMEMを運用設計と契約条件の問題として扱い、枠と実態と壊れ方を揃えて初めて、安定して収束します。その整理を短い時間でやり切るには、経験と手順が必要です。

具体的な案件・契約・システム構成まで踏み込んで「どこを守り、どこを削るか」「どの順で収束させるか」で悩んだら、株式会社情報工学研究所への相談・依頼を検討してください（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983 ／ 電話：0120-838-831）。

　

付録：主要プログラミング言語別──ENOMEM/メモリ問題で見落としやすい注意点

ENOMEMはOS側の制限が主因になることも多い一方で、アプリ側のメモリの“増え方”や“保持の仕方”が引き金になることもあります。ここでは、現場で再発防止に効きやすい注意点を、言語・ランタイムごとに短く整理します。

C / C++

• リークの有無だけでなく、確保サイズの分布と解放タイミングの偏りが断片化を作る。
• スレッドごとのスタック使用量が大きい実装は、並列度増加で急に詰むことがある。
• アロケータの挙動（スレッドごとのarena、断片化、mmap多用）がメモリの見え方を変える。

Rust

• 安全性は高いが、保持している参照が長いとメモリが戻らない（設計次第で常駐化する）。
• Vec/HashMapの成長戦略でピークが跳ねることがあるため、上限・予約容量・ストリーミング化が効く。

Go

• goroutine増殖やキュー滞留で、想定以上にメモリが膨らむ（並列度とバックプレッシャーが重要）。
• 参照が残るとGCが回っても回収できないため、データの所有と寿命を設計で揃える。
• コンテナ上限と実メモリ挙動の噛み合わせで、ピーク時に落ち方が変わることがある。

Java / Kotlin / Scala（JVM系）

• ヒープ（-Xmx）だけでなく、メタスペース、スレッドスタック、DirectBuffer等の合計で枠に当たる。
• コンテナ上限に対してJVM設定が合っていないと、余裕があるように見えて突然落ちる。
• GCは万能ではなく、ピークの作り方（同時実行・一括読み込み）を変えないと再発しやすい。

Python

• オブジェクト参照が残り続けると、実質的にリークと同じ症状になる（キャッシュ・グローバル保持に注意）。
• バッチで巨大データを一括で持つ設計はピークを作りやすい（チャンク処理・逐次化が効く）。
• ネイティブ拡張や外部ライブラリが確保する領域は、純粋なPythonコードの感覚とズレる。

Node.js（JavaScript/TypeScript実行系）

• ヒープ上限やバッファ滞留でピークが出やすい（ストリーム処理と同時実行制御が重要）。
• Promiseの未回収、イベントループに溜まる参照が“戻らないメモリ”を作ることがある。

PHP

• プロセスモデル（FPM等）とワーカ数がメモリ総量を決めるため、同時実行×ワーカ常駐で枠に当たりやすい。
• リクエスト単位のメモリ上限設定がある環境では、入力サイズや処理手順で急に失敗する。

.NET（C# など）

• マネージ領域以外（ネイティブ、ピン留め、スレッド、バッファ）の影響で、想定より早く枠に当たる。
• 大きなオブジェクトやキャッシュがピークを作るため、上限と追い出し設計が効く。

---

言語ごとの注意点はあくまで入口で、最終的には「あなたのシステムは、どのピークを許容し、どこで減速し、どこを守るのか」という設計に帰着します。一般論の範囲を超えて、具体的な構成・契約・運用の現実まで踏まえた判断が必要になったら、株式会社情報工学研究所への相談・依頼を検討してください（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983 ／ 電話：0120-838-831）。

　

第10章：帰結：ENOMEMは「不足」ではなく「契約違反」──上限を可視化し、壊れ方を制御する

ここまで読んだあなたが、たぶん一番「なるほど」と感じるのは、ENOMEMが“メモリが足りない”という単純な不足ではなく、どこかの上限（契約条件）に触れた結果として表面化するケースがとても多い、という点だと思います。ホストの空き、コンテナの上限、systemdの制限、ulimit、overcommit、アドレス空間、そしてアプリの割り当てパターン。これらは全部、同じ「ENOMEM」という顔をして現れます。

だから、結論はこうです。ENOMEMに強い現場は、メモリを“量”としてだけ扱いません。枠（上限）と実態（使い方）と壊れ方（落ち方）をセットで設計します。逆に、ここが曖昧な現場は「とりあえず増やす」「とりあえず再起動」の往復になり、次のピークで再燃します。

最後に整理：ENOMEMを収束させるための3点セット

観点	やること	腹落ちする理由
枠（上限）	ulimit / systemd / cgroups の上限を一覧化し、実運用の値を確定する	ホストに余裕があっても落ちる“見えない天井”を消せる
実態（使い方）	ピークの原因を分解（並列度・入力サイズ・キャッシュ・リーク・断片化）し、内訳を掴む	増設で逃げる前に、減らせる・抑え込めるポイントが見える
壊れ方（落ち方）	縮退運転・レート制御・バックプレッシャー・キュー設計で“落ちる前に減速”を用意する	落ち方を制御できると、事故が運用の範囲に戻る

---

「自分で直せそう」に見える瞬間が、いちばん危ない

ENOMEMは、原因の層を見誤ると対策が逆効果になりやすい障害です。たとえば、コンテナ上限が原因なのにホスト側だけ増設する、overcommitとワークロードが噛み合っていないのにswapだけ増やす、リークなのに上限を上げて延命する——こうした手当ては、短期的に収束したように見えても、ピーク時に別の形で再燃します。

現場の本音としては、こうですよね。

「分かってる。分かってるけど、いま止められないんだよ」

だからこそ、最初にやるべきは“完全解決”ではなく、ダメージコントロール（被害最小化）です。ログを守り、影響を固定し、縮退させ、再発を防ぐ観測を入れる。これができると、現場の温度が下がり、判断がクリアになります。

---

依頼判断：今すぐ相談すべき条件

• OOMが発生し、プロセスが突然消える／同居サービスまで巻き込み始めている
• コンテナやsystemdの上限が絡み、設定差分の追跡が複数チームに跨っている
• ピーク時の同時実行・バッチ・外部API遅延が絡み、原因が一つに絞れない
• レガシーで停止できず、調査のための計測や変更自体がリスクになっている
• 契約・SLO・業務影響が絡み、「遅くなる」か「落ちる」かの許容判断が必要

---

一般論の限界と、専門家に任せる意味

ここまでの内容は、現場でよく効く“原理原則”です。ただ、あなたの環境には必ず固有条件があります。契約、業務ピーク、冗長化、監視基盤、リリース手順、責任分界、そして「止められない」という現実。こうした前提がある以上、一般論だけで最適解を断言することはできません。

だから最終的な帰結はこうなります。ENOMEMを“技術課題”としてだけ処理しようとすると、現場は疲弊します。ENOMEMを運用設計と契約条件の問題として扱い、枠と実態と壊れ方を揃えて初めて、安定して収束します。その整理を短い時間でやり切るには、経験と手順が必要です。

具体的な案件・契約・システム構成まで踏み込んで「どこを守り、どこを削るか」「どの順で収束させるか」で悩んだら、株式会社情報工学研究所への相談・依頼を検討してください（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983 ／ 電話：0120-838-831）。

　

付録：主要プログラミング言語別──ENOMEM/メモリ問題で見落としやすい注意点

ENOMEMはOS側の制限が主因になることも多い一方で、アプリ側のメモリの“増え方”や“保持の仕方”が引き金になることもあります。ここでは、現場で再発防止に効きやすい注意点を、言語・ランタイムごとに短く整理します。

C / C++

• リークの有無だけでなく、確保サイズの分布と解放タイミングの偏りが断片化を作る。
• スレッドごとのスタック使用量が大きい実装は、並列度増加で急に詰むことがある。
• アロケータの挙動（スレッドごとのarena、断片化、mmap多用）がメモリの見え方を変える。

Rust

• 安全性は高いが、保持している参照が長いとメモリが戻らない（設計次第で常駐化する）。
• Vec/HashMapの成長戦略でピークが跳ねることがあるため、上限・予約容量・ストリーミング化が効く。

Go

• goroutine増殖やキュー滞留で、想定以上にメモリが膨らむ（並列度とバックプレッシャーが重要）。
• 参照が残るとGCが回っても回収できないため、データの所有と寿命を設計で揃える。
• コンテナ上限と実メモリ挙動の噛み合わせで、ピーク時に落ち方が変わることがある。

Java / Kotlin / Scala（JVM系）

• ヒープ（-Xmx）だけでなく、メタスペース、スレッドスタック、DirectBuffer等の合計で枠に当たる。
• コンテナ上限に対してJVM設定が合っていないと、余裕があるように見えて突然落ちる。
• GCは万能ではなく、ピークの作り方（同時実行・一括読み込み）を変えないと再発しやすい。

Python

• オブジェクト参照が残り続けると、実質的にリークと同じ症状になる（キャッシュ・グローバル保持に注意）。
• バッチで巨大データを一括で持つ設計はピークを作りやすい（チャンク処理・逐次化が効く）。
• ネイティブ拡張や外部ライブラリが確保する領域は、純粋なPythonコードの感覚とズレる。

Node.js（JavaScript/TypeScript実行系）

• ヒープ上限やバッファ滞留でピークが出やすい（ストリーム処理と同時実行制御が重要）。
• Promiseの未回収、イベントループに溜まる参照が“戻らないメモリ”を作ることがある。

PHP

• プロセスモデル（FPM等）とワーカ数がメモリ総量を決めるため、同時実行×ワーカ常駐で枠に当たりやすい。
• リクエスト単位のメモリ上限設定がある環境では、入力サイズや処理手順で急に失敗する。

.NET（C# など）

• マネージ領域以外（ネイティブ、ピン留め、スレッド、バッファ）の影響で、想定より早く枠に当たる。
• 大きなオブジェクトやキャッシュがピークを作るため、上限と追い出し設計が効く。

---

言語ごとの注意点はあくまで入口で、最終的には「あなたのシステムは、どのピークを許容し、どこで減速し、どこを守るのか」という設計に帰着します。一般論の範囲を超えて、具体的な構成・契約・運用の現実まで踏まえた判断が必要になったら、株式会社情報工学研究所への相談・依頼を検討してください（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983 ／ 電話：0120-838-831）。