Ubuntu ENOMEM (12) 対策：メモリ不足エラー「Out of memory」発生時のリソース最適化編

【注意】 ENOMEM(12) や「Out of memory」が出ている環境では、原因がアプリ不具合だけでなく、OS設定、コンテナ制限、ストレージ逼迫、監視や運用設計の不足など複合になっていることがあります。自己流の“復旧作業”や場当たり的な設定変更で被害を拡大させないため、個別案件の判断が必要な場合は株式会社情報工学研究所のような専門事業者へ相談してください（無料相談フォーム：https://jouhou.main.jp/?page_id=26983 ／電話：0120-838-831）。

第1章：深夜にENOMEMが刺さる瞬間――まずは“被害最小化”のダメージコントロール

「昨日まで動いてたのに、今夜だけ落ちる」「ログに Out of memory が出た。で、何から手を付ける？」――この手の障害は、現場の感情を一気にざわつかせます。しかもレガシーや止められない基幹が絡むと、正論（増設しよう、作り直そう）が刺さらない。まず必要なのは、根性論ではなく“被害最小化”の手順です。

頭の中でこんな独り言が走っていませんか。

• 「また夜勤か……でも原因がアプリなのかOSなのか、今は断言できない」
• 「とりあえず再起動で直るかも、って言われるけど、再起動のたびに再現条件が変わるのが一番つらい」
• 「誰かが ‘メモリ増やせば？’ って言うけど、今ここで欲しいのは手順だ」

その感覚は自然です。ENOMEMやOOMは、単なる“容量不足”ではなく、どの層（アプリ／ランタイム／OS／コンテナ／クラスタ）が限界を迎えたかを切り分けないと、改善が積み上がりません。

冒頭30秒：症状→取るべき行動（安全な初動ガイド）

ここでのポイントは、「直す」より先に状況を固定して、証拠（ログと指標）を残すことです。場当たりの変更は、次の障害対応で“同じ穴”を掘ります。

依頼判断：今すぐ相談したほうがいい条件

• OOM Killer が継続して発生し、原因プロセスが断定できない
• 止められない基幹で、再起動や設定変更のリスクが大きい
• コンテナ/クラスタ/監視/ジョブ設計が絡み、単一担当で手に負えない
• メモリ以外（ストレージ逼迫、ファイルディスクリプタ枯渇、ログ肥大化、バックアップ失敗）が同時に疑わしい

一般論で「増設」「最適化」と言うのは簡単ですが、個別案件では、落としてはいけないサービス、戻せない設定、守るべきデータが絡みます。判断に迷った時点で、株式会社情報工学研究所への相談（無料相談フォーム：https://jouhou.main.jp/?page_id=26983 ／電話：0120-838-831）を検討してください。

第2章：ENOMEM(12)は“原因名”ではない――Out of memory／OOM Killer／割り当て失敗を分けて考える

Linux/Ubuntuで見る “メモリ不足” は、見た目が似ていても意味が違います。まず言葉を揃えるだけで、対策の打ち手が変わります。

ENOMEM(12)：ユーザー空間で「確保できない」

アプリやライブラリが malloc/new/mmap 等でメモリ確保を要求したとき、要求を満たせずに返ってくるのが ENOMEM(12) です。ここで重要なのは、「その瞬間に物理RAMがゼロだった」とは限らないことです。OSのメモリ管理は、ページキャッシュや遅延確保、制限（ulimit/cgroup）などが絡むため、“確保に失敗した”という事実を出発点にします。

“Out of memory” と OOM Killer：カーネルが「誰かを落としてでも守る」

一方で、カーネル側で回収（reclaim）しても追いつかず、システム全体が危険域に入ったとき、カーネルがプロセスを強制終了する仕組みが OOM Killer です。ログには “Out of memory” や “Killed process …” のような出力が残り、通常は対象プロセスが SIGKILL で落ちます。

ここでの心理的な落とし穴は、「落ちたプロセス＝犯人」と決めつけることです。OOM Killer は“最悪を回避するための選別”であって、必ずしも根本原因のプロセスを落とすとは限りません。例えば、あるプロセスが急増させたメモリ圧迫の結果、別の重要プロセスが巻き込まれることもあります。

