du -sh
我正在各种目录中运行以查找占用大量磁盘空间的程序。我有两台相同的服务器(Dell PE2850),都装有 RHEL5,du
在一台服务器上运行的时间明显长于在另一台服务器上运行的时间。
例如,du -sh /opt/foobar
在服务器 A(大约有 25 GB)上执行此操作需要 5 分钟,而在服务器 B 上,使用相同数量的数据执行相同的命令几乎会立即向我报告结果。在运行 top 等时,我没有看到任何明显的变化。
任何意见是极大的赞赏。
答案1
如果该目录中有大量文件,并且目录内容不断更改,目录条目本身会随着时间的推移而变得碎片化。然后,当操作系统读取目录内容时,将会出现大量不必要的磁盘寻道。这种情况尤其发生在 ext* 文件系统(ext4 可能更好)和旧的 ReiserFS v3.x 文件系统(如果已超过 85% 左右)。
解决方案很简单:
cp -pr origdir newdir
mv origdir origdir.bak
mv newdir origdir
当然,如果所有内容都缓存在 RAM 中,那么这并不重要;通常 Linux 会非常积极地缓存经常访问的文件和目录。如果您确实想将这些目录的内容保留在 RAM 中,您可以将类似的东西放入ls -lah /your/dir 2>&1 >/dev/null
您的 cron 中。
编辑:哦,我突然想到了一件事。如果您的服务器有一个带电池备份的 RAID 控制器,并且里面有一些缓存,请检查电池是否正常。我见过电池没电的情况,控制器完全禁用缓存,严重破坏了性能。例如,HP 服务器可能会在 iLO 日志中显示有关控制器电池的信息;在实际的服务器健康仪表板上,一切似乎都很好,而且是绿色的,但只有日志条目会告诉您有关这一点的信息。
答案2
我建议尝试使用简单的 du 命令,不带任何开关。您最终会看到哪个目录正在减慢该过程。可能是磁盘故障,或者其他原因,...
答案3
这只是我自己遇到的另一个陷阱
我忘记了在我的目录树中的一个文件夹中安装了一个巨大的网络驱动器。
啊,卑鄙的我!
$mount
看看是否如此
$sudo umount /path/to/mount/point
对于这个用例来说,符号和硬链接可能也是一个问题?
答案4
列出目录并运行 du 命令就可以了
ls -lrt | awk'{打印$9}'| xargs du -sh