Linuxメモリ・ディスク確認｜free・df・du・vmstat・iostat見方

Linuxのメモリは free -h の available、ディスク容量は df -h の Use%、どこが容量を使っているかは du、遅さの原因は vmstat と iostat で確認します。 5つのコマンドはそれぞれ見ている対象が違うため、「どの数値を見て何を判断するか」を押さえておくと、調査の時間を大きく短縮できます。

この記事では、Ubuntu 24.04.4 LTS（procps-ng 4.0.4、coreutils 9.4、sysstat 12.6.1）で実行した結果を載せながら、各コマンドの見るべき列を判断表で整理します。さらに、dd と stress-ng で実際にディスク・メモリ・CPUに負荷をかけ、数値がどう変わるかを並べて示しました。「ディスクがいっぱい」「サーバーが重い」ときに調べる順番も、フロー図とワンライナー集でまとめています。

メモリ・ディスク確認コマンドの早見表

検証した環境と注意点

Docker などのコンテナ内で free や top、vmstat を実行すると、コンテナの上限ではなくホスト全体の値が表示されます。 これは /proc/meminfo がホストの情報を返すためです。コンテナに割り当てられたメモリ上限は、cgroup v2 なら cat /sys/fs/cgroup/memory.max、使用量は memory.current で確認します（この記事の検証環境はコンテナではなく仮想マシンのため、cgroup の値は表示していません）。

freeでメモリを確認する

free -h の実行結果

free -h

               total        used        free      shared  buff/cache   available
Mem:           7.8Gi       1.4Gi       2.1Gi        72Mi       4.7Gi       6.5Gi
Swap:             0B          0B          0B

「free が 2.1Gi しかない」と考える必要はありません。 buff/cache の 4.7Gi はファイルの読み書きを速くするためのキャッシュで、アプリがメモリを必要とすれば解放されます。実際に新しいアプリが使えるメモリの目安は available の 6.5Gi です。

free の便利なオプション

-m / -g で単位を固定、-w で buffers と cache を分けて表示（この環境では buffers 586MiB・cache 4252MiB）、-s 2 で2秒ごとに繰り返し表示できます。

/proc/meminfo で詳細を見る

free の元データは /proc/meminfo です。 よく見る項目だけを抜き出しました。

grep -E '^(MemTotal|MemFree|MemAvailable|Buffers|Cached|SwapTotal|Dirty|Shmem|SReclaimable)' /proc/meminfo

MemTotal:        8223868 kB
MemFree:         2211012 kB
MemAvailable:    6786688 kB
Buffers:          600276 kB
Cached:          3986064 kB
SwapTotal:             0 kB
Dirty:              4204 kB
Shmem:             73984 kB
SReclaimable:     368984 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB

プロセスごとのメモリ使用量は ps aux --sort=-rss | head で RSS の大きい順に確認できます（プロセスの調べ方は別記事で扱っています）。

dfでディスク容量とinodeを確認する

df -hT の実行結果

df -hT -x tmpfs -x devtmpfs

Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/vda       ext4      252G   33G  9.6G  78% /

（検証環境固有のマウントは省略しています）

Use% は Size ではなく「Used＋Avail」に対する割合です。 ext4 は既定で容量の5%を root 用に予約しているため、通常でも Size ＞ Used＋Avail になります。この検証環境では Size 252G に対して Used＋Avail が約43Gと大きく差があり、Use% は 78% と表示されました。仮想ディスクの割り当て方によってはこのように差が大きくなるため、残り容量は Avail と Use% で判断します。

df -i でinodeを確認する

df -i -x tmpfs

Filesystem       Inodes  IUsed      IFree IUse% Mounted on
/dev/vda       16777216 755257   16021959    5% /

inode はファイル1つにつき1つ使う「ファイルの管理番号」です。 小さなファイルが大量にできる（セッションファイル、キャッシュ、メールキューなど）と、容量が空いていても IUse% が100%になり、No space left on device で新しいファイルを作れなくなります。容量に余裕があるのにこのエラーが出たら df -i を確認します。

lsblk でディスクの構成を見る

lsblk

NAME  MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
vda   254:0    0  256G  0 disk /

（検証環境固有の読み取り専用ディスクは省略しています）

lsblk -f でファイルシステムの種類と UUID、lsblk -o NAME,SIZE,FSUSE%,MOUNTPOINTS で使用率も表示できます。df はマウントされたファイルシステム、lsblk は物理的なディスクとパーティションを見るコマンドです。

duでどこが容量を使っているか調べる

df と du の違い

