[Linux] Disk Full エラー発生時のボトルネックの探り方 [WordPress*KUSANAGI]
はじめに
ConoHa VPS 上に KUSANAGI で WordPress を構築していました。ある時、Disk Full エラーが発生しました。その際、どのようにしてボトルネックを探って解決したか備忘録的に執筆します。
今、この記事を見ている方はもしかしたら実際に問題が発生していて、焦っているかもしれません。そんな方に強くお伝えしたいことは...
推測するな、計測せよ。
焦る気持ちは非常に分かります。
ただ、まずは落ち着いて、ボトルネックを探りましょう！
ボトルネックを特定する
1. ディスクの空き領域を表示する
コマンド
df -h
結果
ファイルシス サイズ 使用 残り 使用% マウント位置
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 1.9G 192M 1.7G 11% /run
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
/dev/vda2 99G 99G 0 100% /
tmpfs 379M 0 379M 0% /run/user/0
/dev/vda2 99G 99G 0 100% / の行から、Linux の論理ボリュームマネージャーの容量が逼迫していることが判明しました。Disk Full は確かに起きていそうです。
2. ディスクの使用量を表示する
コマンド
du -sh /*
結果
0 /bin
352M /boot
0 /dev
42M /etc
7.0G /home
0 /lib
0 /lib64
16K /lost+found
4.0K /media
4.0K /mnt
80G /opt
du: `/proc/1439/task/1439/fd/4' にアクセスできません: そのようなファイルやディレクトリはありません
du: `/proc/1439/task/1439/fdinfo/4' にアクセスできません: そのようなファイルやディレクトリはありません
du: `/proc/1439/fd/4' にアクセスできません: そのようなファイルやディレクトリはありません
du: `/proc/1439/fdinfo/4' にアクセスできません: そのようなファイルやディレクトリはありません
0 /proc
116K /root
192M /run
0 /sbin
4.0K /srv
0 /sys
6.2G /tmp
2.7G /usr
3.4G /var
80G /opt の行から、opt ディレクトリ内に 80G のファイルが存在していることが判明。更に、絞っていきます。
コマンド
du -sh /opt/*
結果
41M /opt/eff.org
80G /opt/kusanagi-manager
4.0K /opt/rh
80G /opt/kusanagi-manager から kusanagi-manager ディレクトリ配下に 80G のファイルが存在していることが分かりました。以上のようにディレクトリを掘っていきます。最終的には以下のコマンドで特定できました。
コマンド
du -sh /opt/kusanagi-manager/backup/myigk3sfxc49r4y8dwzcened/*
結果
40M /opt/kusanagi-manager/backup/myigk3sfxc49r4y8dwzcened/db_auto
80G /opt/kusanagi-manager/backup/myigk3sfxc49r4y8dwzcened/web_auto
どうやら web_auto ディレクトリが 80G もディスクを使用していました。
cd コマンドで web_auto ディレクトリ内に移動。
コマンド
ls -lh
結果
合計 80G
-rw-r--r-- 1 root root 6.2G 10月 23 03:24 web_20201023_031801.tar.gz
-rw-r--r-- 1 root root 6.2G 10月 24 03:24 web_20201024_031801.tar.gz
-rw-r--r-- 1 root root 6.2G 10月 25 03:23 web_20201025_031801.tar.gz
-rw-r--r-- 1 root root 6.2G 10月 26 03:24 web_20201026_031802.tar.gz
-rw-r--r-- 1 root root 6.2G 10月 27 03:23 web_20201027_031801.tar.gz
-rw-r--r-- 1 root root 6.2G 10月 28 03:23 web_20201028_031802.tar.gz
-rw-r--r-- 1 root root 6.1G 10月 29 03:23 web_20201029_031801.tar.gz
以下略
1 ファイルで約 6 GB のバックアップファイルが生成されていました。これらが 14 日分あったので、約 80 GB もディスクを使用していました。結果、Disk Full 状態を起こしていました。
これでボトルネックを特定することができました！
ボトルネックを解消する
バックアップファイルの上限数を減らす
14 日分のバックアップファイルを 7 日分に変更すれば、約 40 GB は減らせます。まずは手動で不要なバックアップファイルを削除。一旦、Disk Full エラーを解決。
当然、それだけだと、また 1 週間後に同じような問題に直面します。
なので、今回のボトルネックを解消します。
kusanagi-manager のバックアップの上限数を変更します。
cd コマンドで /etc/cron.d/ に移動。
backup_{サイト名} ファイルを vim コマンド等で変更します。
Before
SHELL=/bin/bash
18 3 * * * root /opt/kusanagi-manager/kusanagi-manager backup --fqdn example.com --name $(date "+web_\%Y\%m\%d_\%H\%M\%S") --target web_auto --limit 14 >> /var/log/kusanagibackup.log 2>&1
18 3 * * * root /opt/kusanagi-manager/kusanagi-manager backup --fqdn example.com --name $(date "+db_\%Y\%m\%d_\%H\%M\%S") --target db_auto --limit 14 >> /var/log/kusanagibackup.log 2>&1
After
SHELL=/bin/bash
18 3 * * SUN root /opt/kusanagi-manager/kusanagi-manager backup --fqdn example.com --name $(date "+web_\%Y\%m\%d_\%H\%M\%S") --target web_auto --limit 7 >> /var/log/kusanagibackup.log 2>&1
18 3 * * SUN root /opt/kusanagi-manager/kusanagi-manager backup --fqdn example.com --name $(date "+db_\%Y\%m\%d_\%H\%M\%S") --target db_auto --limit 7 >> /var/log/kusanagibackup.log 2>&1
--limit 14 を --limit 7 に変更しただけです。
これで、ボトルネックを解消することができました！
おわりに
障害発生時は焦ります。冷静に判断することが難しいです。
しかし、そんな時だからこそ、推測して当てずっぽうに改善を試みるのではなく、計測してボトルネックを特定する。特定後、ボトルネックを解消するという順番で解決するべきです。自戒の念を込めて。
Discussion