在有大量小文件的系统中,EXT4 的性能变得非常糟糕

在有大量小文件的系统中,EXT4 的性能变得非常糟糕

我有一个小型嵌入式设备,只有 128MB 的 RAM

该设备附带一个 2TB USB2 硬盘

我一直对设备的性能非常满意,直到最近文件数量超过了阈值或磁盘容量超过了阈值(我不确定是哪一个)

磁盘上有许多小文件,由于写入应用程序的性质,文件被组织成非常平衡的方式- 没有一个叶节点目录包含超过 200 个文件,并且文件数量刚好超过 800,000 个。

我希望能找到一些线索来调查。磁盘性能大幅下降,设备运行良好,然后突然间性能急剧下降。

我的假设是,我在磁盘上为文件选择的组织结构在某种程度上损害了 inode 缓存保持快速的能力。

作为实验,我卸载了磁盘(刷新缓存,使用 free 进行验证)。然后,我从命令提示符深入浏览目录结构。总而言之,这个目录(及其子目录)下只包含大约 3200 个文件,此时“free”显示有 >117MB 的可用内存

此时,我输入命令“find”,然后输入“free”

“find” 显示大约 3000 个文件,但内存使用量从约 117MB 降至约 2MB

我了解缓存与可用内存之间的平衡,以及内核如何将空页视为坏页 - 但是来自 3000 个文件的目录的 115MB 缓存内容表明我的理解存在严重差距。我希望有人能帮助我了解发生了什么

我可以假设平衡树是存储大量文件的最佳方式吗?

答案1

非常好的问题描述。

根据你所说的,我认为你看到的是 slab 使用率升高。一个很好的实验是运行一个cat /proc/meminfocat /proc/slabinfo延迟 3 秒,同时深入 fs 层次结构并发现 3000 个文件。本质上发生的事情是内核将遍历 fs 结构并扫描单个文件及其 inode,并且它们都存储在内存中。如果你检查,/proc/slabinfo你会看到一个名为的对象ext4_inode_cache,它会告诉你每个 inode 将占用多少内存。将其乘以对象数(obj_size * no_obj),你将得到对象使用的内存量。你进入 fs 层次越深,消耗的内存就越多,直到系统达到内存区域的高水位。此时,内核将开始回收。

如果您查看 meminfo 和 slabinfo,您将获得所需的详细信息。如果您想让我查看,请将其粘贴到 pastebin 中 ;)

相关内容