次のエラーが発生した後にシステムを再起動しましたが、再起動後の使用量が75%に低下する問題が発生しました。
dfmon[16139]: FATAL: ディスク使用可能モニター: 102 #ファイルシステム "/" が 100% いっぱいです。
ログや他の場所でこのスペースを占めるファイルを見つける方法はありますか?一部のプロセスでこれらのファイルが生成され、問題を解決する必要があるかもしれません。
どんな助けでも大変感謝します。
答え1
/ tmpまたは起動時に空になった可能性がある他のディレクトリに疑わしいほど大きなファイルが表示されない場合は、ファイルが接続されていないがまだ開いている可能性があります。
これは通常、他のプロセスに渡すことができますが、関連していないプロセスからファイル名でアクセスする共有メモリを作成するなど、一部のプログラムによって意図的に発生します。たとえば、ログファイルが回転/削除されているがログ記録プロセスでファイルを開いたままにしても、これは誤って発生する可能性があります。
たとえば、ファイルを開いたままにしたすべてのプロセスが終了した場合(システムが完全にシャットダウンしたとき)、または停電fsck
後に実行されると、これらのファイルはもう存在しません。したがって、これらのファイルは再起動後の使用量の削減を説明できます。
削除されたがマウントポイントに作成されたまだ開いているすべてのファイルを表示するには、rootとして次を試してください/
。
lsof -s -- / | grep -e '^COMMAND \| (deleted)' | less
この列には、COMMAND
ファイルを開いたプロセスの名前、SIZE
ファイルサイズ(バイト)、NAME
ファイルが削除される前の元のパスが含まれています。
リストに非常に大きなファイルまたは一般的なログファイル名が表示された場合は、犯人を見つけた可能性があります。
答え2
以下を試してください。ドライブがいっぱいで時間がかかることがあります。ルートディレクトリの下のすべてのファイルを確認し、サイズでソートします。
du / | sort -n
時間がかかる場合は、要約を受けて詳細がわかるまで繰り返します。
du -s /* | sort -n
答え3
パッケージマネージャには通常、少しのスペースが必要なキャッシュがあります。sudo yum clean all
またはsudo apt-get clean all
何かをきれいにすることができます。
du
素晴らしいツールです。私は使用しますdu -xhd1 /
-x, --one-file-system -h, --human-readable -d, --max-depth=N
しかし、物を削除することに夢中にならないでください。サーバーアプリケーションがデータを書き込む場所を見つけて、そのログが手に入らないことを確認します。