ディスク容量が不足していますが、ソースは何ですか？
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 220G 220G 0 100% /
none 1.9G 168K 1.9G 1% /dev
none 1.9G 0 1.9G 0% /dev/shm
none 1.9G 52K 1.9G 1% /var/run
none 1.9G 0 1.9G 0% /var/lock
none 1.9G 0 1.9G 0% /lib/init/rw
none 220G 220G 0 100% /var/lib/ureadahead/debugfs
年齢のように見えた後、パニック状態で答えを探している間、使用は減少しました
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 220G 9.3G 200G 5% /
none 1.9G 168K 1.9G 1% /dev
none 1.9G 0 1.9G 0% /dev/shm
none 1.9G 52K 1.9G 1% /var/run
none 1.9G 0 1.9G 0% /var/lock
none 1.9G 0 1.9G 0% /lib/init/rw
none 220G 9.3G 200G 5% /var/lib/ureadahead/debugfs
私はこれまで何も削除しておらず、今これを書いているところです
/dev/sda1 220G 12G 197G 6% /
何が起こった？？原因を調査し、再発しないようにするにはどうすればよいですか？
マッサージの使用中に、/ varフォルダーのサイズは1.8ギガで一定であることがわかりましたが、すべてのフォルダーを確認することができませんでした
編集まで
/dev/sda1 220G 18G 192G 9% /
* update 2 *再び増加します
ubuntu /: df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 220G 43G 167G 21% /
none 1.9G 168K 1.9G 1% /dev
none 1.9G 0 1.9G 0% /dev/shm
none 1.9G 52K 1.9G 1% /var/run
none 1.9G 0 1.9G 0% /var/lock
none 1.9G 0 1.9G 0% /lib/init/rw
none 220G 43G 167G 21% /var/lib/ureadahead/debugfs
そして、私が与えられたコマンドをチェックします
ubuntu /: du -h --max-depth=1 /
31M /boot
4.0K /selinux
8.0K /srv
7.4M /bin
du: cannot access `/proc/9993/task/9993/fd/4': No such file or directory
du: cannot access `/proc/9993/task/9993/fdinfo/4': No such file or directory
du: cannot access `/proc/9993/fd/4': No such file or directory
du: cannot access `/proc/9993/fdinfo/4': No such file or directory
0 /proc
12K /tmp
2.4G /var
0 /sys
100K /root
4.0K /media
575M /usr
4.0K /opt
16K /lost+found
4.5M /home
270M /lib
168K /dev
4.0K /mnt
6.7M /sbin
6.1M /etc
4.0K /cdrom
3.3G /
/の3.3Gに注意してください
この問題は、php CLIコマンドを毎分実行するcronタスクによって引き起こされていました。 PHPコードは、キャッチされたエラーとプロセッサの速度で増大する大量のデバッグデータのある種の狂気のループで立ち往生しているようです。
実行中のphpコードは、ジョブが完了したとは見なさないため、1分以上かかったため、繰り返し実行され続け、（一時的な？）データの増加速度が増加しました。
同じタスクが1か月近く実行されて問題はなかったため、原因としては考えられませんでした。
奇妙なことは、phpスクリプトが最大実行時間を手動で設定することです
手がかりについてphp.iniをチェックしました
; Maximum execution time of each script, in seconds
; http://php.net/max-execution-time
; Note: This directive is hardcoded to 0 for the CLI SAPI
max_execution_time = 30
; Maximum amount of time each script may spend parsing request data. It's a good
; idea to limit this time on productions servers in order to eliminate unexpect$
; long running scripts.
; Note: This directive is hardcoded to -1 for the CLI SAPI
; Default Value: -1 (Unlimited)
; Development Value: 60 (60 seconds)
; Production Value: 60 (60 seconds)
; http://php.net/max-input-time
max_input_time = 60
これは、CLIの値が無制限にハードコードされていることを示しています。 O_o
ドライブから削除されたが、アプリケーション/サーバーによってまだ閉じられていないファイルに何か書き込みをしていると思います。そのため、ディスクに割り当てられた領域は残りますが、ファイルがduで表示されませんファイルシステムから削除されました。 lsofプログラムは、ファイルを開いているプロセスをリストします。より多くのファイルシステムをマウントしていて、その数がそれほど変動しない場合は、空ではないディレクトリの上にファイルシステムをマウントしたことをお勧めします（ただし、umount /var/lib/ureadahead/debugfsを試して、そのディレクトリは空であり、そのマウントポイントの下に隠れているディレクトリに書き込まれる大量のジャンクはありません）。
その場合は、Sudo lsof | grep deletedを使用して簡単に見つけることができます。 lsofは、プロセスがまだ開いている間にファイルが削除された場合、最後の列に(deleted)を含めます。最初の列はコマンドの名前、2番目の列はPIDです。 ps、たとえばps auxww | grep PID、またはps auxwwf | less -Sを使用してコマンドをより詳細に確認し、「フォレスト」モードでプロセスリストを表示して、PIDがどのプロセスから来たかを確認できます。から。開いている巨大なファイルを保持しているプロセスを追跡したら、それを停止してドライブ領域を解放し、それを修正してファイルを適切に閉じる方法を見つけます。これの通常の原因は、ログファイルの名前を変更または削除するlogrotateスクリプトですが、そのことをアプリケーションに通知しません（killを使用した適切なシグナルまたはアプリケーションの再起動によって）。古いログファイルを開いたままにします。
走る
du -h --max-depth=1 /
そして、それはより明確な絵を与えるはずです。出入りするときに、一時ファイルが作成されてから一度削除されないように聞こえる場合は、いずれかのプロセスがクラッシュを引き起こすまでは。このサーバーはどのOSを実行しており、特に何を実行していますか？
問題は/var/lib/ureadahead/debugfsのようです。これは既知の問題のようです。ここに詳細情報を含むubuntuforumsへのリンクがあります http://ubuntuguide.net/howto-fix-ureadahead-problem-after-upgrading-to-ubuntu-10-04 =。 tl; drはアップデートとアップグレードのようで、Sudo mv /etc/init.d/ureadahead.conf /etc/init.d/ureadahead.conf.disabledの後に再起動します。もちろん、私はあなたが10.04を実行していると想定しています。
私の推測はログファイルです。開発サーバーのApacheログにPHP 5.3 "deprecated"という警告が多すぎて、varパーティションの8GBのスペースがすべて消費されたことに特に注意を払っていませんでした。問題の補足記事：ルートパーティションが不足するとシステムが不安定になる可能性があるので、常に/ varを別のパーティションに置く必要があります。
スペースが非常に速く消費された場合（古くない場合）、おそらくファイルの割り当てだけです。
原因は、一部のアプリケーションの巨大なスワップまたは一時ファイルである可能性があり、それらはそのプロセスの後に空になります。
du --max-length=1スペースが大量に消費される場合。
ルートフォルダーが多すぎる（3.3 GB）と思われる場合は、ll -a /を試して結果を投稿してください。
/var/lib/ureadahead/debugfsは赤毛のようです。その理由は...
/var/lib/ureadahead/debugfsは/etc/mtabには存在しますが、/proc/mountsにはありません。
$ mount | grep debug
none on /sys/kernel/debug type debugfs (rw)
none on /var/lib/ureadahead/debugfs type debugfs (rw,relatime)
$ cat /proc/mounts | grep debug
none /sys/kernel/debug debugfs rw,relatime 0 0
dfコマンドは、/var/lib/ureadahead/debugfsと/についてまったく同じことを報告しているようです
$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 10321208 1681128 8115792 18% /
none 830388 120 830268 1% /dev
none 880752 0 880752 0% /dev/shm
none 880752 60 880692 1% /var/run
none 880752 0 880752 0% /var/lock
none 880752 0 880752 0% /lib/init/rw
none 10321208 1681128 8115792 18% /var/lib/ureadahead/debugfs
/dev/sdb 153899044 192068 145889352 1% /mnt
/tmpに1GBファイルを作成：
$ dd if=/dev/zero of=/tmp/carypjunk.out bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 52.7234 s, 20.4 MB/s
両方の場所で報告されたサイズを表示します。
$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 10321208 2730216 7066704 28% /
none 830388 120 830268 1% /dev
none 880752 0 880752 0% /dev/shm
none 880752 60 880692 1% /var/run
none 880752 0 880752 0% /var/lock
none 880752 0 880752 0% /lib/init/rw
none 10321208 2730216 7066704 28% /var/lib/ureadahead/debugfs
/dev/sdb 153899044 192068 145889352 1% /mnt
そのため、/var/lib/ureadahead/debugfsの統計情報をミラーリングしているだけなので、/デバイスは問題を抱えているようです。スペースが不足している場合は、ルートファイルシステムがいっぱいになっていることが原因です。最初に/ var/logを確認します。