同じ現象でも、見るべきログが違う

「なるほど、まず“どれ”のOOMなのかを決めるのが先か」と腹落ちすると、次章以降の計測が迷子になりません。

第3章：まず事実を固める――“誰が・どこを・どれだけ”食っているか測る

メモリ障害で一番つらいのは、「推測の議論」が増えて、手が止まることです。ここは割り切って、短時間で“計測の型”を作ります。現場の会話を、推測からデータへ戻す章です。

全体像：RAM・キャッシュ・swapの3点セットで見る

• free -h：大づかみ（total/used/free/buff/cache/available）
• vmstat 1：変化を見る（r/b、si/so、wa、us/sy/id）
• swapon --show と cat /proc/swaps：swapの有無とサイズ
• cat /proc/meminfo：内訳（MemAvailable、Slab、SReclaimable など）

「available があるのに ENOMEM？」のような違和感が出たら、プロセス側の制限（ulimit/cgroup）や、割り当て要求の性質（巨大連続領域、mmapの失敗、オーバーコミット方針）を疑う材料になります。

犯人探し：プロセスの“実メモリ”はRSSだけで決めない

よくある罠が「psのRSSが大きい＝悪」と短絡することです。共有ライブラリ、ページキャッシュ、匿名メモリ、スレッドスタックなどが混ざるため、可能なら次の順で深掘りします。

• ps aux --sort=-rss | head：入口（上位を見る）
• smem -tk（導入できる場合）：PSSで共有分を按分して把握
• pmap -x PID：どの領域が増えているか（ヒープ、匿名、マップドファイル）
• /proc/PID/smaps_rollup：PSS/RSS/Anon/Fileの要約

「また新しいツール？」と思うのも自然です。でも、ここでの狙いはツール増やしではなく、議論を短くすることです。PSSや内訳が見えると、「共有が大きいだけ」「匿名が増えている」「ファイルマップが肥大」など、打ち手が変わります。

時系列が命：1回のスナップショットで決めない

ENOMEMやOOMは“瞬間芸”になりがちです。可能なら、次のどれかで時系列を残します。

• 短時間：vmstat 1 を数分、pidstat -r 1（可能なら）
• 運用：Prometheus/CloudWatch等でメモリ使用量・swap・OOM回数を継続監視
• systemd環境：journalctlでOOM関連ログの時刻を起点に相関を見る

「一晩に1回だけ落ちる」系は、再現条件を作り直すより、次に起きるまでの準備の方が効果的です。計測の仕込みを先に入れると、次の章で“原因の種類”が見えてきます。

第4章：伏線① メモリ不足の犯人はRAMだけじゃない――ページキャッシュ／スラブ／匿名メモリの見取り図

「freeで空きが少ない＝不足」だけで判断すると、対策がブレます。Linuxのメモリは、空いているならキャッシュに使う設計です。問題は“使っていること”ではなく、必要なときに回収できるかと、回収しても足りないほど増えるかです。

ページキャッシュ：空きが少なく見える最大要因

ディスクI/Oを減らすため、読み込んだファイルはページキャッシュとしてRAMに残ります。free の buff/cache が増えるのは自然で、MemAvailable が確保できていれば直ちに悪ではありません。逆に、MemAvailable が落ち、回収が追いつかない状態が危険です。

スラブ（Slab）：カーネル内部の“道具箱”が肥大する

ネットワーク、ファイルシステム、inode/dentry、各種キャッシュなど、カーネルが内部で使うメモリが Slab です。/proc/meminfo の Slab、SReclaimable（回収可能寄り）、SUnreclaim（回収しづらい）を見ると、ユーザー空間ではなくカーネル側が圧迫している兆候が分かります。

• slabtop：どのキャッシュが増えているかを俯瞰
• /proc/slabinfo：詳細（読み取りに注意しつつ）

大量の小さなファイルを高速に作る・消す、巨大ディレクトリを走査する、特定のワークロードが偏る――こうした条件でスラブが増えることがあります。アプリを疑う前に、ワークロードの形も伏線として回収しておくべきです。

