ディスク領域が不足しているのは、ソースは何ですか？

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% /

*更新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に注意してください

ドライブから削除されたが、アプリケーション/サーバーによってまだ閉じられていないファイルに何か書き込みがあると思うので、ディスク上のスペースは割り当てられたまま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。これは既知の問題のようです。詳細はhttp://ubuntuguide.net/howto-fix-ureadahead-problem-after-upgrading-to-ubuntu-10-04の ubuntuforumsへのリンクです。tl; drは更新とアップグレードのようでsudo mv /etc/init.d/ureadahead.conf /etc/init.d/ureadahead.conf.disabled、再起動します。もちろん、10.04を実行していると仮定しています。

私の推測では、ログファイルです。開発サーバーのApacheログにPHP 5.3「非推奨」警告が非常に多かったため、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

で1GBファイルを作成/tmp：

$ 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を確認します。

問題は毎分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