df と du の合計が大きく違うときは、削除済みでも開かれたままのファイルや、マウントで隠れたファイルが考えられます。詳しい対処は別記事「Linuxでrmしても容量が減らない原因と対処法」にまとめているので、ここでは確認コマンドの要点だけ紹介します。

大きいディレクトリを順にたどる

テスト用に、ログ・キャッシュ（1バイトのファイル2,000個）・アップロードファイル・スパースファイルを作って調べました。

du -xh --max-depth=1 . | sort -h
du -sh *

7.9M    ./cache
31M ./uploads
181M    ./logs
218M    .

7.9M    cache
181M    logs
0   sparse.img
31M uploads

1バイトのファイル2,000個が 7.9M になっているのは、ext4 ではファイル1つにつき最小 4KiB のブロックを使うためです（2,000 × 4KiB ≒ 7.8MiB）。

ls と du でサイズが違うファイル

truncate -s 1G sparse.img
ls -lh sparse.img
du -h sparse.img
du -h --apparent-size sparse.img

-rw-r--r-- 1 root root 1.0G Oct  1 23:45 sparse.img
0   sparse.img
1.0G    sparse.img

スパースファイル（中身が空の領域を確保しないファイル）は、ls では 1.0G、du では 0 と表示されます。 仮想マシンのディスクイメージやデータベースのファイルでよく見られます。容量を調べるときは、実際に使っているブロック数を表す du の値を見ます。

ファイル数が多い場所を探す

du --inodes -x --max-depth=1 . | sort -n

3   ./logs
3   ./uploads
2001    ./cache
2009    .

df -i で inode が足りないとわかったら、この方法でファイル数の多いディレクトリを探します。

ncdu で対話的に調べる

ncdu -x /

ncdu（1.19）は du の結果を矢印キーでたどれるツールです（対話画面のため実行結果は省略）。d で削除（確認あり）、q で終了します。

vmstatでCPU・メモリ・I/Oの全体像を見る

vmstat 1 5 の実行結果（負荷なし）

vmstat 1 5

procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 0  0      0 2214976 600276 4355300    0    0  2652  3256 1941   29 37  5 51  7  0  0
 0  0      0 2235272 600276 4355532    0    0     0    36 1337 1507  4  2 94  0  0  0
 0  0      0 2238924 600276 4355584    0    0     0    12 1431 1645  4  3 93  0  0  0
 0  0      0 2228196 600280 4355716    0    0     0   280 1690 2246 17  6 77  0  0  0
 0  0      0 2247112 600280 4355756    0    0     0   732 1693 2174  6  5 89  0  0  0

1行目は起動してからの平均なので、判断には2行目以降を使います。 vmstat 1 5 は「1秒間隔で5回」という意味です。

単位をMiBにして横に広く表示するなら vmstat -S M -w 1 5、メモリの内訳は vmstat -s、ディスク別の統計は vmstat -d です。

iostatでディスクI/Oを見る

iostat -xz の実行結果（負荷なし）

iostat -xz 1 2

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           7.77    0.00    2.43    0.00    0.00   89.81

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz     d/s     dkB/s   drqm/s  %drqm d_await dareq-sz     f/s f_await  aqu-sz  %util
vda              0.00      0.00     0.00   0.00    0.00     0.00   20.00    268.00     0.00   0.00    0.15    13.40    1.00     12.00     0.00   0.00    0.00    12.00    0.00    0.00    0.00   0.00

-x は詳細表示、-z は動きのないデバイスを省略、1 2 は1秒間隔で2回です。vmstat と同じく最初のレポートは起動からの平均なので、2回目以降を見ます。

現在の sysstat（この環境は 12.6.1）では await が r_await と w_await に分かれ、svctm 列も表示されません。古い解説の await や svctm は、この2つと %util に読み替えます。

負荷をかけて数値の変化を見る

ここからは、意図的に負荷をかけて、各コマンドの数値がどう変わるかを確認します。

ディスク書き込み負荷（dd）

キャッシュを通さずに書き込む oflag=direct で、1GiB の書き込みを5回繰り返しました。

for i in 1 2 3 4 5; do
  dd if=/dev/zero of=big.img bs=1M count=1024 oflag=direct conv=notrunc
done &
iostat -dx vda 1 5      # 別の端末で
vmstat 1 5              # 別の端末で

iostat の主要な列（vda のみ抜粋）：

Device r/s w/s wkB/s w_await aqu-sz %util
vda 3.00 1157.00 720820.00 1.66 2.54 91.20
vda 1.00 303.00 310272.00 3.10 2.16 97.20
vda 1.00 788.00 805892.00 1.10 1.80 94.00
vda 0.00 175.00 178188.00 4.88 1.72 99.20

