先日、Sambaサーバー（Ubuntu 8.04 ltr）の共有がいっぱいになりましたが、確認してみると、共有にそれほど多くの容量があるようには見えませんでした。
グループシェアは5つあり、各ユーザーには個別のシェアがあります
1人のユーザーが22GBのデータを所有し、他の数人が10～20MBのデータを所有し、他のユーザーは空です。
合計26GBくらいかな
昨日、いくつかのファイルを削除して約 250 MB のスペースを解放しましたが、今日確認すると、再び完全にいっぱいになっていました。古いファイルをいくつか削除して約 170 MB のものを解放しましたが、空きスペースが徐々に減っていくのがわかります。
私は走り続けるdf -h
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 241690180 229340500 169200 100% /
varrun 257632 260 257372 1% /var/run
varlock 257632 0 257632 0% /var/lock
udev 257632 72 257560 1% /dev
devshm 257632 52 257580 1% /dev/shm
lrm 257632 40000 217632 16% /lib/modules/2.6.24-28-generic
/揮発性
HDD を大量に占有しているものを追跡するにはどうすればよいでしょうか? (私は UNIX 全般についてあまり詳しくないので、説明が不十分な場合はお詫びします)
答え1
(これは Linux に重点を置いた回答です。他の UNIX バリアントでは異なる場合があります。)
問題に関連する情報は 2 つあります: (1) どのファイルがファイル システムを占有しているか、(2) どのプロセスがそれらのファイルに書き込んでいるかです。
ノート
以下で、$コマンドに文字を入れているところは、おそらく実際の値を代入する必要があるプレースホルダーです。どこで代入すべきか、どこで代入すべきでないかが明らかになれば幸いです。
どのファイルですか?
ほとんどのファイル システム タイプには、個々のファイルで使用できるリソースが実際には 2 つあることに注意してください。メタデータ (例: inode) と実際のデータです。inode の数を確認するには、次のようなコマンドを使用します (定義については Google で検索してください。inode はファイルを構成する構造への「ポインタ」です)。
df -i
...そして、すでにご存知のとおり、実際のデータによって使用されているスペースは次のようになります。
df -h
また、ファイル システムのスペースは、ディスク上に存在しないファイルによって占有される可能性があることに注意してください。これらのファイルは、何らかのプロセスによってまだオープン状態ですが、削除されています (これについては後で説明します)。
完全なファイル システムを特定したら、多数の小さなファイル、少数の大きなファイル、またはその両方を探し始める必要があります。メタデータ リソースが不足するのは通常、多数の小さなファイルがあるためですが、実際のデータ リソースが不足するのは通常、少数の大きなファイルがあるためです。私は次のコマンドを使用して、大きなファイルを見つけるのを好みます。
sudo find $file_system -mount -ls | awk '{print $7, $11}' | sort -rn > $output
...そしてこのコマンドは、たくさんの小さなファイルがあるディレクトリを見つけるのに役立ちます（アップデート：: ファイル名の処理を改善するためにヌル終端を追加しました):
sudo find . -mount -print0 | xargs -0n 1 dirname | sort | uniq -c | sort -rn > $output
... これらのコマンドは実行に時間がかかり、状況によっては大量の I/O を実行する可能性があることに注意してください。実行したら、$output問題のあるファイルまたはディレクトリを見つけることができます。それぞれの名前と場所から、データの出所に関するヒントが得られる場合がありますが、Linux の経験が必要です。
犯人を特定したら、rm $file問題を解決することができます。
どのプロセスですか?
ファイル システムを占有する可能性のあるプロセスを見つける最も簡単な方法は、次のようなコマンドを実行することです。
fuser -c $file_system 2>/dev/null
... 特定のファイル システムのファイル記述子 (ファイルとネットワーク ソケット) を開いているプロセスの PID が表示されます (この2>/dev/null部分では不要な情報が削除されます)。これらの PID から、どのプロセスがファイル システムを占有しているかを推測できる場合があります。次の方法でプロセスを検索します。
ps -ef | grep $pid
このコマンドを実行すると、さらに詳しい情報が表示されます (また、ディスク上に対応するファイル名がない開いているファイルを識別するのにも役立ちます。これについては上で説明しました)。
sudo lsof $file_system | grep $directory_filling_up
... コマンドから疑わしい PID を特定した場合はfuser、次の操作を実行できます。
sudo lsof -p $pid
fuserとの問題点は、lsofコマンドを実行した時点でのシステムのスナップショットしか得られないことです。実行時に問題のあるプロセスが書き込みを行っていない場合は、運が悪いとしか言えません。これを対処するには、時間をかけて繰り返し実行し、出力を保存します。これには、出力を読み取ってパターンを見つけるか、それを実行するプログラムを作成する必要があります。代替案としては、次のようなツールを使用する方法があります。システムタップSystemTap を使用すると、あらゆる種類の有用な情報を捕捉でき、「プログラム可能」です。また、一定期間にどのプロセスがどのファイルに書き込んでいるかを確認できるサンプル ソース ファイルも付属しています。これは完璧なツールですが、高度なツールであり、Linux に関する多くの知識が必要です。
問題のあるプロセスを特定したら、それらを強制終了 (および再起動) できます。プロセスがオペレーティング システムまたは適切にパッケージ化されたソフトウェアに関連付けられている場合は、再起動するメカニズムが存在する可能性がありますが、それは Linux ディストリビューションによって異なります (Ubuntu では のようなものを実行できると思います/etc/init.d/$init_script restartが、ディストリビューションのドキュメントを確認する必要があります)。それ以外の場合、動作していない場合はkill $pidまたは を使用して強制終了できますkill -9 $pid。プロセスの実行方法 ( に表示された引数など) を注意深く記録し、ps -ef再起動が必要な場合に備えてください (そのソフトウェアのドキュメントを参照する必要がある場合があります)。
答え2
duディスクを占有しているファイルを含むディレクトリを追跡するために使用します。
cd /
du -h --max-depth 1
/ 内のどのディレクトリが最も多くのスペースを使用しているかを表示します。du コマンドを実行してファイルシステムを走査し、原因を見つけます。
例えば
cd /
du -h --max-depth 1
システムで使用されている 3.5G のうち、/usr が 2.3G を使用していることを示しています。
cd /usr
du -h --max-depth 1
/usr/lib は /usr 内の 2.3 のうち 1.1G を使用していることがわかります...
これは、開いているファイルが削除されたことが原因で発生する場合もあります。
使用できますlsof開いているがリンクされていない（削除された）ファイルを検索する
lsof +L1
うまくいくはずです。マニュアルページには次のように書かれています:
フォームの指定により、
+L1リンクが解除された開いているファイルが選択されます。 フォームの指定により、+L1 <file_system>指定されたファイル システム上のリンクが解除された開いているファイルが選択されます。
答え3
何かが / パーティションを占有しています。おそらく/var/log、 または にある何かです/home。これは設定によって異なります。ユーザーがアクセスできる場所も確認してください。
問題の各ディレクトリで次のコマンドを実行します。これにより、最も多くのスペースを消費しているサブディレクトリが表示されます。
cd /directory
du -cks -x * .* |sort -n
このアイデアは、ducksスクリプト（du -cks）から借用したものです。Linux サーバー ハッキングO'Reilly から。私はこのコマンドを頻繁に実行します。
私の経験では、これはほとんどの場合、ログファイルが大きく成長していることが原因です。この場合、ログローテート、 そして必ず圧縮を使用してくださいデフォルトの圧縮率で gzip 圧縮を使用すると、ログ ファイルは 80 ～ 95% 小さくなります (1 GB の /var/log/messages は簡単に 200 MB 以下に圧縮できます)。これにより CPU に適度な負荷がかかりますが、サーバーの実際のパフォーマンスに影響が出ることはめったにありません。Bzip2 圧縮や を使用することを好む人もいますが、gzip --best私の経験では、これでは CPU のオーバーヘッドが大きくなり、メリットはほとんどありません。gzipデフォルトの圧縮率で通常は十分です。
そして明らかに、この問題はユーザーが不正行為を行ったために発生することがあります。du上記のコマンドを使用して、原因を特定してください。
答え4
おそらく原因はログですが、最近変更された（または作成された）ファイルをサイズ順に並べ替えるコマンドは次のとおりです。
D=$(date --rfc-3339 date);
sudo sh -c 'find / -xdev -mtime -1 -type f -print0 |xargs -0 du -0sbc' \
|tee ~/recent-files.$D |sort -zn |tee ~/recent-by-size.$D |xargs -0n1
このコマンドを毎日実行することもできます。おそらく、SQL 風の操作を行って、これらのファイルを日々の増加順に並べ替える方法があるでしょう。
（編集）成長を監視するには、gt5
sudo aptitude install gt5
cd /
gt5
1日後、±のサインを探す
gt5