残念ながら、手元にディスクフルになった環境がないので、コマンドや手順だけを残す。
ディスク容量を確認する
df -h
-h
で、単位がつくので見やすくなります。
そしてMounted on
にあるパスを見て、フォルダを絞り込んでいきます。
大概、ディスクフルを起きて困惑してこの記事を見たとすれば、/
でディスクフルが起きたときだと思いますが。
ディレクトリを絞り込んでいく
du -sh <ディレクトリパス>/*
-s
は、サブフォルダを探索しないためのオプション。<ディレクトリパス>配下のファイルサイズを合計した結果のみを表示してくれます。
-h
は、du
と同じく、単位がつくようになります。
先に上げたdf
でディスクフルになっているディレクトリを指定します。
ただ、/
だと時間がかかったり、/proc
など不要なディレクトリまで見てしまうため、ファイルサイズが大きくなりやすいフォルダに絞って最初は見たりしています。
例えば、/home``/usr``/var``/tmp
あたりから見ています。
以前私がDockerコンテナによるディスクフルに出くわしたときは、
du -sh /var
du -sh /var/*
du -sh /var/lib/*
du -sh /var/lib/docker/*
の順で絞り込んで行きました。
また、どのディレクトリにサイズが大きいファイルがあったのか分かれば、原因分析もできますよね。
先のDockerの例では、コンテナの内部で巨大な一時ファイルを、ホスト上にマウントしていないフォルダに作ってしまったためでした。
対処
まず第一に、いらないファイルは、消しましょう。
思い切りが大事です。
いるファイルばかりと思ったなら、少しでもいらないファイルにしましょう。
- 取っておく必要があるようなファイルは、バックアップサーバや手元に移して消す
- gzip圧縮して消す
- 障害発生時に出た過去ログやコアダンプを消す
- PostgreSQLなどミドルウェアが出力したバイナリファイルは、過去のアーカイブログ(実は消せる)だったりもするので、ネットで裏とりして消す
一時対処は上記の通り消すしかないですが、頻発するようなら消す以外の手を打ちましょう。
- ディスクを増やす(再サイジング、金で解決)
- 自動化して消す(ログローテートとかのことです)
- 念のためのそのファイル、そもそもいらなくね、という議論を始める