匿名メモリ（Anon）：ヒープ、スタック、JIT、バッファが正体

プロセスが確保するヒープやスタック、ランタイムが抱えるメモリ（JIT/GCヒープなど）は匿名メモリとして増えやすく、回収は簡単ではありません。/proc/PID/smaps_rollup の Anon や、smem のPSSが増え続けるなら、アプリ・ランタイム側の設計（読み込み方法、バッチサイズ、並列度、キャッシュ戦略）へ踏み込みます。

“クールダウン”の誤解：キャッシュを消せば直る、は再発する

緊急対応として一時的にメモリを空けたい誘惑は分かります。ただし、ページキャッシュを強制的に落とす操作は、根本原因を消すものではなく、次のI/O増・遅延増の引き金にもなります。ここでの狙いは、キャッシュを敵にすることではなく、何が増えているかを分類して、次の章の切り分けに繋げることです。

この章までで、少なくとも次の問いが言語化できるはずです。「増えているのは、プロセスの匿名メモリか？ カーネル側（スラブ）か？ それともページキャッシュか？」――ここが分かると、打ち手は劇的に絞れます。

第5章：伏線② “リークっぽさ”の正体――増え続けるRSSを、アプリ・依存ライブラリ・ワークロードで切り分ける

メモリ問題で一番ややこしいのは、「増えているように見える」現象が複数混ざることです。現場の頭の中で、こんな会話が起きがちです。

• 「やっぱりメモリリーク？ でも昨日は平気だったんだよな」
• 「いや、キャッシュが増えてるだけじゃない？」
• 「とにかく再起動で収束させよう。…でもまた明日、同じだ」

この章のゴールは、“リーク”という言葉を雑に使わないことです。言い換えると、増え方を観察して「どのタイプの増加か」を分類し、次の打ち手（修正／設定／設計変更）に繋げます。

まず増え方を型に落とす：階段型／直線型／スパイク型

ここで大事なのは、「増えている＝バグ」と即断しないことです。例えばページキャッシュや一時バッファは増えます。問題は、戻るべきものが戻らない、または、上限がないことです。

RSSだけで決めない：匿名/ファイル/共有を見て“犯人像”を固める

プロセスのメモリは、ざっくり匿名（ヒープ等）とファイルマップ（mmap等）に分かれます。匿名が増えているならアプリ/ランタイム側、ファイルマップが増えているなら読み込み方やキャッシュ、共有が大きいならライブラリやページ共有の影響が疑えます。

• /proc/PID/smaps_rollup：Anon/File/Sharedの方向感をつかむ
• pmap -x PID：どの領域が肥大しているかを見る
• smem（導入できる場合）：共有を按分したPSSで「本当に食ってる」を見る

「そこまでやるの？」と思うのも自然です。ただ、ここをサボると、対策が“運”になります。増設や再起動で一旦は収束しても、根が残ります。

依存ライブラリと“返しているのに減らない”問題

実装が正しく free していても、プロセスの常駐メモリ（RSS）がすぐには減らないことがあります。一般に、メモリアロケータは解放した領域をプロセス内部の再利用プールに残し、OSへ即座に返さない場合があります。その結果、「処理は終わったのにRSSが高止まり」に見えることがあります。

だからこそ、切り分けの問いはこうです。

• 次のリクエスト/ジョブで、そのメモリは再利用されるか（ピークが増え続けるのか）
• ピークが日々更新されるのか（上限がないのか）
• 特定入力や特定時刻にだけ跳ねるのか（スパイクの要因があるのか）

「戻らない＝即バグ」と決めない一方で、「増え続ける＝放置できない」も事実です。次章では、そもそも増えないようにする設計（上限の設計）に踏み込みます。

第6章：伏線③ いきなり増設しない――上限を設計に落とす（バッチ分割、ストリーミング、ワーカー数、キュー制御）

「メモリを増やせば解決する」という助言が刺さらないのは、現場が“止められない・戻せない・検証が重い”現実を知っているからです。増設は最終手段として否定しませんが、まずは上限（予算）を設計に埋め込むほうが、再現性と安全性が上がります。ここが、後半で語る“契約・構成”の相談ポイントにも直結します。

