Linuxのメモリ状況を正しく読む運用点検｜free/vmstatで枯渇を見極める【2026年版】

「空きメモリが少ない」は必ずしも問題ではない

Linuxサーバーを運用していると、freeコマンドの出力を見て「空きが少ない、まずいのでは」と焦る場面があります。しかし、LinuxのメモリはWindowsとは異なる発想で管理されています。未使用のメモリは「もったいない」と判断し、ファイルシステムのキャッシュなどに積極的に充当するのがLinuxの設計思想です。そのため、free列の値が小さいこと自体は正常な状態であることがほとんどです。

問題になるのは、キャッシュを解放しても新たなプロセスにメモリを割り当てられない「本当の枯渇」です。ここを見誤ると、不要なサーバー増強や場当たり的なプロセス再起動を繰り返すことになります。本記事では、freeとvmstatの出力を正確に読んで枯渇の有無を判断する手順を、現行の標準環境に即して整理します。

free -h の出力フォーマットを理解する（現行版）

RHEL 8・Rocky Linux 9・Ubuntu 20.04以降など、現在主流のディストリビューションが採用するprocps-ng 3.3.10以降では、freeの出力フォーマットが変わっています。旧来の「-/+ buffers/cache」行は廃止され、代わりにavailable列が追加されました。

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           15Gi        4.2Gi       8.1Gi       512Mi       3.1Gi      10.7Gi
Swap:          7.9Gi          0B       7.9Gi

各列の意味は次のとおりです。

• total：カーネルに認識されている物理メモリ総量
• used：プロセスが実際に使用中のメモリ（buff/cacheを除いた値）
• free：一切使われていない領域。通常は小さくて当然
• shared：tmpfsなど複数プロセスが共有するメモリ
• buff/cache：バッファとページキャッシュの合計。カーネルが管理し、必要時に解放される
• available：スワップを使わずに新プロセスへ割り当て可能な推計値。/proc/meminfoのMemAvailableから算出される

運用上で最優先に注目するのはavailableです。freeがほぼゼロでもavailableが十分あれば問題ありません。逆にavailableが残り数百MB以下に縮小している場合は、本格的なメモリ圧迫のサインです。

availableを基準にした枯渇の判断フロー

ステップ1：availableの割合を計算する
目安として「totalの20%を下回ったら要注意、10%以下なら即対処」という基準が運用現場でよく使われます。totalが16GBのサーバーなら、availableが3.2GB（20%）を切ったら原因調査を開始するのが妥当です。

ステップ2：Swapの使用状況を確認する
Swapのusedがゼロでなく増加傾向にある場合は、物理メモリが不足してカーネルがスワップに退避している状態です。スワップの頻繁な発生（スワッピング）はI/Oレイテンシを急増させ、サービス全体を劣化させます。

ステップ3：プロセス別の消費量を特定する
availableの低下原因が確認できたら、ps aux --sort=-%mem | head -20でメモリ消費上位プロセスを洗い出します。Javaアプリケーションのヒープ肥大・Webサーバーのワーカー数過多・メモリリークなど、原因に応じて対処が変わります。

vmstatで時系列の傾向を掴む

freeはスナップショットですが、vmstatは一定間隔でメモリ・スワップ・I/Oの変化を継続表示できます。一過性の急増なのか、徐々に積み上がっているのかを区別するために活用します。

$ vmstat 5 10
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 8308736 102400 3276800    0    0     4    12  150  300  3  1 96  0  0
 0  0      0 8304640 102400 3276800    0    0     0     8  140  280  2  0 98  0  0

引数「5 10」は「5秒間隔で10回表示」を意味します。注目すべき列は以下の3点です。

• swpd：スワップ使用量。増加し続けていればメモリ圧迫が進行中
• si / so：スワップイン／アウトの発生量（KB/秒）。ゼロでない状態が続くとI/O劣化の直接原因になる
• free：瞬間的な空きメモリ。単体では判断材料にならないが、急減を検出するのには有効

siとsoが継続的に発生している状態は「スワッピング中」であり、サービスの応答悪化と直結します。この状態を確認したら、原因プロセスの特定と対処を優先してください。

OOM Killerの介入を確認し復旧する

メモリ枯渇が極限に達すると、カーネルのOOM Killer（Out-of-Memory Killer）が自動的にプロセスを強制終了します。突然プロセスが消えた場合は、まずジャーナルログで確認します。

$ journalctl -k --since "1 hour ago" | grep -i "oom\|killed process"

「Out of memory: Killed process XXXX」という行があれば、OOM Killerの介入です。どのプロセスが終了させられたかを把握し、再起動が必要なサービスを特定します。systemdが管理するサービスであれば、systemctl status サービス名で状態を確認し、必要ならsystemctl restart サービス名で復旧できます。

根本対策としては次の選択肢があります。

• systemdのMemoryMax=ディレクティブでプロセスのメモリ上限を制限し、OOM Killerの対象を制御する
• アプリケーション設定でワーカー数・キャッシュサイズ・ヒープ上限を見直す
• スワップ領域を追加して時間的猶予を確保しつつ、根本原因を並行調査する
• 物理メモリの増設またはスケールアウトを検討する

スワップ追加はあくまで応急措置です。スワッピングが常態化するとI/O負荷が上がり別の問題を引き起こします。スワップを増やしても根本解決にはならない点は、運用担当者として押さえておく重要な注意点です。

2026年の現行環境における差分と注意点

cgroup v2とメモリ管理
現行のsystemd（v248以降）はデフォルトでcgroup v2（Unified Hierarchy）を使用します。コンテナやサービス単位のメモリ制限は/sys/fs/cgroup/配下で確認でき、memory.currentファイルが各cgroupの現在使用量を示します。コンテナ環境（DockerやPodman）ではホスト側のfreeコマンドだけでなく、コンテナ内のcgroupメモリ統計も合わせて確認する必要があります。

-h オプションが実質的な標準に
現行版では-h（human-readable）が実務上の標準となり、GiBやMiBで読みやすく表示されます。旧来のドキュメントにある-m（メガバイト固定）は今でも使えますが、大容量メモリ環境では桁数が増えて読みにくくなります。日常的な点検はfree -hで十分です。

/proc/meminfo との対応
freeの出力は/proc/meminfoを加工したものです。より詳細な値（Slab・KernelStack・HugePagesなど）が必要な場合は直接参照できます。特にMemAvailableの値がカーネル自身の推計であり、free -hのavailable列の根拠となっています。

zramによるスワップ圧縮の普及
Raspberry PiやUbuntu Desktopなど、メモリ搭載量の少ない環境では、zram（メモリ上の圧縮スワップ）がデフォルトで有効になっているケースが増えています。freeでSwapの使用が見えても、ディスクI/Oは発生していない場合があります。スワップの実体がディスクかzramかはswapon --showで確認できます。zramが使われている環境では、vmstatのsi/soの解釈にも注意が必要です。