☰

rm 间歇性地导致磁盘锁定

tag-icon • tag-icon linux performance storage rm
rm 间歇性地导致磁盘锁定

我现在在两台服务器上都遇到了这个非常奇怪的问题，两台服务器都运行 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

相关内容