バッチ分割：1回で全部やらない、を仕様にする

データ処理や検索、画像/ログ解析などでよくあるのが「全部読み込んでから処理」の形です。入力が大きくなるほど、ピークメモリが跳ね上がります。対策はシンプルで、分割単位を設けてピークを抑えることです。

• 1件ずつ処理して逐次出力する（集計もストリーム化する）
• ページング/カーソルで取得し、上限件数を決める
• “全件保持”が必要な箇所だけ、代替（外部ストア、オンディスク）を検討する

このとき、「処理が遅くなるのでは？」という不安が出ます。そこは健全な疑いです。実際には、メモリ圧迫が起きると swap やGCで遅延が爆発し、結果的にスループットが落ちます。先にピークを抑える設計を入れる方が、全体として安定して速いことが多いです。

ストリーミング：結果の“溜め込み”をやめる

Web/APIでもバッチでも、メモリを食うのは「処理」そのものより、「処理結果を配列に積み続ける」行為であることが少なくありません。対策は、結果を逐次返す・逐次書く設計に寄せることです。

• レスポンスの一括生成ではなく、ページングや段階出力を検討する
• ファイル出力は一括バッファではなく、逐次書き込みにする
• 中間データをオンメモリに置く前提を疑い、外部ストア/一時ファイルを使う

「そんなの理想論では？」と思うのも分かります。だからこそ、“全部ストリーム”ではなく、危険な箇所だけを絞って修正するのが現実的です。

ワーカー数：並列化はメモリを“回数分”使う

CPUが余っていると、つい並列度を上げたくなります。しかし、ワーカー数を2倍にすると、メモリも単純に2倍とは限らず、キャッシュやバッファ、接続プールが増えてピークが想定外に跳ねることがあります。

ここまでの話は「設計のきれいごと」ではなく、障害時に取れる選択肢を増やすための“ダメージコントロールの仕込み”です。次章では、OSと実行環境側での設定（ブレーキとストッパー）に踏み込みます。

第7章：OS側で詰まりをほどく――overcommit、swappiness、THP、ulimit、OOMスコアの「効く設定」

「設定をいじるのは怖い」――その感覚は正しいです。特に本番で、理由なく値を変えるのは危険です。ただし、メモリ問題はアプリだけでは完結しません。OS側には、安全にクールダウンさせるための“ブレーキ”が用意されています。ここでは“何を変えると何が変わるか”の因果を、できるだけ誤解なく整理します。

overcommit：確保を許すか、早めに断るか

Linuxは、実メモリが足りなくても「確保要求」を一旦通す（遅延確保）設計を取る場合があります。これが overcommit の考え方です。方針次第で、ENOMEMが早く出る（安全に断る）か、後でOOMに飛ぶ（後から破綻する）かの傾向が変わります。

• 「早めに失敗させたい」要件なら、overcommit方針の見直しが論点になる
• 「とにかく落としたくない」要件なら、OOMに至る前の余裕（設計・監視）が論点になる

現場の意思決定としては、「どちらが良い」ではなく、どちらが運用しやすいかです。バッチなら早期失敗の方がリカバリしやすいことが多く、常時サービスならOOM回避を優先して設計することが多い。ここは一般論で決めず、案件の性質で決めます。

swappiness：swapをどう使うか（使わない、ではなく“どう使うか”）

swappiness は、メモリ圧迫時にswapへ退避する傾向に関わります。swapを完全に否定すると、ピーク時にOOMへ一直線になりやすい一方、swapに寄りすぎると遅延が大きくなります。重要なのは、サービスのSLOに合わせて「許容できる遅延」と「許容できない停止」を天秤にかけることです。

ここでの基本姿勢は、swapの存在だけで安心しないことです。swapは“最後の堤防”にはなりますが、堤防に頼り切ると応答が崩れます。第8章で、swapを運用設計に落とす話に進めます。

THP（Transparent Huge Pages）：遅延とメモリ挙動に影響することがある

