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

Question

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

编辑 上升到

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

Answer 1

我认为您正在写入已从驱动器中删除但尚未被应用程序/服务器关闭的文件，因此该空间仍分配在磁盘上，但du由于该文件已从文件系统中删除而无法看到。该lsof程序列出了打开文件的进程。如果您安装了更多文件系统并且数量没有太大波动，那么我会建议您将文件系统安装在非空目录的顶部（尽管您可以尝试umount /var/lib/ureadahead/debugfs确保该目录为空并且没有一堆垃圾写入隐藏在该挂载点下的目录中）。

如果是这种情况，那么您应该使用sudo lsof | grep deleted. 如果文件已被删除而进程仍处于打开状态，则lsof包括(deleted)在最后一列中。第一列是命令的名称，第二列是 PID。您可以使用get在命令的更多详细信息ps，例如ps auxww | grep PID，或者ps auxwwf | less -S看到“森林”模式中的进程列表，所以你可以看到什么进程PID是从哪里来的。一旦您追踪到保存打开的巨型文件的进程，您可以停止它以释放驱动器空间，然后找出如何修复它以正确关闭文件。造成这种情况的通常原因是一个 logrotate 脚本，它重命名/删除日志文件，但不通知应用程序它已经这样做了（通过适当的信号与kill 或通过重新启动应用程序），因此应用程序继续保持旧的日志文件打开。

Answer 2

跑

du -h --max-depth=1 /

它应该给出更清晰的画面。如果它来来去去，听起来像是创建了临时文件，然后一旦完成就不会删除，直到导致它崩溃的任何进程。这台服务器运行的是什么操作系统，它是否在运行任何特别的东西？

Answer 3

看起来问题是/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。

Answer 4

该问题是由每分钟执行 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 的值被硬编码为无限制！奥奥