ディスク使用率が100%になっていた時の動作確認と改善
Linuxの本を読んでいてとあるコマンドの動作確認してみよう〜と思って、VPSでapt-getしてみると、ディスク容量が足りずapt-getできなかった...その時の備忘録。
実行環境は以下です。
$ cat /etc/os-release NAME="Ubuntu" VERSION="20.04.2 LTS (Focal Fossa)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 20.04.2 LTS" VERSION_ID="20.04" HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" VERSION_CODENAME=focal UBUNTU_CODENAME=focal
CPUの状態とかVPSのストレージの容量などのスペックに関する情報も今回は大事そうなので、概要を貼っておく。
ストレージは30Gでメモリは512Mの1コア。
原因を調べる
まず出ていたエラーはこちら
$ sudo apt-get install sysstat -y Reading package lists... Error! E: Write error - write (28: No space left on device) E: IO Error saving source cache E: The package lists or status file could not be parsed or opened
No space left on deviceなるほど？と思ってググってみると、エラーメッセージからも分かるようにディスク容量が足りないっぽい。
監視しているGrafanaを見てみようとするも、こちらもerror while signing in userというエラーが出て、どうやらディスク容量が足りなくてログインできないらしい（やばすぎ）
この記事を参考に状況確認をしていく。
ディスク容量を確認してみると、確かに100%になっている。
df -h Filesystem Size Used Avail Use% Mounted on udev 196M 0 196M 0% /dev tmpfs 48M 7.8M 41M 17% /run /dev/vda2 30G 30G 0 100% / tmpfs 240M 0 240M 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 240M 0 240M 0% /sys/fs/cgroup overlay 30G 30G 0 100% /var/lib/docker/overlay2/16732358870e1f380a4419b2b6f3ad96de63978c4db409f9d4101e1e548c3347/merged overlay 30G 30G 0 100% /var/lib/docker/overlay2/6c34794ad8d40cdae81f6786b3f358da1dfa6be67e303c4a0a33f624e58e6f33/merged overlay 30G 30G 0 100% /var/lib/docker/overlay2/cab37ca7d92d44cec7ac44e89e3586f66e5b45f1848f36a84caa466a738b3894/merged overlay 30G 30G 0 100% /var/lib/docker/overlay2/f077786c541e8b771b84f244c3df32824d1a8a4ac1a79a0d48d874ea3b5a67ea/merged overlay 30G 30G 0 100% /var/lib/docker/overlay2/046193df3aff249777c74c548e11a54aed88626e09e464b8069e6e06e10b3e6a/merged overlay 30G 30G 0 100% /var/lib/docker/overlay2/43950b4910e94cc1f29e7cebedf980c366621a4567318941409a355fbaf4cbe9/merged overlay 30G 30G 0 100% /var/lib/docker/overlay2/ee953ed406e774cd7d425ccbbf19d458cb1d96e9dfe63ce9a866e4b7bfc9b1f1/merged overlay 30G 30G 0 100% /var/lib/docker/overlay2/e292d887b9f781e9e40fd48c3bf49c3239c646b2b626cb95c4801fda335809e9/merged overlay 30G 30G 0 100% /var/lib/docker/overlay2/1b15663ad519a318e573dc885d62a9a10bdbcd879ea619b67d430061d5869e1c/merged overlay 30G 30G 0 100% /var/lib/docker/overlay2/0ad38b35d06e8fd47ecbec097453548f20dee51a46446eab6a408902ba4650e1/merged overlay 30G 30G 0 100% /var/lib/docker/overlay2/8adec6f6f1fde1674d3db066b63aa418fb082f3cc846bcd083575490c7193427/merged /dev/loop10 56M 56M 0 100% /snap/core18/2284 /dev/loop7 44M 44M 0 100% /snap/snapd/14978 /dev/loop4 68M 68M 0 100% /snap/lxd/22526 /dev/loop0 62M 62M 0 100% /snap/core20/1376 /dev/loop1 44M 44M 0 100% /snap/snapd/15177 /dev/loop2 56M 56M 0 100% /snap/core18/2344 /dev/loop6 68M 68M 0 100% /snap/lxd/22753 /dev/loop3 62M 62M 0 100% /snap/core20/1405
inodeの方は余裕がある。
$ df -i Filesystem Inodes IUsed IFree IUse% Mounted on udev 50094 445 49649 1% /dev tmpfs 61192 977 60215 2% /run /dev/vda2 1966080 255325 1710755 13% / tmpfs 61192 1 61191 1% /dev/shm tmpfs 61192 4 61188 1% /run/lock tmpfs 61192 18 61174 1% /sys/fs/cgroup overlay 1966080 255325 1710755 13% /var/lib/docker/overlay2/16732358870e1f380a4419b2b6f3ad96de63978c4db409f9d4101e1e548c3347/merged overlay 1966080 255325 1710755 13% /var/lib/docker/overlay2/6c34794ad8d40cdae81f6786b3f358da1dfa6be67e303c4a0a33f624e58e6f33/merged overlay 1966080 255325 1710755 13% /var/lib/docker/overlay2/cab37ca7d92d44cec7ac44e89e3586f66e5b45f1848f36a84caa466a738b3894/merged overlay 1966080 255325 1710755 13% /var/lib/docker/overlay2/f077786c541e8b771b84f244c3df32824d1a8a4ac1a79a0d48d874ea3b5a67ea/merged overlay 1966080 255325 1710755 13% /var/lib/docker/overlay2/046193df3aff249777c74c548e11a54aed88626e09e464b8069e6e06e10b3e6a/merged overlay 1966080 255325 1710755 13% /var/lib/docker/overlay2/43950b4910e94cc1f29e7cebedf980c366621a4567318941409a355fbaf4cbe9/merged overlay 1966080 255325 1710755 13% /var/lib/docker/overlay2/ee953ed406e774cd7d425ccbbf19d458cb1d96e9dfe63ce9a866e4b7bfc9b1f1/merged overlay 1966080 255325 1710755 13% /var/lib/docker/overlay2/e292d887b9f781e9e40fd48c3bf49c3239c646b2b626cb95c4801fda335809e9/merged overlay 1966080 255325 1710755 13% /var/lib/docker/overlay2/1b15663ad519a318e573dc885d62a9a10bdbcd879ea619b67d430061d5869e1c/merged overlay 1966080 255325 1710755 13% /var/lib/docker/overlay2/0ad38b35d06e8fd47ecbec097453548f20dee51a46446eab6a408902ba4650e1/merged overlay 1966080 255325 1710755 13% /var/lib/docker/overlay2/8adec6f6f1fde1674d3db066b63aa418fb082f3cc846bcd083575490c7193427/merged /dev/loop10 10847 10847 0 100% /snap/core18/2284 /dev/loop7 480 480 0 100% /snap/snapd/14978 /dev/loop4 799 799 0 100% /snap/lxd/22526 /dev/loop0 11777 11777 0 100% /snap/core20/1376 /dev/loop1 482 482 0 100% /snap/snapd/15177 /dev/loop2 10849 10849 0 100% /snap/core18/2344 /dev/loop6 802 802 0 100% /snap/lxd/22753 /dev/loop3 11778 11778 0 100% /snap/core20/1405
どこでディスクを食っているのか確認。
sudo du -sh /* 0 /bin 298M /boot 4.0K /cdrom 0 /dev 5.5M /etc 11M /home 0 /lib 0 /lib32 0 /lib64 0 /libx32 16K /lost+found 4.0K /media 4.0K /mnt 16K /opt du: cannot access '/proc/2809715/task/2809715/fd/4': No such file or directory du: cannot access '/proc/2809715/task/2809715/fdinfo/4': No such file or directory du: cannot access '/proc/2809715/fd/3': No such file or directory du: cannot access '/proc/2809715/fdinfo/3': No such file or directory 0 /proc 84K /root 7.8M /run 0 /sbin 1.5G /snap 4.0K /srv 2.1G /swap.img 0 /sys 264M /tmp 3.0G /usr 28G /var
/usrはライブラリ群が入っている。どうみても/varがやばそうなので追って確認してみる。
$ sudo du -sh /var/* [sudo] password for hysrtr: 824K /var/backups 98M /var/cache 4.0K /var/crash 27G /var/lib 4.0K /var/local 0 /var/lock 832M /var/log 4.0K /var/mail 4.0K /var/opt 0 /var/run 76K /var/snap 28K /var/spool 28K /var/tmp
もう1階層下。
$ sudo du -sh /var/lib/* 12K /var/lib/AccountsService 36K /var/lib/PackageKit 8.0K /var/lib/apport 139M /var/lib/apt 4.0K /var/lib/boltd 228K /var/lib/cloud 3.1M /var/lib/command-not-found 536K /var/lib/containerd 4.0K /var/lib/dbus 4.0K /var/lib/dhcp 26G /var/lib/docker 38M /var/lib/dpkg 900K /var/lib/fwupd 4.0K /var/lib/git 16K /var/lib/grub 16K /var/lib/initramfs-tools 4.0K /var/lib/landscape 8.0K /var/lib/logrotate 4.0K /var/lib/man-db 4.0K /var/lib/misc 4.0K /var/lib/ntp 4.0K /var/lib/os-prober 28K /var/lib/pam 4.0K /var/lib/plymouth 40K /var/lib/polkit-1 4.0K /var/lib/private 4.0K /var/lib/python 4.0K /var/lib/resolvconf 840M /var/lib/snapd 4.0K /var/lib/sntp 8.0K /var/lib/sudo 580K /var/lib/systemd 4.0K /var/lib/tpm 4.0K /var/lib/ubuntu-advantage 8.0K /var/lib/ubuntu-release-upgrader 108K /var/lib/ucf 4.0K /var/lib/unattended-upgrades 12K /var/lib/update-manager 20K /var/lib/update-notifier 608K /var/lib/usbutils 8.0K /var/lib/vim
26G /var/lib/docker
知ってた。だってコンテナ11個立ってるから。ということでdockerコンテナでストレージを食い潰していることが確認できた。
メトリクスを見る
まずデプロイされているサーバーはちゃんと応答するのか確認した。
サーバーの動作確認して、APIも叩けていて読み書きができているのは確認した。
ディスクを圧迫しているのは、とあるプロダクトでログを出力していて、promtailがLokiに送ってLokiが保存しているログがかなり溜まってきてディスクを圧迫し出したのかな〜と推測。
（ちゃんとログローテートしようね）
Grafanaが見れないので、ログファイルを直接tailコマンドで確認してみたけど、アクセスは全然ない...最終アクセスは2ヶ月前とか。
一応duコマンドでログファイルの容量を見てみる。
$ du -h 8.0K ./derror 356K ./logging/log 368K ./logging 8.0K ./dcontext 8.0K ./db 36K ./server/handler 12K ./server/model/mock_model 20K ./server/model 16K ./server/service/mock_service 56K ./server/service 120K ./server 8.0K ./utils/mock_utils 16K ./utils 12K ./http/middleware 8.0K ./http/response/mock_response 16K ./http/response 32K ./http 564K .
ログファイルが入っているlogging/logも容量的には小さいので、このプロダクトのログが原因ではなさそう。
貧弱だけどVPSのメトリクスを見てみる。
CPU使用率は確かに少しずつ上がっていて直近だと急増とは言わないまでも増えている。
特別リリースしているプロダクトがあるわけではないし、そんな顕著にアクセス数が増える要因はなさそう。
CPU使用率が上がっているのはログが溜まってきて、ログ出力する際のファイルへの書き込みだったりログファイルの読み込み処理が重たくなってきたのかな〜。
と思ったけど、そもそもログが増えていないので多分それもない...
一旦Nginxのログを見てみたいけど、コンテナに入るディスクすらない（笑）
$ docker exec -it nginx-proxy sh failed to create runc console socket: mkdir /tmp/pty342788273: no space left on device: unknown
freeコマンドでメモリの使用状況を確認する。
$ free -m
total used free shared buff/cache available
Mem: 478 282 10 4 185 172
Swap: 2047 587 1460
-mオプションでメガバイト単位で出力されている。メモリには余裕がありそう。
んじゃとりあえずいらないコンテナ落とそうと思ったけど、消せない。
$ docker-compose down [2811825] INTERNAL ERROR: cannot create temporary directory!
プロセスを切ろうと思ったけど、それも無理。
OCI runtime exec failed: write /tmp/runc-process177314135: no space left on device: unknown
こういうことにならないように監視してSlack通知とかできる仕組み作ろうってことね（学び）
/var/lib/docker/overlay2の肥大化
df -hコマンドの結果を再度見てみると、/var/lib/docker/overlay2配下がかなり肥大化している。
ググってみると対処法があるらしいので、やってみる。
ディスク容量の確保
$ sudo docker system prune WARNING! This will remove: - all stopped containers - all networks not used by at least one container - all dangling images - all dangling build cache Are you sure you want to continue? [y/N] y Deleted Networks: infecshotapi_loki infecshotapi_default Deleted Images: untagged: phpmyadmin/phpmyadmin@sha256:8911fb0cfef21dc9fb385ad02cc3254179cd7df87bab3d3a6fa04d1f0549463f deleted: sha256:72000eb04892657673456eb9e49a17c1a1c4f8bd248762e635a5a9a2d419b706 deleted: sha256:0aae68c037aa83cc840e9497099e34126c3267e89012e5ac9721dea08b57ef5d deleted: sha256:4d753ce77b2a8902763e263ce8e8f67734ce82b3711d4646e01269be4e667a99 deleted: sha256:04f56bb98a35279655735589da44e15ba58fe980ec110bbeba33ae3b7278fb51 deleted: sha256:831e6802a4050103c5100dc975758f691b8ef53ab91b7f18220febbfcadcf8d2 deleted: sha256:ce51a414c795e165e1812cec96f4272d5b7ca8aa46f7fa947cc4563740178465 deleted: sha256:659bb6c656b7ad3de6bc48b2a42eb52203a6d82bddc329b55ac3bb87d57fb41c deleted: sha256:08e5085476b5fe7cdcdde54c5eb8b57b0ffe3a8cbbbd3efc34379fae5cd0fe34 deleted: sha256:240444cca7a1c2258cf0040c92d0cc466ecd3ffd7bcc9c3c98ed1b163ab82b6f deleted: sha256:d6b236f42314993f24d1b6f26e18050ef697518c6f2a4b7819acd69c08531b5a deleted: sha256:59ec2d85a348f5f7c2927b57d3d60cbc7143427d84ad63e2f7678eb5940100d1 deleted: sha256:86fb957d5b48d7590796aca0c79c7a15d1a035c182ba3c1a5c03d5c8718907f9 deleted: sha256:0f79560001ca66b44b869333a059ac9f109f2cc2bfda3da5e0b9328ccf6f5876 deleted: sha256:d2b3415933888ae214a940917ef6ef3de81fbe6dc29a8700ad0971eb2af12437 deleted: sha256:9635b15bd71af78bd50d20f536c2f1b1295d44796cf8aa142fcb7f83a4705078 deleted: sha256:a966a3879737b38ba08d50017ceb96d0733ca61aa8be2a83ec6d7eb36c03385e deleted: sha256:3942e303af0d218de6c79079a0594913df200acab6c5790197dc24c766703340 deleted: sha256:95ad977108150f3b154a1ac2b9592bb2d02c281200af808951ae5c50b19e97e3 deleted: sha256:14a1ca976738392ffa2ae4e54934ba28ab9cb756e924ad9297a4795a4adbfdf6 Total reclaimed space: 477.2MB
お、500MBぐらい空きができた。
けどこれでは全然ディスク使用率は改善されていない。
やっぱり稼働しているコンテナを落としてoverlay削除するしかないかなぁ...
コンテナを落としてpruneして、再度dfコマンドでディスク使用率を確認
$ df -h Filesystem Size Used Avail Use% Mounted on udev 196M 0 196M 0% /dev tmpfs 48M 1.6M 47M 4% /run /dev/vda2 30G 7.5G 21G 27% / tmpfs 240M 0 240M 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 240M 0 240M 0% /sys/fs/cgroup /dev/loop10 56M 56M 0 100% /snap/core18/2284 /dev/loop7 44M 44M 0 100% /snap/snapd/14978 /dev/loop4 68M 68M 0 100% /snap/lxd/22526 /dev/loop0 62M 62M 0 100% /snap/core20/1376 /dev/loop1 44M 44M 0 100% /snap/snapd/15177 /dev/loop2 56M 56M 0 100% /snap/core18/2344 /dev/loop6 68M 68M 0 100% /snap/lxd/22753 /dev/loop3 62M 62M 0 100% /snap/core20/1405
overlay自体の仕組みなどは結構難解だったのでまた別の機会にまとめようと思います。