同じ時間の vmstat：

procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 3  2      0 3087892 600044 3509408    0    0  2469  4775 1898   28 36  5 52  7  0  0
 0  2      0 3077656 600044 3520332    0    0    52 717748 2566 4333 29 13  2 55  1  0
 2  0      0 3084196 600044 3519576    0    0    56 310272 1514 2570 13  7  1 79  0  0
 1  2      0 3086104 600044 3518528    0    0     4 806916 3247 6409  6 15  9 70  0  0
 0  2      0 3092444 600044 3518316    0    0     0 180236 1280 2328  6  3 42 48  0  0

1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.71571 s, 626 MB/s

「wa が高い・b が0でない・%util が100%近い」の3つがそろったら、ディスクI/Oが遅さの原因と判断できます。どのプロセスが書き込んでいるかは iotop（apt で導入）や pidstat -d 1 で調べます。

メモリ負荷（stress-ng --vm）

1.5GB のメモリを確保し続けるプロセスを動かしました。

stress-ng --vm 1 --vm-bytes 1500M --vm-keep --timeout 12s

--- 負荷前 free -m
               total        used        free      shared  buff/cache   available
Mem:            8031        1336        2228          72        4837        6695
Swap:              0           0           0
--- 負荷中 free -m
               total        used        free      shared  buff/cache   available
Mem:            8031        3124        1302         345        4247        4906
Swap:              0           0           0

free が 926MiB しか減っていないのに available は約1.8GiB 減りました。 足りない分はキャッシュを解放してまかなっているためで、「キャッシュは必要に応じて空く」ことが数値で確認できます。この環境はスワップがないため si/so は 0 のままでした。スワップがある環境で available が0に近づくと、vmstat の si/so が0以外になり、さらに足りなければ OOM Killer がプロセスを終了させます（dmesg | grep -i oom で確認）。

CPU負荷（stress-ng --cpu）

2コアの環境で、CPUを使い続けるワーカーを4つ動かしました。

stress-ng --cpu 4 --timeout 10s
vmstat 1 3

procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 4  0      0 2861032 600040 3743348    0    0  2515  4222 1911   28 36  5 52  7  0  0
 4  0      0 2870088 600040 3743360    0    0     0    56 1012 2010 99  1  0  0  0  0
 5  0      0 2875600 600040 3743364    0    0     0     0  896 1595 100  1  0  0  0  0

r が 4〜5（コア数2の2倍以上）、us が 99〜100、id が 0 になりました。ディスク負荷のときと違い、b と wa は 0 のままです。

負荷の種類と数値の変化まとめ

sarで過去の推移を記録する

sar は sysstat に含まれる、CPU・メモリ・ディスクの記録を取るコマンドです。 引数に間隔と回数を指定すると、その場で計測できます。

sar -u 1 2
sar -r 1 1

Linux 6.18.44-fc-v50 (vm)   10/01/26    _x86_64_    (2 CPU)

23:45:34        CPU     %user     %nice   %system   %iowait    %steal     %idle
23:45:35        all      1.50      0.00      1.00      0.00      0.00     97.50
23:45:36        all      4.55      0.00      2.02      0.00      0.00     93.43
Average:        all      3.02      0.00      1.51      0.00      0.00     95.48

23:45:36    kbmemfree   kbavail kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
23:45:37      3021588   6818592    959408     11.67    600540   3242180   1745788     21.23   2185040   2518880    101104
Average:      3021588   6818592    959408     11.67    600540   3242180   1745788     21.23   2185040   2518880    101104

Ubuntu では、インストール直後は記録が無効（/etc/default/sysstat の ENABLED="false"）です。ENABLED="true" にして systemctl enable --now sysstat すると、10分ごとの記録が始まり、後から sar -u -s 02:00:00 -e 03:00:00 のように時間帯を指定して振り返れます（この記事の環境は systemd がないため、記録の有効化は実行していません）。

「ディスクがいっぱい」「重い」を調べる順番

flowchart TD
    A[症状] --> B{どちら？}
    B -->|ディスクがいっぱい| C[df -h で Use% を確認]
    C --> D{Use% が高い？}
    D -->|高い| E[du -xh --max-depth=1 / で大きい場所をたどる]
    E --> F[find -size +100M で大きいファイルを特定]
    D -->|低いのに書けない| G[df -i で IUse% を確認]
    G --> H[du --inodes でファイル数の多い場所を探す]
    E --> I{du の合計が df より小さい？}
    I -->|小さい| J[lsof +L1 で削除済みの開かれたファイル]
    B -->|重い| K[vmstat 1 5]
    K --> L{どの数値が高い？}
    L -->|r がコア数超え・us/sy 高| M[CPU：top や ps で使用率の高いプロセス]
    L -->|b が0以外・wa 高| N[ディスク：iostat -xz 1 で %util と await]
    L -->|si/so が0以外| O[メモリ：free -h の available と ps の RSS]
    L -->|st 高| P[仮想化基盤側の混雑]

