こんにちは。Takitaです。
Webサービスのデプロイがこけると連絡を受けて対応しました。
ぼくはインフラエンジニアでもなくインフラの知見があまりないので調べながら対応した内容をまとめておきます。
デプロイでこけたという話だったのでデプロイのログを確認しました。
mkdir stdout: mkdir: cannot create directory ‘/var/www/app_name/releases/20170613042031’: No space left on device
No space left on device
は
通常ファイルの書き込み時またはディレクトリエントリの作成時に、デバイスに空き領域が残っていません。ディスク、テープ、またはフロッピーディスクがデータでいっぱいです。この状態のときに書き込まれたすべてのデータが失われる可能性があります。
https://docs.oracle.com/cd/E19455-01/806-2720/msgs-601/index.html
ということです。
サーバーに入ってディスク容量を確認しました。
まず、ディスク・ドライブの使用量を表示して確認します。
$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/xvda1 8115168 7679888 4 100% /
none 4 0 4 0% /sys/fs/cgroup
udev 4082848 8 4082840 1% /dev
tmpfs 817564 348 817216 1% /run
none 5120 0 5120 0% /run/lock
none 4087808 0 4087808 0% /run/shm
none 102400 0 102400 0% /run/user
/
が100%になっています。
/
以下の不要なファイルを削除して容量を確保します。
削除対象のファイルを洗い出すために容量を食っていそうなディレクトリを一覧にします。
$ sudo du -x -h / | sort -r -h | head -40
どれも必要そうなフォルダっぽいので容量の大きいフォルダの一覧の中から、
不要なファイルが格納されていそうなログ関連のフォルダを見つけます。
$ sudo du -x -h / | sort -r -h | head -40 | grep log
1.3G /var/log/nginx
1.3G /var/log
これらのフォルダに入って ll
でいらなそうなファイルかつ容量が大きいものから順に rm
していきました。
今回は暫定対応だけ行いました。
今回はそもそもローテートされていないログファイルがあったりしたことが原因のひとつだったので、
ちゃんとログファイルはローテートするなどの対応が必要だと思います。
ログファイルのローテートを行っていても容量が逼迫する場合は、ディスク容量を増やすなどの対策が必要です。
https://docs.oracle.com/cd/E19455-01/806-2720/msgs-601/index.html
https://serverfault.com/questions/330532/xvda1-is-100-full-what-is-it-how-to-fix