ストレージを消費しているものを探す

はじめに

自分が業務で管理しているサーバーを眺めていたら、ディスクの使用量が思っていたよりかなり多いことに気づきました。

$ df -h /
Filesystem         Size    Used   Avail Capacity  Mounted on
/dev/gpt/rootfs     31G    8.2G     20G    29%    /
$

このFreeBSDサーバーはクラウドサービスのVMを利用しているもので、ストレージは約30GBのシングルパーティションです。サーバーとしては大したデータが無いにも関わらず8GBの消費は多すぎます。空き容量が逼迫して困っているわけではないですが、この際なので気づいたついでにストレージを消費しているものを探して不要なものを削除して空き容量を増やしておきます。

ストレージを消費しているものを探す

さてどのストレージのどの部分が容量を消費しているのでしょうか。こーいうときに使うツールは duコマンド です。さっそくストレージの使用量を確認してみます。

消費量はMB単位程度わかれば十分なので -m オプションを指定し、まず / (ルート)の各ディレクトリ単位で容量を把握したいので -s オプションを加えて、結果を sort -n で容量順に並べ替えます。なおストレージの容量調査ではすべてのファイルやディレクトリにアクセスできないといけないですから、root 権限で作業します。

$ cd /
$ du -m -s * | sort -n
0       home
0       tmp
1       COPYRIGHT
1       dev
1       entropy
1       libexec
1       media
1       mnt
1       net
1       proc
1       root
2       bin
4       etc
7       sbin
14      rescue
15      lib
152     opt
183     boot
3959    usr
4045    var
$

見ての通りで /usr と /var ディレクトリが使用容量の大部分を占めているのことがわかります。

/usr ディレクトリ内のストレージ消費調査

それでは /usr 内を調べてみましょう。

$ cd /usr
$ du -m -s * | sort -n
1       libdata
1       obj
1       src
2       home
4       libexec
25      sbin
29      include
79      tests
112     share
258     lib32
320     bin
609     local
2526    lib
$

この通りで /usr/lib 下が圧倒的にストレージを消費していることがわかります。

自分の経験と照らし合わせて「え？ /usr/lib なんてそんなにストレージ使うものがあったかな？」と疑問を持ちながら次に /usr/lib 下を調査しました。 /usr/libには多数のファイルもあるのでとりあえず上位10番目までわかればよいということで sort の出力結果 を tail で制限しています。

$ cd lib
$ du -m -s * | sort -n | tail
11      libc++.a
12      libc++_p.a
16      libc.a
16      libc_pic.a
17      libc_p.a
17      libcrypto.a
18      libcrypto_p.a
26      libzpool.a
100     clang
2017    debug
$

なんと /usr/lib/debug ディレクトリが2GB程消費していることがわかりました。

/usr/lib/debug ディレクトリ内にはカーネルやOS標準コマンドのデバッグの為のシンボル入りのライブラリ等があるわけですが、運用で利用しているサーバーでデバッグを行うことはなく、不要なもので大量のストレージを消費していることがわかりました。ですからこのディレクトリ内のファイル類をすべて削除します。

$ cd debug/
$ ls
bin     boot    lib     libexec sbin    usr
$ du -s * | sort -n
1368    libexec
6208    bin
39344   sbin
78920   lib
969824  boot
3033760 usr
$ pwd
/usr/lib/debug
$ rm -r *
$ ls
$

これで2GB程度空き容量が増えたことになります。このサーバーは自分でインストールしたものではなくクラウドサービス側が用意しているFreeBSDのVMイメージをそのまま利用しているもので、正直 /usr/lib/debug 内のファイルが存在していたのは今回調べるまで気づいていませんでした。

/var ディレクトリ内のストレージ消費調査

/usr ディレクトリ内の調査が終わったので、今度は /var内で同様の調査を行います。

$ cd /var
$ du -m -s * | sort -n | tail
1       spool
1       tmp
1       unbound
1       yp
4       lib
7       backups
31      cache
34      log
216     named
3755    db
$ cd db
$ du -m -s * | sort -n | tail
1       ntpd.leap-seconds.list
1       ports
1       portsnap
1       sudo
1       zfsd
1       zoneinfo
3       services.db
4       etcupdate
65      pkg
3685    freebsd-update
$

この通りで /var/db/freebsd-update ディレクトリが /varディレクトリ内の大部分の容量を消費していました。

/var/db/freebsd-update ディレクトリに freebsd-updateコマンドを使うと、パッチや新しいバージョンのファイルのイメージと、アップデート後にロールバックができるように必要な情報が保存されています。とくにfreebsd-updateコマ\ンドを使って何度もバージョンアップを行うと、このディレクトリ内のファイルは増える一方なので、適度なタイミングで削除するべきでしょう。ほんとうは古いものだけ削除できれば良いのですが、freebsd-update コマンドでアップデートを行うと無いファイルはあらためてダウンロードするため、ここでは気にせず一旦全部削除します。

$ cd /var/db/freebsd-update
$ pwd
/var/db/freebsd-update
$ rm -r *
$ ls
$

これで 3.7GB 近くの容量を確保できました。

ただし /var/db/freebsd-update ディレクトリは freebsd-update コマンドを使用すると、すぐに1GB程度は消費するので、消費量が2GB程度であればわざわざ削除する必要は無いでしょう。

/usr/lib/debugと/var/db/freebsd-updateを合わせて 5GB以上空き容量を確保できました。その結果ストレージの消費量は次の通り 2.6GB となりました。

$ df -h /
Filesystem         Size    Used   Avail Capacity  Mounted on
/dev/gpt/rootfs     31G    2.6G     26G     9%    /
$

まとめ

運用サーバーでのストレージの空き容量不足は致命的なトラブルにつながります。サーバー内でどのディレクトリがストレージを消費しているのかを把握できるようにしておくと、トラブルを未然に防ぐことができます。

おまけ

X Window Systemを使っているのであれば xduコマンドを使うとディスクの消費量をグラフィカルに把握できます。使い方はこんな感じになると思います(doasが無ければsudoで)。

$ doas du -m / | xdu