linux目录文件太多导致卡死存储 minio dfs【实战】

悠悠 2024-03-16 12:06 19阅读 0赞

### 省流： ###

ls -1 -f

### ls 和 ls -1 -f ###

你一定遇到过这种情况，在一个有几百万文件的目录中执行ls命令，ls就卡在那了，是吧？

用 ls -1 -f 命令可以立即显示出文件。如果你想删除当前目录中的所有文件，使用如下命令：

ls -1 -f | xargs rm

在清理大量不需要的文件后，会留下一个巨大稀疏的目录对象(directory object)。

假如**一个目录有300万个文件**，除了这些文件占用空间外，**目录对象本身也会占用超过100M**的空间。

你也许想重建一个目录来回收那100M空间。但是，如果目录是/tmp，那就要小心了，只能在单用户模式下操作。

ls命令为什么会卡住？

默认情况下，**ls 命令会将输出排序**。为了排序，ls命令**先将所有文件的名称读入内存**。当遇到一个非常大的目录时，它就在那里不断地读入文件名，并且内存占用越来越大，直到将所有文件一次性以字母数字顺序列出来。

而 **ls -1 -f 命令**并不执行排序操作，只是**读取目录然后立即显示文件**。

### 案例 ###

#### 速度(时间) ####

下面举个例子，有个目录，包含300万个文件，文件名称形如test\_file\_a\_1, test\_file\_a\_2, ..., test\_file\_a\_3000000. 用Perl脚本以文件名中的数字编号顺序来创建这些文件。

可以用ls -1 -f命令立即列出头几个文件：

> bash-4.2$ time ls -1 -f | head
> 
> .
> 
> ..
> 
> test\_file\_a\_2531963
> 
> test\_file\_a\_467778
> 
> test\_file\_a\_2677947
> 
> test\_file\_a\_329896
> 
> test\_file\_a\_835701
> 
> test\_file\_a\_1266060
> 
> test\_file\_a\_261887
> 
> test\_file\_a\_311007
> 
> real 0m0.006s
> 
> user 0m0.000s
> 
> sys 0m0.008s

现在，去掉上面命令中的-1和-f标志，ls命令花了大约10000倍长的时间：

> bash-4.2$ time /bin/ls | head
> 
> test\_file\_a\_1
> 
> test\_file\_a\_10
> 
> test\_file\_a\_100
> 
> test\_file\_a\_1000
> 
> test\_file\_a\_10000
> 
> test\_file\_a\_100000
> 
> test\_file\_a\_1000000
> 
> test\_file\_a\_1000001
> 
> test\_file\_a\_1000002
> 
> test\_file\_a\_1000003
> 
> real 0m57.880s
> 
> user 0m55.644s
> 
> sys 0m2.121s

#### 内存占用 ####

除了变得更慢外，后者还占用了大量内存。当ls命令真正开始打印文件名的时候，它已经**在内存中存储了300万个文件名，使用了大约507M内存**。相反，**ls -1 -f命令内存占用从未超过4.5M**，少了100倍。

EXT3/EXT4文件系统的Bug？

遍历EXT3/4文件系统花这么长时间和这么多资源有时被认为是文件系统Bug。但是我个人认为，如果有Bug的话，那只能是**遍历软件的Bug(比如，find命令、不带-1和-f标识的ls命令以及各种备份软件)**，而不是文件系统的Bug。

注意顺序

在上面的测试中还有一点蹊跷之处。ls命令将文件名按照字母数字顺序排好了序，但是ls -1 -f命令的输出是以什么顺序呢？看起来比较随机。头三个文件是test\_file\_a\_2531963、test\_file\_a\_467778和test\_file\_a\_2677947。这个次序与文件创建时间、修改时间、inode编号或者其它顺序都不符合。那到底是怎么回事？

测试使用的是EXT4文件系统。EXT4和EXT3文件系统使用一种叫做HTree的哈希算法来存储文件名。当读取目录时，文件名是以任意顺序返回的。因此，ls -1 -f的输出结果看起来混在一起不是有序的。

EXT2文件系统的行为有时候像本文中所说的EXT3和EXT4一样(比如在Fedora 16系统上)，有时又不是(比如在Red Hat 4系统上)，而是按照文件创建时间返回文件。Solaris UFS文件系统也一样。

进程卡住？看看它在干什么

当ls -1 -f命令不可用时，可以用strace(Linux系统)或者truss(Solaris系统)命令来监视进程来发现有用信息。在我同事Neil Dixon使用strace来监视ls进程时，我才发现这一巧妙方法。在终端中执行：

cd verybigdir

ls -l > /dev/null

然后获取ls进程的PID，在另一个终端中监视它，就可以看到ls正在获取每个文件的元信息：

\[root@saturn ~\]\# strace -p 3963 2>&1 | grep lstat

lstat64(“test\_file\_a\_2433028″, \{st\_mode=S\_IFREG|0664, st\_size=0, …\}) = 0

lstat64(“test\_file\_a\_2047256″, \{st\_mode=S\_IFREG|0664, st\_size=0, …\}) = 0

lstat64(“test\_file\_a\_1201573″, \{st\_mode=S\_IFREG|0664, st\_size=0, …\}) = 0

这样就能立即看到文件名了。如果你想删掉它们，将上述strace的输出重定向到AWK处理。