LAMP 環境で、ディスク利用率の監視通知がきたときの、原因ファイル特定までの手順まとめ
1年に数回はきます。たまに全く知らない環境の調査依頼もきます。
慣れすぎて、いつも経験則でやってましたが、最近記憶力が低下してきたので、いまのうちに一度まとめます。
奇抜な方法は使いません。段階を追って特定します。この方法で、原因(のファイル)が見つからなかったことはないです。
まずは、root 権限になります。rootでない場合、原因になっているディレクトリやファイルに辿り着けないことが多いからです。
$ su -
or
$ sudo -i
df でどのディスクが原因か確認します。
# df -h
対象のディスクの第一階層で、どのディレクトリがサイズが大きいかを確認します。多いのが、
- /var/log 以下の特定のログが肥大化している
- /var/lib/mysql 以下で特定スキームが肥大化していしている
- /var/www/html (ドキュメントルート)以下で、コンテンツファイル(画像やPDFなど)が増加している
といったパターンです。
# du -h --max-depth 1 <対象ディレクトリ>
# du -h --max-depth 1 /var/log/
# du -h --max-depth 1 /var/lib/mysql/
# du -h --max-depth 1 /var/www/html
目星がついたら、さらにディレクトリを1段階下げて、同じコマンドで確認するということを繰り返します。
ディレクトリまで辿り着いたら最後にどのファイルが多いかを特定します。
まずは、ls で ファイルのサイズが大きいもの順で表示する方法です。
# ls -lSh <対象ディレクトリ>
あとは、100MB以上のファイルを検索するfindもよく使います。
# cd <検索したいディレクトリ>
# find ./ -type f -size +10M | xargs ls -lh
最後に特定したファイルの処理ですが、これは、システムによるのかなとおもうので、適宜ですね。
消す
# rm <対象のファイル>
余裕のあるディスクに移動する
# mv <対象のファイル> <余裕のあるディスクのディレクトリ>
MySQLのテーブル最適化 ※Deleteが多くデフラグしやすい場合に有効。時間がかかるので要注意※
> optimize table <サイズの多きいテーブル>
※ http://gihyo.jp/dev/serial/01/mysql-road-construction-news/0035
番外編で、「そっちかー」というのが、inode の利用制限のオーバーです。1年に一回ぐらいきます。
そのときは、下記です。
# df -ih
Author And Source
この問題について(LAMP 環境で、ディスク利用率の監視通知がきたときの、原因ファイル特定までの手順まとめ), 我々は、より多くの情報をここで見つけました https://qiita.com/t_murotani/items/31f87f6efe89820350c3著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .