磁盘空间不足，来源是什么？

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 gig，但是我无法检查所有文件夹

编辑 上升到

/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)。第一列是命令的名称，第二列是PID。您可以使用ps例如来更详细地查看命令ps auxww | grep PID，或者ps auxwwf | less -S以“森林”模式查看进程列表，以便查看PID来自哪个进程。跟踪保存打开的巨型文件的进程后，可以停止它以释放驱动器空间，然后找出如何修复它以正确关闭文件。造成这种情况的常见原因是一个logrotate脚本，该脚本重命名/删除了日志文件，但没有通知应用程序已这样做（通过以下方式发出适当的信号：kill

跑

du -h --max-depth=1 /

并且它应该给出更清晰的画面。如果它来来去去听起来好像是临时文件正在创建，但一旦完成就不会删除，直到导致它崩溃的任何进程。该服务器在什么操作系统上运行，并且是否运行任何特定功能？

看来问题出在哪里/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“已弃用”警告，我并没有真正注意它占用了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/debugfsdevice只是反映了的统计信息，因此它似乎是一条红线/。如果空间不足，那是由于某些东西填满了您的根文件系统。我会先检查您的/ var / log。

这个问题是由每分钟执行一次php CLI命令的cron任务引发的。PHP代码似乎陷于某种疯狂的循环中，该循环中捕获了错误，并且以处理器的速度增长了大量的调试数据。

由于正在执行的php代码花费了超过一分钟的时间，因此它没有考虑完成的工作，因此不断执行，这一次又一次地提高了（临时？）数据的增长速度。

相同的任务已经运行了将近一个月，没有任何问题，因此我认为这不是原因。

奇怪的是，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