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为/
我认为你已经写了一个文件,这个文件已经从驱动器中删除了,但是还没有被应用程序/服务器closures,所以这个空间在磁盘上仍然是分配的,但是从文件系统中删除文件之后就不能被du
看到。 lsof
程序列出打开文件的进程。 如果你安装了更多的文件系统,并且数量没有太大的波动,那么我会build议你在一个非空目录的顶部安装一个文件系统(尽pipe你可以尝试使用umount /var/lib/ureadahead/debugfs
,并确保该目录是空的,并没有一堆垃圾写入隐藏在该挂载点下的目录)。
如果是这样,那么你应该很容易find这些与sudo lsof | grep deleted
sudo lsof | grep deleted
。 如果在进程仍然打开的情况下文件已被删除,则lsof
包括(deleted)
在最后一列中。 第一列是命令的名称,第二列是PID。 您可以使用ps
命令更详细地查看命令ps auxww | grep PID
ps auxww | grep PID
或ps auxwwf | less -S
ps auxwwf | less -S
在“森林”模式下查看进程列表,以便查看PID来自哪个进程。 一旦你已经跟踪了持有开放巨型文件的进程,你可以停止它来释放驱动器空间,然后找出如何解决它来正确closures文件。 通常的原因是一个logrotate脚本,它重命名/删除日志文件,但不会通知应用程序它已经这样做(通过kill
适当的信号或重新启动应用程序),所以应用程序继续保持旧的日志文件打开。
跑
du -h --max-depth=1 /
它应该给一个更清晰的画面。 如果它来了,它听起来像临时文件正在创build,然后不删除一次,直到任何一个进程造成它崩溃。 这个服务器运行的是什么操作系统,它运行的是什么?
看起来问题是/var/lib/ureadahead/debugfs
。 看来这是一个已知的问题,这里是一个链接到Ubuntu的更多信息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
中存在/var/lib/ureadahead/debugfs
,但在/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
创build1GB文件:
$ 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代码似乎陷入了某种错误的疯狂循环,以及处理器速度增长的大量debugging数据。
由于正在执行的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