THPは、ページサイズを大きく扱うことで効率を狙う仕組みですが、ワークロードによっては遅延の揺れやメモリ確保の挙動に影響することがあります。ここで強調したいのは、THPが常に悪いという話ではなく、“効く/効かない”が案件依存だという点です。観測（遅延、メモリ断片化の兆候、ピーク時の挙動）とセットで扱います。

ulimit：プロセスごとの上限で“暴走を止める”

ulimit（リソース制限）は、無制限にメモリを食わせないための手段になり得ます。ただし、制限の種類によって効き方が異なり、OSやランタイムの挙動に左右されます。重要なのは、上限を入れる目的が「落とす」ことではなく、落ち方を制御して被害を局所化することだという点です。

• アプリ単体の暴走を止めて、ホスト全体の巻き込みを避ける
• 制限超過時のエラー（ENOMEM等）をアプリが扱えるようにする

「制限したら結局落ちるじゃん」という反応も自然です。ただ、ホストごと落ちて復旧が長引くより、プロセス単位で収束させられるなら、現場の負担は大きく下がります。

OOMスコア：守るべきプロセスを守る（ただし万能ではない）

OOM Killer は、メモリが枯れたときに“誰かを落として守る”仕組みです。重要プロセスが落ちると復旧が重くなるため、OOM時に守りたいプロセスと、落としてよいプロセスを整理する発想は有効です。ただし、これも一般論の魔法ではなく、プロセス間依存や監視・自動復旧の設計とセットです。

この章の結論はシンプルです。OS設定は“裏技”ではなく、設計で作った上限と合わせて初めて効くストッパーです。次の章では、swapを「悪者か味方か」ではなく、運用上の安全装置として扱います。

第8章：swapは悪者じゃない――“堤防を築く”ための使い方（zram/ディスクswap、スロッシング回避、緊急退避の設計）

メモリ不足の議論で、swapは極端に扱われがちです。「swapを入れたら遅くなる」「swapがあるから大丈夫」――どちらも半分だけ正しい。swapは、万能薬ではなく、最後の堤防です。堤防として機能させるには、“いつ使わせるか”と“使い過ぎたらどう抑え込むか”を決める必要があります。

まず言葉をそろえる：swapが救うのは「停止」ではなく「瞬間的な圧迫」

swapは、RAMが足りない瞬間に、使われにくいページを退避させることでプロセスを生かす仕組みです。したがって、次のようなケースでは有効になりやすいです。

• 短時間のスパイク（バッチ開始直後、デプロイ直後、キャッシュ温まり前）
• 一時的な並列増（リトライ集中、キュー詰まり）
• メモリ断片化や一時領域が絡む“ピークだけ高い”ワークロード

逆に、常にメモリが足りない状態（恒常的な圧迫）では、swapは延命しつつ遅延を増やし、結果的に障害対応を重くします。ここで必要なのは、「swapで粘る」ではなく「swapが出始めたら負荷を落とす・入力を絞る・ジョブを分割する」などの運用ブレーキです。

スロッシングを見逃さない：遅いのではなく“終わらない”状態

swapが過剰に使われると、ページの入れ替えが支配的になり、CPUがI/O待ちに寄っていきます。体感としては「遅い」よりも「応答が戻らない」「監視もSSHも重い」です。ここは感覚で判断せず、次の観測で“状態”を定義します。

• vmstat 1 の si/so（swap in/out）が継続して大きい
• wa（I/O待ち）が高止まりし、r（実行待ち）も増える
• free -h で swap 使用量が増え続け、回復しない

この状態に入ったら、「原因を探す」より先に被害最小化を優先します。ジョブの並列度を落とす、入力を制限する、重い処理を止める――第6章で設計した上限が、ここで効きます。

zramとディスクswap：目的が違う

「どちらが正解か」ではなく、何を守るために置くかで選びます。SLO上、停止が最悪なら堤防を厚くしつつ、スロッシングに入る前に負荷を抑え込む運用が必要です。逆に遅延が最悪なら、堤防を薄くして早期に失敗させ、ジョブ再実行やリトライ設計で回す方が安全な場合もあります。

運用設計としてのswap：しきい値と自動化で“場を整える”

