ubuntuサーバーがゆっくりといっぱいになります
先日、Sambaサーバー（ubuntu 8.04 ltr）のシェアがいっぱいになりましたが、それを見に行ったところ、どのシェアも多くを持っていることがわかりません。
5つのグループ共有があり、各ユーザーには個別の共有があります
1人のユーザーは22ギガのコンテンツを持っており、他の数人は10〜20 MBのコンテンツを持っており、他のすべてのユーザーは空です
たぶん合計26ギガのように
昨日いくつかのファイルを削除し、今日は完全にいっぱいになっていることを確認したところ、約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
/ volatile
私のHDDの多くを占めているものを追い詰めるために私は何ができますか？ （私は一般的にUNIXにかなり新しいので、これが十分に説明されていない場合はお詫びします）
（これはLinuxに焦点を当てた回答です。他のUNIXバリアントは異なる場合があります。）
問題に関連する情報は2つあります。（1）どのファイルがファイルシステムをいっぱいにしているのか、（2）どのプロセスがそれらのファイルに書き込んでいるのかです。
ノート
以下では、コマンドに$文字を入力すると、実際の値に置き換える必要があるプレースホルダーになります。うまくいけば、それを行う場所と行わない場所が明らかです。
どのファイル？
ほとんどのファイルシステムタイプには、個々のファイルで使用できるリソースが実際には2つあることに注意してください。メタデータ（iノードなど）と実際のデータです。次のようなコマンドを使用して、iノードの数を確認できます（Googleで定義を検索しますが、これらはファイルを構成する構造への「ポインター」です）。
df -i
...そして、すでにご存知のように、このようなものは、実際のデータによって使用されているスペースを示します。
df -h
また、ファイルシステムのスペースは、ディスク上に存在しないファイルによって占有される可能性があることに注意してください。これらのファイルは、いくつかのプロセスによってまだ開いた状態ですが、削除されています（これについては以下で説明します）。
完全なファイルシステムを特定したら、たくさんの小さなファイル、いくつかの大きなファイル、またはその両方を探し始める必要があります。メタデータリソースの不足は通常、小さなファイルがたくさんあることが原因ですが、実際のデータリソースの不足は通常、いくつかの大きなファイルが原因です。私はこのコマンドを使用して大きなファイルを見つけるのを助けるのが好きです：
Sudo find $file_system -mount -ls | awk '{print $7, $11}' | sort -rn > $output
...そしてこのコマンドは小さなファイルがたくさんあるディレクトリを見つけるのに役立ちます（更新：：ファイル名の処理を改善するためにnull終了を追加しました）：
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
...そしてfuserコマンドから疑わしいPIDを特定した場合は、次のことができます。
Sudo lsof -p $pid
fuserとlsofの問題は、コマンドの実行時にシステムのスナップショットしか提供されないことです。それらを実行したときに問題のプロセスがたまたま書き込みを行っていない場合は、運が悪いことになります。時間をかけて繰り返し実行し、出力を保存することで、これに対抗できます。これには、パターンを見つけるために出力を読み取るか、それを行うためのプログラムを作成する必要があります。別の方法は、 SystemTap のようなツールを使用することです。 SystemTapを使用すると、あらゆる種類の有用な情報をトラップでき、「プログラム可能」です。一定期間にどのプロセスがどのファイルに書き込んでいるかを確認できるサンプルソースファイルも付属しています。完璧ですが、高度なツールであり、Linuxに関する多くの知識が必要です。
問題のあるプロセスを特定したら、それらを強制終了できます（場合によっては再起動できます）。プロセスがオペレーティングシステムまたは適切にパッケージ化されたソフトウェアに関連付けられている場合、それらを再起動するメカニズムがある可能性がありますが、Linuxディストリビューションによって異なります（Ubuntuでは/etc/init.d/$init_script restartのようなものを実行できると思います。ただし、ディストリビューションのドキュメントを確認する必要があります）。それ以外の場合は、動作していない場合はkill $pidまたはkill -9 $pidで強制終了できます。プロセスを再起動する必要がある場合に備えて、プロセスがどのように実行されているか（たとえば、ps -efに表示される引数は何か）に注意してください（そのソフトウェアのドキュメントを参照する必要がある場合があります）。
duを使用して、ディスクをいっぱいにしているファイルを含むディレクトリを追跡します。
cd /
du -h --max-depth 1
/内のどのディレクトリが最も多くのスペースを使用しているかが表示されます。 duコマンドを実行しているファイルシステムをトラバースして、原因を見つけます。
例えば.
cd /
du -h --max-depth 1
/ usrは、システムで使用されている3.5Gの2.3Gを使用していることを示しています。
cd /usr
du -h --max-depth 1
/ usr/libが/ usrの2.3の1.1Gを使用していることを示しています...
これは、開いているファイルが削除されたことが原因である可能性もあります。
lsof を使用して、開いているがリンクされていない（削除された）ファイルを見つけることができます。
lsof +L1
トリックを行う必要があります。マニュアルページに記載されているように：
フォームの仕様
+L1は、リンクが解除されている開いているファイルを選択します。フォームの仕様+L1 <file_system>は、指定されたファイルシステムでリンクされていない開いているファイルを選択します。
/パーティションがいっぱいになっています。おそらく/var/logまたは/homeにあるものです。これはセットアップによって異なります。また、ユーザーがアクセスできる場所も調べてください。
問題の各ディレクトリで次のコマンドを実行します。これにより、スペースの最大の消費者であるサブディレクトリが表示されます。
cd /directory
du -cks -x * .* |sort -n
このアイデアは、O'Reillyの Linux Server Hacks のducksスクリプト（du -cks）から借用しています。私はこのコマンドを頻繁に実行します。
私の経験では、これはほとんどの場合、大きく成長しているログファイルが原因です。この場合、 Logrotate を使用し、必ずcompressionを使用してください。デフォルトの圧縮率でgzip圧縮を使用すると、ログファイルが80〜95％小さくなります（1GBの/ var/log/messagesは200MB以下に簡単に圧縮できます）。これによりCPUに中程度の負荷がかかりますが、これがサーバーの実際のパフォーマンスに影響を与えることはめったにありません。 Bzip2圧縮を使用したり、gzip --bestを使用したりすることを好む人もいますが、私の経験では、これにより多くのCPUオーバーヘッドが発生し、追加のメリットはほとんどありません。通常、デフォルトの比率のgzipで十分です。
そして明らかに、この問題はユーザーが悪いことをしていることが原因である場合があります。上記のduコマンドを使用して、原因を見つけます。
duコマンドを使用して、どのディレクトリがより多くのスペースを使用しているかを確認します。これにより、どのプログラムがそのスペースを使用しているかがわかります。グラフィカルアプリを実行できる場合、 いくつかの素敵なアプリがあります これは、KDirStatなどのduの出力を要約するのに役立ちます。
考えられる原因はログですが、最近変更された（または作成された）ファイルをサイズで並べ替えるコマンドは次のとおりです。
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
翌日; ±記号を探す
gt5
ログファイルがハードドライブをいっぱいにしている可能性があります。 logrotateを使用してそれを停止します。
皆さんの助けに感謝します
犯人は、隠されていた各共有ディレクターの隠された.recyclerフォルダーであることが判明しました。
ls -aを実行すると、それらを見ることができます。