Linuxのメモリ不足・swap使用を切り分ける手順

Linuxでメモリ不足が疑われるときは、freeの値やswap使用量を一つだけ見て原因を決めず、利用可能量、swapの動き、プロセス別の値、OOM記録を同じ時刻帯で確認します。このガイドは読み取り中心の原因確認に絞り、メモリ解放やprocess・serviceの状態を変える操作は扱いません。

原因確認と復旧操作を明確に分け、表示結果、確認時刻、タイムゾーンを記録してください。コマンドのoptionや表示は環境ごとに異なるため、導入されている版のman pageを優先します。

「freeが少ない」だけではメモリ不足と断定しない

Linuxは空いているメモリをpage cacheなどにも利用します。そのため、未使用量を示すfree が少ないことだけでは、アプリケーションがすぐ使えるメモリまで不足しているとは断定できません。cacheやreclaim可能な領域も考慮したavailable、swap、監視の時系列を組み合わせて判断します。

1. 物理メモリとswapの全体像を確認する

free -h

total、used、free、buff/cache、availableと、swapのtotal・used・freeを読みやすい単位で確認します。available は、page cacheやreclaim可能なslabのうち全てが回収できるわけではない点も考慮し、swapせず新しいアプリケーションを開始するために利用できるメモリ量を推定した値です。単一の固定しきい値ではなく、平常時や監視基準と比較します。

2. MemAvailableとswapの元データを確認する

grep -E 'MemTotal|MemAvailable|SwapTotal|SwapFree' /proc/meminfo

/proc/meminfo から、物理メモリ総量、利用可能量の推定、swap総量、swap空きを確認します。表示単位を含めて記録し、free -h の値と対応させます。swapが使われていることだけで現在のメモリ圧迫を断定せず、次のswap in/outも確認します。

3. swap in/outを一定間隔で確認する

vmstat 1 5

vmstat 1 5 は1秒間隔で合計5回reportを表示します。最初のreportはboot以降の平均で、追加のreportが各1秒のsampling期間を示します。si はdiskからswap inした量、so はdiskへswap outした量を毎秒の値として表示します。

一度だけsi やso が0でも、問題がないとは断定できません。発生時刻の前後で複数回確認し、MemAvailable、応答遅延、監視の時系列と照合してください。

4. プロセス別のRSS・VSZ・%MEMを確認する

ps -eo pid,ppid,cmd,%mem,rss,vsz --sort=-rss

resident set sizeが大きい順にprocessを並べます。RSSはprocessが使用するnon-swappedの物理メモリをKiB単位で、VSZはvirtual memory sizeをKiB単位で示し、%MEM はRSSと物理メモリの比率です。ただしRSSは一部のprocess領域を数えず、共有pageも含み得ます。VSZには現在residentではないmappingや予約領域も含まれるため、RSS・VSZのどちらも「そのprocessだけの実メモリ消費量」と単純に同一視しません。

cmdには引数、path、credentialなどの機密情報が含まれる可能性があります。出力を共有する前に内容を確認し、組織の規程に従ってマスクしてください。

5. 現在のbootに属するOOM記録を確認する

journalctl -k -b --no-pager | grep -i -E 'oom|out of memory|killed process'

systemd journalを使う環境では、現在のbootに属するkernel messageからOOMに関連する文字列を確認します。記録があれば、時刻、対象process、同時刻のMemAvailableやswap、アプリケーションの症状と照合します。

journalの保存設定、権限、rotation、systemdを使わない環境などにより、OOM記録を取得できない場合があります。出力がないことだけでOOMがなかったとは断定せず、利用できるkernel logや監視記録の範囲も記録します。

症状別に観測結果を整理する

MemAvailableが継続して少ない

swap in/out、応答遅延、RSS上位processの変化を同じ時刻帯で比較します。一時点の順位だけで原因processを断定しません。

swap使用量がある

swapのusedだけでなく、vmstat の追加reportでsi・so が継続しているか、平常時と比べて変化したかを確認します。

OOM記録がある

OOM発生時刻、対象process、影響範囲、直前の監視値を並べます。記録されたprocessだけを原因と決めず、その時点までのメモリ推移と処理量を確認します。

一時点だけで原因を断定しない

メモリ使用量は処理内容やcacheによって変化します。各コマンドの結果に観測時刻とタイムゾーンを添え、同じ条件で取得した複数時点の値、監視グラフ、直近の処理量や変更時刻と比較します。観測した事実、原因の推測、未確認事項を分けて管理者へ引き継ぎます。

原因確認と復旧操作を分離する

この手順で行うのは、利用可能メモリ、swapの動き、process別の値、OOM記録を観測して原因候補を絞るところまでです。メモリやswapの設定、process・serviceの状態を変える操作は、影響範囲、組織の承認手順、復旧計画を確認し、権限を持つ管理者が別途判断します。

共有前に機密情報をマスクする

コマンド結果にはhostname、ユーザー名、process引数、file path、サービス名などが含まれる場合があります。元の記録は保持したまま共有用のコピーを作り、認証情報、個人情報、内部構成を示す値をマスクしてから再確認してください。

コマンド仕様の参照先

optionや表示内容は導入環境のman pageを優先し、以下のupstream一次情報も参照してください。