swapを入れるなら、「どの状態になったら、誰が、何をするか」まで決めないと、深夜対応が長引きます。例えば次のように、しきい値を定義します。

• swap使用率が一定値を超えたら、バッチ投入を止める／ワーカー数を減らす
• swap in/out が継続したら、重い処理をキューに戻し、バックプレッシャを強める
• OOMが出る前に、重要度の低いジョブを抑え込み、重要系を守る

ここまでやって初めて、swapは“延命”ではなく被害最小化の道具になります。次章では、コンテナやクラスタ環境で、この制御がどうズレるかを回収します。

第9章：コンテナ/クラスタの伏線回収――cgroup v2、requests/limits、systemd-oomd、KubernetesのOOMを“仕様”として扱う

「ホストは生きてるのに、コンテナだけ落ちる」「PodがOOMKilledになったけど、ノードは余裕っぽい」――ここで混乱が起きるのは自然です。コンテナやクラスタでは、“メモリの世界”がホスト全体ではなく、cgroup（制限の枠）単位で区切られます。つまり、メモリ不足は「全体の容量」ではなく「割り当てられた予算」の問題になります。

まず切り分ける：ホストOOMか、cgroup OOMか

同じ “Out of memory” でも、意味が違います。まず、どの枠で起きたかを確認します。

ここを外すと、対策が空回りします。ホストが余裕なら増設しても意味が薄く、逆にホストが枯れているならPodのlimits調整だけでは巻き込みが止まりません。

cgroup v2 の考え方：上限（max）と“抑え込み”（high）

cgroup v2 では、強制上限（例：memory.max）に達すると、その枠内でOOMが起き得ます。一方、強制上限に至る前に“圧力が高い状態”を検出し、抑え込み（例：memory.high）でスローダウンさせる設計も可能です。

現場の意思決定として重要なのは、次の二択を明示することです。

• 早めに抑え込み、遅くしてでも落とさない（ただし遅延は許容する）
• 抑え込みは弱め、一定ラインを超えたら落として復旧させる（ただし再起動は許容する）

ここが曖昧だと、障害時に「遅いのも嫌、落ちるのも嫌」で議論が過熱し、結果として現場が疲弊します。SLOと業務影響を踏まえ、仕様として決める領域です。

systemd-oomd：落とすのはカーネルだけじゃない

Ubuntuを含むsystemd環境では、メモリ圧力に応じて systemd 側がプロセスやサービスを止める設計が入ることがあります。ここでのポイントは、「ログの見え方が変わる」ことです。カーネルOOMのログだけ追っていると、別のレイヤーで落とされているケースを見逃します。

したがって、障害解析では「落ちた」の事実だけでなく、どのレイヤーが“抑え込み”を実行したかを確認します。これが分かると、「OOMだから増設」ではなく、「抑え込みが効く設計に寄せる」「守るべきサービスを守る」など、実装に落とせます。

Kubernetes：requests/limitsは“課金”ではなく“生存戦略”

Kubernetesでは、requests がスケジューリングの前提、limits が上限（予算）になります。limitsが低すぎると、ノードが余裕でもPodは枠内でOOMします。逆にrequestsが低すぎると、詰め込まれてノード全体が苦しくなり、別のPodを巻き込みます。

ここで押さえるべき論点は次の通りです。

• ピークメモリを見積もり、limitsに反映しているか（根拠は計測か）
• requestsが現実より低く、過密配置で“ノード側の圧迫”を起こしていないか
• OOM時に再起動させる設計か、落とさない設計か（状態の持ち方が変わる）

「また設定項目が増えるだけでは？」という疑いは健全です。ただ、この設計がないと、障害が起きた瞬間に“運任せ”になります。requests/limitsは運用を増やすためではなく、落ち方を制御して、被害を局所化するための仕組みです。

一般論の限界が出るポイント：複数サービスの同居と優先度

クラスタでは、複数サービスが同じノードに乗ることが多く、障害時に「どれを守るか」が露わになります。重要系（認証、DB、ゲートウェイ）を守るのか、バッチを優先するのか。これを決めていないと、OOMのたびに場が荒れ、調整コストが積み上がります。

