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