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

以下是各种操作和文件系统的一些基准 ，供您参考。 （在一个繁忙的系统当然你会有不同的结果，但希望这会给你一个想法）。

如果我将在你的座位上，我会尝试获得该场景的基准基准：

• 确定操作需要花费多长时间才能完全隔离硬件（是的，即使在相当陈旧的硬件上也要花费7-8小时）。
• 尝试添加通常以受控方式发生的其他操作，并查看实际运行这么久的内容

一些数字。

在5岁的笔记本电脑上， ext3安装了rw，noatime，运行上面，并且没有什么比使用shell脚本创build10k目录create10kdirs.sh

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

sudo time ./create10kdirs.sh
24.59user
20.70system
0：47.04elapsed
96％CPU（0avgtext + 0avgdata 0maxresident）k80inputs + 8outputs（1major + 2735150minor）pagefaults 0swaps

用sudo time rm -rf删除10k目录
0.10user
19.75system
0：20.71elapsed
95％CPU（0avgtext + 0avgdata 0maxresident）k0inputs + 8outputs（0major + 222minor）pagefaults 0swaps

相同的硬件， ext4挂载rw，noatime使用shell脚本创build10k目录sudo time create10kdirs.sh
23.96user
22.31system
0：49.26elapsed
93％CPU（0avgtext + 0avgdata0maxresident）k1896inputs + 8outputs（20major + 2715174minor）pagefaults 0swaps

用sudo time rm -rf删除10k目录
0.13user
16.96system
0：28.21elapsed
60％CPU（0avgtext + 0avgdata0maxresident）k10160inputs + 0outputs（1major + 219minor）pagefaults0swaps

4岁的笔记本， xfs安装rw，relatime，nobarrier上USB sudo时间create10kdirs.sh
14.19user
13.86system
0：29.75elapsed
94％CPU（0avgtext + 0avgdata0maxresident）k432inputs + 0outputs（1major + 2735243minor）pagefaults 0swaps

删除10K目录
sudo time rm -rf
0.13user
2.65system
0：08.20elapsed
33％CPU （0avgtext + 0avgdata 0maxresident）k120inputs + 0outputs（1major + 222minor）pagefaults 0swaps

结论：这个旧的硬件会在ext3上删除大约21s * 40 = 12m40s的400k小文件+文件夹。 在xfs（与nobarriers）它会做约5分20秒。 在这两个testing案例中，testing机器都没有承受过重的负担，但对我来说，你的问题似乎与你select的文件系统没有严格的关系。

编辑2此外，运行以上的基准后，我去尝试删除与查找。 -mindepth 1 -maxdepth 1 -delete

和结果!:

ext3用sudo时间查找删除10k目录。 -mindepth 1 -maxdepth 1 -delete
0.04user
0.44system
0：00.88elapsed
55％CPU（0avgtext + 0avgdata 0maxresident）k516inputs + 8outputs（1major + 688minor）pagefaults0swaps

ext4删除10k目录
sudo时间查找。 -mindepth 1 -maxdepth 1 -delete
0.05user
0.66system
0：01.02elapsed
70％CPU（0avgtext + 0avgdata 0maxresident）k568inputs + 0outputs（1major + 689minor）pagefaults swaps

xfs删除10k目录
sudo时间查找。 -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不是很聪明，而且对于大树来说，性能不佳。 （假设我的testing案例真的有代表性）。

注意：我也testing了xargs变种，它速度很快，但速度不如以上。

正如你在评论中提到的，你使用的是ext3 。

众所周知，ext3上大文件的性能很差， 它是ext4中固定的东西之一。 比如看这个post ，或者kernelnewbies （其中提到了extents改进了大文件的删除和截断速度）。

我不知道这是多less适用于您的典型文件大小。 我希望它至less应用一点，因为在200kB左右，你已经在ext3上使用了间接块，而在ext4上可能只有一个。

作为一个解决方法（因为你可能不会升级到ext4 ），每次只删除几个文件，并在删除之间添加一个sleep 。 这不是很好，但应该有助于减轻负载。

另外，如果丢失掉电文件不是问题（因为它是某种types的caching），你可以把它们放在一个单独的分区上，你可以在启动的时候再次使用mkfs ，并且使用没有日志甚至是ext2 ext3 。 高负载的原因可能是日志被冲刷到与读取冲突的磁盘（在另一篇文章中提到，您有大量的并发读取）。

也许壳是问题的原因。 你应该直接使用find： find /dir -mindepth 1 -maxdepth 1 -delete

这可能是也可能不是相关的：但是我曾经有过这样的场合， rm无法处理我在命令行上提供的文件数量（通过星形运算符）。 相反，我会从shell中使用以下命令：

 for i in *; do rm -rf $i; done 

在这种情况下，你可能会删除树，在这种情况下，上述可能不会做你所需要的。 您可能必须将删除操作拆分为多个部分，例如

 for i in [a-mA-M]*; do rm -rf $i; done for i in [n-zN-Z]*; do rm -rf $i; done 

那只有25万个左右的文件，真的不应该是个问题 – 你使用的是什么文件系统，这个卷是用来做其他事情的吗？

当你有很多像你描述的文件，你每次都调用该命令。 另外，你必须记住在日志FS你正在处理缓冲区命中和元数据，这可能会大大影响处理时间。

你最好的select就是使用上面提到的find命令，而不是显而易见的特性。

 find / -name filename.* -exec /bin/rm -f '{}' \+ 

基本上“+”是你的朋友。 这样做是以集合的forms创build文件名，每组调用一次rm命令。 这和'xargs'的function几乎一样，但是如果在BSD / Linux上，你不必担心正确的标志。

非常好奇，它为你加速了多less。 所以如果你还在身边，请回复。 祝你好运 ！

在研究了文件系统基准之后，我select了JFS作为我的mythtvvideo文件的文件存储，因为文件删除速度很快（mythtv等待删除完成，使IO缓慢）。

你也可以通过“find”和“xargs”而不是rm -rf来调用“rm”。 这可能会更快：

 find <dir> | xargs rm 

如何pipe理这些文件列表到Perl和使用其unlinkfunction？

 find <dir> | perl -nle 'unlink;' 

我同意不应该花那么长时间，但根据所使用的底层存储，可能需要进行精读。 我认为最终你最好的解决办法是添加额外的磁盘，并把它们分开。 如果沿着这条路线走下去，RAID可能会在某些情况下有所帮助 iostat在这些时间告诉你什么？ 你也可以使用for循环，并在'time'中包装'rm'命令来获得一些额外的信息。

另一种可能性，取决于你的设置和当然的应用，但也许你可以使这些caching文件在不同的分区，只是定期格式化驱动器，而不是删除文件？ 我认为运行mkfs可以大大减less时间，但是在这种情况下你的应用程序将不可用，所以它不会很理想。

我也喜欢更频繁地清理它们的想法。 在cron中说你每小时安排一次这样的事情：

find ./ -maxdepth 1 -type f -name“some pattern”-ctime +1 -exec rm -f {} \;

这会删除每个超过24小时的文件，而不是一次尝试完成。