この段階で、具体的な案件（同居構成、SLO、リリース頻度、夜間体制）が絡み、「一般的にはこう」が通用しにくくなります。ここまでの計測と設計の材料を持った上で、個別設計に落とし込む必要があります。

第10章：帰結：メモリは“増やす資源”ではなく“守る予算”――計測→制御→再発防止で、止められない現場を楽にする

ここまで見てきた通り、ENOMEM(12) や OOM は「メモリが足りない」という一言で片づけられる現象ではありません。アプリの割り当て失敗、カーネルの強制終了、コンテナの予算超過、swapの使い過ぎによる遅延崩壊――同じ“メモリ不足”の顔をして、原因の層が違います。

だから、帰結はこうなります。メモリは「余ったらラッキーな資源」ではなく、守るべき予算（バジェット）です。予算は、見積もり（計測）し、上限（制御）を入れ、逸脱したら早めに知らせる（監視）ことで初めて、現場の夜を穏やかにできます。

最短で“収束”させるための一本道：計測→分類→上限制御→運用の歯止め

対策を一本の線にすると、次の順番が最も崩れにくいです。

1. 計測：誰が、どの内訳（匿名/ファイル/スラブ/キャッシュ）で増えているかをつかむ
2. 分類：ENOMEMか、カーネルOOMか、cgroup OOMかを切り分ける
3. 上限制御：入力サイズ、並列度、バッチ分割、キューでピークを抑える
4. ストッパー：OS/コンテナの制限と優先度で、巻き込みを最小化する
5. 運用ブレーキ：swapやメモリ圧力の兆候で負荷を抑え込み、深夜対応を短くする

この順番の良さは、現場の本音に効くところです。「また新しい設定？」「運用が増えるだけでは？」という不信感に対して、計測と上限制御が先にあると、変更が“理由のある変更”になります。理由がある変更は、引き継げます。属人化しません。

“一般論”が効かなくなる境界：SLO・同居構成・夜間体制

一方で、ここから先は一般論の限界がはっきり出ます。例えば、同じENOMEMでも、次の前提が違えば正解が変わります。

ここまで来ると、「スワップを増やすべきか」「limitsをどこに置くか」「同居を許すか」「アプリを直すか、設計で抑えるか」は、単なるチューニングではなく、契約・構成・運用責任の設計になります。

次の一歩：悩みが“具体”になったときが相談のタイミング

読者が本当に困るのは、答えが一つに決まらない場面です。

• 「OOMを防ぎたいが、遅延も増やしたくない。どこで折り合う？」
• 「Kubernetesのrequests/limitsをどう置けば、巻き込みが減る？」
• 「リーク疑いがあるが、止められない。どうやって安全に切り分ける？」
• 「夜間体制が薄い。自動で“抑え込み”まで回したい」

ここは一般論だけで背中を押すのが難しい領域です。業務影響、SLO、データの重要度、既存のレガシー制約、監視基盤、チーム体制――現場の条件で最適解が変わります。

だからこそ、具体案件で迷った段階で、株式会社情報工学研究所への相談・依頼を検討してください。単に「メモリを増やす/減らす」ではなく、計測、設計、運用、そして巻き込み最小化までを含めて、現場の意思決定ができる材料に落とし込みます（無料相談フォーム：https://jouhou.main.jp/?page_id=26983 ／電話：0120-838-831）。

“困ってから”ではなく、“困りそうな形が見えたとき”が、最もコストが小さく、最も静かに収束させやすいタイミングです。

付録：主要プログラミング言語別――メモリ不足を招きやすい落とし穴と対策の観点

メモリ障害の再発を減らすには、OS/コンテナだけでなく、言語ランタイムやライブラリの“クセ”を前提に設計する必要があります。ここでは「言語ごとに、どこで予算を超えやすいか」を整理します。

C / C++

• 落とし穴：解放漏れ（リーク）、二重解放、巨大連続確保、メモリ断片化、独自アロケータの癖
• 観点：ピークが入力サイズと直結しやすい。スレッド数・バッファ数が増えると線形に増えやすい
• 対策：入力上限とバッチ分割、アロケーション回数削減、プロファイル（heap/alloc）、失敗時のハンドリング（ENOMEM時に安全に抜ける）

