![rm 间歇性地导致磁盘锁定](https://linux22.com/image/799477/rm%20%E9%97%B4%E6%AD%87%E6%80%A7%E5%9C%B0%E5%AF%BC%E8%87%B4%E7%A3%81%E7%9B%98%E9%94%81%E5%AE%9A.png)
我现在在两台服务器上都遇到了这个非常奇怪的问题,两台服务器都运行 CentOS5,都是 ext4。一个是 SSD,另一个是普通硬盘,都是没有 RAID 的 SATA。
问题如下,当我在具有大量子目录(> 1000)的目录上运行 rm -r 时,每个子目录都包含大量文件(> 1000),这些目录所在的磁盘将间歇性地锁定。
这可以通过 top 看到。通常,rm 命令的 CPU 使用率约为 50-60%,但突然间,它会在 10-15 秒内降至零,然后在 3-4 秒内恢复到 50-60%,然后再次降至零。在 rm 命令的 CPU 使用率为 0% 期间,即使是相关驱动器上的 ls 等简单命令也会挂起,屏幕上什么也不会显示,直到 rm 再次以 50-60% 运行。
当 rm 以 0% 运行时,在 top 中,我也得到 0.0%wa。
可以想象,磁盘的这种持续挂起会使处理变得极其缓慢。我犹豫着是否应该把这归咎于磁盘故障,因为我已经在两个不同的系统上看到了这种行为。
有人有什么想法吗?
编辑:还想指出,当 rm 以 0.0% CPU 运行时,jbd2/sdc1-8 在相关磁盘上仍然处于活动状态。
答案1
这不是解决方案,而是一种变通方法:您可以用 启动 rm ionice -c3
。如果您可以重现此问题,您可以使用 跟踪它strace -tt -o rm.strace rm ...
并联系 ext4 开发人员。
答案2
首先,
在 SSD 文件系统上,你需要启用忽略选项。例如
# mount -t ext4 -o discard /dev/ssd_dev /mnt/storage/location
你可以阅读它这里 (RedHat SSD Tuning)
最后,您可能需要检查块大小,因为硬盘和 SSD 的大小有所不同。但如果您不想重新安装系统,那么我认为使用 disgard 选项重新安装应该可以解决问题。
更新:rm 缓慢的原因可归因于文件系统写入屏障,如前所述这里
干杯,丹尼
答案3
删除数百万个文件会导致数百万个事务。这会很快填满日志。您看到的停顿是由于日志被刷新造成的。
使用更大的日志应该允许在刷新之前批量处理更多的交易,因此您应该会看到更少的此类停顿。
默认日志大小通常为 128 MB。您可以tune2fs -J size=512
在完全卸载的文件系统上使用,将日志大小增加四倍
答案4
我发现,当使用递归选项删除大量文件时,最好编写一个简单的 bash 脚本,使用 for 循环逐个删除文件。类似于:
for f in /path/to/dir/*
do
# if file, delete it
[ -f "$f" ] && rm "$f"
done