在 linux 上删除大量文件会占用 CPU

Question

我在我的 RHEL 服务器上生成了超过 50GB 的缓存文件（典型的文件大小是 200kb，所以没有文件很大）。当我尝试删除这些文件时，需要 8-10 个小时。

然而，更大的问题是系统负载在这 8-10 个小时内变得至关重要。无论如何，我可以在删除过程中控制系统负载。

我尝试使用

nice -n19 rm -rf *

但这对系统负载没有帮助。

PS 我在superuser.com上问了同样的问题，但没有得到足够好的答案，所以在这里尝试。

Answer 1

以下是各种操作和文件系统的一些基准，供您参考。（当然，在繁忙的系统上，您会得到不同的结果，但希望这能让您了解会发生什么）。

如果我坐在你的椅子上，我会尝试获得场景的基线基准：

• 确定操作将在与其他所有内容隔离的裸硬件上花费多长时间（是的，即使在相当旧的硬件上，它也应该花费远远少于 7-8 小时）。
• 尝试添加通常以受控方式发生的其他操作，看看究竟是什么让它运行了这么长时间

一些数字。

在 5 岁的笔记本上， ext3安装了 rw、noatime、运行 top 等等，用 shell 脚本 create10kdirs.sh 创建 10k 个目录

#!/bin/bash
for i in $(seq 10000)
do
    mkdir $i
done

须藤时间./create10kdirs.sh
24.59user
20.70system
0:47.04elapsed
96%CPU (0avgtext+0avgdata 0maxresident)k80inputs+8outputs (1major+2735150minor)pagefaults 0swaps

删除 10k 个目录 sudo time rm -rf
0.10user
19.75system
0:20.71elapsed
95%CPU (0avgtext+0avgdata 0maxresident)k0inputs+8outputs (0major+222minor)pagefaults 0swaps

相同的硬件，ext4挂载 rw，noatime 使用 shell 脚本创建 10k 个目录 sudo time create10kdirs.sh
23.96user
22.31system
0:49.26elapsed
93%CPU (0avgtext+0avgdata0maxresident)k1896inputs+8outputs(27150pages+2715000000)

删除 10k 个目录 sudo time rm -rf
0.13user
16.96system
0:28.21elapsed
60%CPU (0avgtext+0avgdata0maxresident)k10160inputs+0outputs(1major+219minor)pagefaults0swaps

4 年旧笔记本，xfs安装 rw，relatime，USB 上无障碍 sudo time create10kdirs.sh
14.19user
13.86system
0:29.75elapsed
94%CPU (0avgtext+0avgdata0maxresident)k432inputs+0outputs(1major+0outputs(1major+3waaults027)

删除 10k 个目录
sudo time rm -rf
0.13user
2.65system
0:08.20elapsed
33%CPU (0avgtext+0avgdata 0maxresident)k120inputs+0outputs (1major+222minor)pagefaults 0swaps

结论：这个旧硬件将在大约 21 秒 * 40 = 12 分钟 40 秒内擦除 ext3 上的 40 万个小文件+文件夹。在 xfs（无障碍）上，它会在大约 5m20s 内完成。在这两个测试案例中，测试机器都没有承受沉重的负载，但对我来说，您的问题似乎与您选择的文件系统没有严格的关系。

EDIT2 另外，在超过基准测试后，我去尝试使用 find 删除。-mindepth 1 -maxdepth 1 -delete

和结果！：

ext3 使用 sudo time find 删除 10k 个目录。-mindepth 1 -maxdepth 1 -delete
0.04user
0.44system
0:00.88elapsed
55%CPU (0avgtext+0avgdata 0maxresident)k516inputs+8outputs(1major+688minor)pagefaults0swaps

ext4 使用
sudo time find删除 10k 个目录。-mindepth 1 -maxdepth 1 -delete
0.05user
0.66system
0:01.02elapsed
70%CPU (0avgtext+0avgdata 0maxresident)k568inputs+0outputs (1major+689minor)pagefaults swaps

xfs 使用
sudo time find删除 10k 个目录。-mindepth 1 -maxdepth 1 -delete
0.06user
0.84system
0:04.55elapsed
19%CPU (0avgtext+0avgdata 0maxresident)k416inputs+0outputs (3major+685minor)pagefaults 0swaps

真正的结论是 rm -rf 不是很聪明，它在大树上表现不佳。（前提是我的测试用例确实具有代表性）。

注意：我还测试了 xargs 变体，它很快，但没有上面的那么快。

Answer 2

正如您在评论中提到的，您正在使用ext3.

众所周知，rmext3 上大文件的性能很差；它是固定在ext4. 例如，请参阅这篇文章或kernelnewbies（其中提到扩展区可提高大文件的删除和截断速度）。

我不知道这在多大程度上适用于您的典型文件大小。我希望它至少应用一点，因为在大约 200kB 的情况下，您已经在 上使用了间接块ext3，而不是在 上使用了单个范围ext4。

作为一种解决方法（因为您可能不会ext4仅为此升级），每次只删除几个文件并sleep在删除之间添加一个。它不漂亮，但应该有助于减少负载。

此外，如果在断电时丢失文件不是问题（因为它是某种缓存），您可以将它们放在一个单独的分区中，您可以mkfs在启动时再次使用该分区，并且ext3无需日志甚至ext2. 高负载的原因可能是日志刷新到磁盘与读取冲突（您在另一篇文章中提到您有很多并发读取）。