Rust

• 落とし穴：所有権で安全でも、設計上の“溜め込み”は起きる（Vec/HashMapの肥大、キャッシュ無制限、clone多用）
• 観点：安全性とメモリ効率は別問題。非同期/並列で同時保持が増えるとピークが跳ねる
• 対策：容量上限、ストリーミング、Backpressure、メモリプロファイル、必要ならアロケータ設定や断片化対策を検討

Go

• 落とし穴：GCのヒープ成長、巨大スライス/マップ、参照保持で解放されない、ゴルーチンの増殖、バッファの使い回し不足
• 観点：RSSが即座に減らないことがある。ピーク時にGCが追いつかず遅延が増える場合がある
• 対策：同時実行制御、バッチ分割、キャッシュ上限、不要参照の切断、ヒープ/GCのメトリクス監視、入力サイズ制限

Java / Kotlin / Scala（JVM系）

• 落とし穴：ヒープ不足、メタスペース不足、スレッドスタックの積み上がり、オフヒープ（DirectBuffer等）の肥大、GC停止の増大
• 観点：JVMのヒープ設定だけ見ていると、ネイティブ領域やDirectメモリで枯れることがある
• 対策：ヒープ・メタスペース・Direct・スレッド数の予算配分、プロファイル（ヒープダンプ等）、バッチ分割、キャッシュ上限、コンテナ上限との整合

Python

• 落とし穴：巨大オブジェクト（リスト/辞書）、データフレーム等の一括保持、コピーの連鎖、参照保持（グローバル/キャッシュ）、プロセス分岐でのメモリ複製
• 観点：一括読み込みがピークを作りやすい。並列処理（プロセス/ワーカー）でメモリが回数分増えやすい
• 対策：ストリーミング、ジェネレータ活用、バッチ分割、ワーカー数制限、入力サイズ上限、キャッシュ明示、監視でピークを把握

Node.js（JavaScript）

• 落とし穴：ヒープ上限到達、Promise/キューの溜め込み、ログ/バッファの蓄積、同時リクエストの集中、GC負荷での遅延増
• 観点：イベントループが詰まると“遅延”として先に出る。ヒープ上限に近づくとGCで応答が荒れやすい
• 対策：バックプレッシャ、同時実行制御、ストリーミング、キュー上限、入力制限、ヒープ/GCメトリクス監視

PHP

• 落とし穴：memory_limit到達、配列の肥大、文字列結合の多用、巨大レスポンス生成、バッチをWeb実行してピークが跳ねる
• 観点：Webプロセスは同時実行数で総消費が増える。1リクエストの上限設計が重要
• 対策：バッチはCLIへ分離、ページング/分割、同時実行制御、キャッシュ上限、プロファイル、Web/CLIそれぞれの上限を設計

.NET（C# など）

• 落とし穴：LOH（大きなオブジェクト）による断片化、非同期での同時保持、キャッシュ/バッファ無制限、GC設定不整合
• 観点：ピーク時に大きな配列やバッファを確保すると、断片化やGC負荷が表面化しやすい
• 対策：バッファ再利用、分割処理、同時実行制御、プロファイル、コンテナ上限との整合、監視で兆候を捕まえる

言語に共通する最重要ポイント：上限の設計と“巻き込み防止”

どの言語でも、最後は同じ問いに戻ります。

• 入力サイズと並列度に上限はあるか
• ピークが来たときに、処理を抑え込みできるか
• 落ちたときに、被害が局所化される設計か
• 次に起きたとき、原因が分かる計測が仕込まれているか

これらは、実装だけでなく、環境（Ubuntu設定、コンテナ制限、クラスタ同居、夜間体制）と一体です。個別案件で「どこに上限を置くべきか」「何を守るべきか」に悩んだら、株式会社情報工学研究所への相談・依頼を検討してください（無料相談フォーム：https://jouhou.main.jp/?page_id=26983 ／電話：0120-838-831）。設計と運用を含めて、現場が納得できる“予算の置き方”に落とし込みます。