ディスク容量のワンライナー集

# どのディレクトリが大きいか（/ 配下、同じファイルシステム内のみ）
du -xh --max-depth=1 / 2>/dev/null | sort -h | tail -15

# 100MB を超えるファイルをサイズ付きで
find / -xdev -type f -size +100M -exec ls -lh {} + 2>/dev/null | awk '{print $5, $9}'

# 大きい順に上位20ファイル（バイト単位）
find / -xdev -type f -printf '%s %p\n' 2>/dev/null | sort -nr | head -20

# 7日より古いローテート済みログ
find /var/log -type f -mtime +7 -name '*.gz'

# ファイル数が多いディレクトリ
du --inodes -x --max-depth=2 / 2>/dev/null | sort -n | tail -10

# 削除済みだが開かれたままのファイル
lsof -nP +L1

# journald のログ容量と整理
journalctl --disk-usage
journalctl --vacuum-size=500M

# apt のキャッシュ
du -sh /var/cache/apt; apt-get clean

テストデータで find を実行した結果です。

$ find . -xdev -type f -size +50M -exec ls -lh {} +
120M ./logs/app.log
60M ./logs/app.log.1
1.0G ./sparse.img
$ find . -xdev -type f -printf "%s %p\n" | sort -nr | head -3
1073741824 ./sparse.img
125829120 ./logs/app.log
62914560 ./logs/app.log.1

find -size と -printf '%s' は見かけのサイズで判定するため、スパースファイル（du では 0）も上位に出ます。実際の使用量で並べたいときは du -ah . | sort -h | tail を使います。

削除済みでも開かれているファイル

ファイルを開いたままのプロセスがいる状態で rm すると、名前は消えても容量は解放されません。

python3 -c "import time; f=open('logs/app.log','rb'); time.sleep(30)" &
rm logs/app.log
lsof -nP +L1

COMMAND   PID     USER   FD   TYPE DEVICE  SIZE/OFF NLINK    NODE NAME
python3 15616     root    3r   REG  254,0 125829120     0 1040773 /…/data/logs/app.log (deleted)

（パスの途中は省略しています）

NLINK が 0、末尾に (deleted) と表示されるのが目印です。プロセスを再起動するか終了すると容量が解放されます。プロセスを止めずに空にする方法やログローテーションの設定は、別記事「Linuxでrmしても容量が減らない原因と対処法」で詳しく扱っています。

よくある質問

Q. free の free が少ないのですが、メモリ不足ですか？ A. free の値だけでは判断しません。Linux は空きメモリをキャッシュに使うため free は小さくなるのが普通です。available が十分あり、vmstat の si/so が0なら、メモリ不足ではありません。

Q. df と du の結果が合わないのはなぜですか？ A. 主な理由は、削除済みでも開かれたままのファイル（lsof +L1 で確認）、マウントで隠れたファイル、ext4 の予約領域です。du は見えるファイルを数え、df はファイルシステム全体の使用量を見ているため差が出ます。

Q. iostat の %util が100%ならディスクが限界ですか？ A. HDD のように1つずつ処理するディスクなら、ほぼ限界です。SSD や RAID は並列に処理できるため、%util が100%でも余裕があることがあります。r_await / w_await と aqu-sz が普段より増えているかを合わせて判断します。

Q. コンテナの中で free を実行すると値が大きすぎるのはなぜですか？ A. コンテナ内の /proc/meminfo はホスト全体の値を返すためです。コンテナの上限は /sys/fs/cgroup/memory.max（cgroup v2）や docker stats で確認します。

まとめ

• メモリは free の available で判断し、buff/cache は必要に応じて解放される
• df の Use% と df -i の IUse% の両方を見る。Use% は Used÷(Used+Avail)
• 原因の場所探しは du -xh --max-depth=1 | sort -h、ファイル数は du --inodes
• vmstat は2行目以降を見る：r（CPU）、b・wa（ディスク）、si・so（メモリ）
• iostat は %util と r_await / w_await をセットで、SSD では await を重視
• 負荷試験では wa・b・%util がそろって上がるのがディスク、r と us がCPU
• df と du が合わないときは lsof +L1、コンテナではホストの値が見える点に注意

株式会社RJCでは、Linuxのリソース監視とトラブル調査の基本を仲間と学び合っています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。