logrotateの関係でディスク周りで失敗した時の話 - ヌキのやる気のないエンジニアブログ

問題発生

日に日にDisk残容量が現象していき何が大きいのかわからない状態になっていました。
普通容量を食っているファイルを検索かけて削除or転送を行うのですが、今回duコマンドでも見つけることができませんでした・・・
私がいつも打つのは

# du -sh /* | grep G | sort -n

と実行し、/配下でGB単位で容量を食ってるディレクトリを調べ、出てきたものからディレクトリを掘り下げて調査していました。
さくらVPSの1GBの契約のサーバだったので/配下は約17GBしかありません。
muninで容量が減り始めたのはチェックしていたのですが、「ログのせいだろうな」って軽く考えてました。
アクセスログやらphpのログをgzipで固め容量を空けようとしたのですがそれでは足らず・・・
そしてついに残容量3GBを切りNagiosからはずっとアラートメールが飛び続け・・・
ｱﾜﾜヽ(´Д｀;≡;´Д｀)丿ｱﾜﾜ

Twitterでエンジニアに助けを求めたところ
「du -sh /*だとドットで始まる隠しファイルが計算されないので、隠しファイルが原因かもしれません。du -sch /{.[!.]*,*}で実行するとドットファイルも計算されます。」
「あとはls -al /proc/*/fd/* | grep deletedで実際は削除されたのにプロセスが掴んでいるファイルがわかるのでプロセスの再起動をするか、もしくは権限で見れていないファイルがあるのかもしれないのでrootで実行するとかでしょうか」
と意見を頂きました。
実際ドットから始まるファイルがたくさんあるなどの理由ではなく後者が原因でした。

原因その1

プロセスがファイルを掴んだままで容量が減少しているというのが最終的な理由でした。

 # ls -al /proc/*/fd/* | grep deleted

を実行した時にプロセスがファイルを掴んでいることは確認したのですが、上記コマンドで表示されたファイルの容量が小さかったので違うだろうなと考えていました。
ここで大きな勘違いをしていたようです。

原因その2

memcachedのログを-vvオプションを利用し取得していました。ログのローテートを行ってなかったので、後からローテートの設定を実装しました。

/var/log/memcached.log {

    daily

    compress

    rotate 4

}

ローテートの仕方は間違えていないと思うのですが、memcachedがローテートされたファイルにログを出し続けていたようです。
memcachedがmemcached_log.1というファイルを掴んでいたのは確認しました

対応を優先してしまって詳細な原因などをログに残せなかったので本当にこれが原因だったかわかりませんが、memcachedのログをローテートしてはいけないようです。
それかちゃんとしたローテート方法があるんだと思います。

対応

プログラマーの許可の元、サービスをメンテナンスに切り替えサーバの再起動を実施しました。
そしたら先程まで残容量が3GBしかなかったのに急に残容量が13GBになりました・・・
その時のmuninのグラフです。

ここまで急に落ちるとは・・・

ローテートは便利ですが、使い方を間違えるとこの様に大変な思いをしなければなりません。
結局は私の「技術不足」「経験不足」「判断ミス」が一番の問題でした。
たぶんこの記事の中にも間違ったことを言ってることがあるかもですが、痛いミスをしたのでログに残しておきます。