☰

磁盘空间不足，原因是什么？

tag-icon • tag-icon ubuntu disk-space-utilization
磁盘空间不足，原因是什么？ 
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 GB，但我无法检查所有文件夹

编辑 上升到

/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

答案1

我认为您正在向已从驱动器中删除但尚未被应用程序/服务器关闭的文件写入内容，因此空间仍分配在磁盘上，但由于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重新启动应用程序），因此应用程序继续保持旧日志文件打开。

答案2

跑步

du -h --max-depth=1 /

而且它应该能给出更清晰的画面。如果它来来去去，听起来就像是创建了临时文件，然后在完成后没有被删除，直到导致它崩溃的进程。这台服务器运行的是什么操作系统，它是否运行了某些特定的东西？

答案3

问题似乎是/var/lib/ureadahead/debugfs。这似乎是一个已知问题，这里有一个指向 ubuntuforums 的链接，其中包含更多信息http://ubuntuguide.net/howto-fix-ureadahead-problem-after-upgrading-to-ubuntu-10-04。总结起来就是更新和升级，sudo mv /etc/init.d/ureadahead.conf /etc/init.d/ureadahead.conf.disabled然后重启。当然，我假设你运行的是 10.04。

答案4

如果空间消耗得非常快（不是很长时间），那么可能只是文件分配。

原因可能是某些应用程序占用了大量的交换文件或临时文件，这些文件在处理完毕后会被清空。

du --max-length=1当空间消耗很大时执行。

如果你认为你的根文件夹占用太多（3.3 GB），请尝试ll -a /并发布结果。

相关内容