1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

LAMP 環境で、ディスク利用率の監視通知がきたときの、原因ファイル特定までの手順まとめ

Last updated at Posted at 2019-10-13

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
1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?