古いlog ファイルを削除したり、不要なデータベースを削除したりしてもディスクの圧迫が止まらない。仕方なくディスク容量を追加する為にメンテナンスを行おうと思った。このまま放置しておくとログインすら出来なくなる可能性もあるからだ。
だが、ふと気がついた。もしかしたらメールが問題なのでは？予想は見事的中した。もっとも多いものでは100%消費していたディスク容量が17%にまで下がった。つまり、メールが83%もあったということだ。
※通常はこのような管理運用は誤っており、 pc.casey.jp » CentOS インストール後にやっておくこと などで触れているようにroot 宛のメールを正しく転送したり、クライアントが受信することが望ましい。また、容量制限を設けることも求められる。
スポンサードリンク
スプール形式の場合
ls -la /var/spool/mail/
※確認
合計 416808
drwxrwxr-x 2 root mail 4096 1月 4 03:20 .
drwxr-xr-x 11 root root 4096 1月 27 2010 ..
-rw——- 1 root root 426372967 1月 4 03:20 root
time rm -rfv /var/spool/mail/root
※削除
removed `/var/spool/mail/root’
real 0m3.243s
user 0m0.000s
sys 0m0.004s
ディレクトリ形式の場合
time rm /root/Maildir/new -rfv
※削除
real 678m38.121s
user 0m3.784s
sys 0m19.085s
こちらは見ての通り処理に非常に時間がかかった。ディスクアクセスを見れば動作していることがわかるが、もしサーバーが遠隔地にあったらディスクアクセスランプを見ることはできない。また、処理が完了するまでプロンプトが表示されないから不安になる。そのためrm コマンドに v オプションを設定し、トラフィックを犠牲にしても動作していることを確認している。v オプションを設定すると削除されたファイルが逐次表示される。
この作業はディスクアクセスがよほど強靭でなければその他の処理を妨げる。一時的に外部からのアクセスや処理を停止して行うほうが良い。筆者の環境では上記作業でload average が3.6 程度になった。CPUの使用は少ないもののディスクアクセスが尋常でないほど発生し、その他の処理の応答が著しく低下した。当然、このような状態になるまで気がつかない管理者は管理者失格と言える…。
※これらのコマンドは問答無用でメールを削除する”緊急”コマンドであるから注意すること
コメント