Linux下C++ pread函数读取5GB与64MB文件中64字节的性能对比及疑问

嘿，这个问题挺有意思的——按说NVMe SSD的随机读性能应该不分文件大小才对，但你的测试结果却出现了明显差异，我来帮你拆解下可能的原因：

1. 文件系统元数据的访问开销差异 #

你用的是Ext4文件系统，它对小文件和大文件的块映射方式不同：

• 对于64MB这种较小的文件，Ext4通常会用直接块或者短extent（扩展块）来记录数据位置，这些信息直接存在inode里，查找起来非常快，而且inode本身很小，很容易被缓存到CPU的LLC或者系统内存中。
• 对于5GB的大文件，Ext4会用多层extent树来管理块映射。要找到你指定的offset对应的物理块，需要遍历这个树结构，虽然这个过程很快，但相比小文件的直接查找，还是会多一些CPU周期，累积起来就会体现在latency上。

2. 页缓存（Page Cache）的命中率差异 #

你的代码里用的是O_RDONLY打开文件，没有加O_DIRECT，所以pread会经过系统的页缓存：

• 小文件的元数据（inode、extent信息）和数据块本身占用的内存更少，在你多次测试的过程中，这些内容更容易被留在页缓存甚至CPU的LLC里，后续的读取几乎是纯内存访问，速度自然更快。
• 5GB的文件内容量极大，即使只读取其中64字节，它对应的元数据（比如extent树的节点）可能因为系统内存的压力，更容易被挤出缓存，每次读取都需要重新从内存（甚至磁盘，极端情况）加载元数据，增加了延迟。

3. 测试细节的潜在影响 #

你提到测试了10次取平均，这里有个值得验证的点：每次测试前是否清空了系统缓存？如果没有的话，第一次读取是从磁盘加载，后续几次都是缓存命中，但大文件的缓存命中率可能比小文件低——毕竟系统内存有限，大文件的相关数据更容易被其他进程的缓存需求挤掉，导致部分测试轮次还是会触发磁盘IO，拉高原值。

怎么验证这些猜想？ #

给你几个小建议来确认原因：

• 加上O_DIRECT标志：修改open调用为open(filename, O_RDONLY | O_DIRECT)，绕开页缓存直接从磁盘读取。如果此时两个场景的latency变得接近，说明差异主要来自缓存和文件系统元数据的缓存开销。
• 每次测试前清空缓存：执行sudo echo 3 > /proc/sys/vm/drop_caches（需要root权限），然后再跑测试。对比冷缓存下的第一次读取延迟，看差异是否依然存在——如果冷缓存下差异缩小，说明页缓存是主要影响因素。
• 调整offset测试：换几个不同的合法offset（比如64MB文件里的不同位置，5GB文件里的不同位置），看差异是否稳定。如果差异始终存在，那大概率是文件系统元数据的访问开销导致的。

其实你最初的想法没错：NVMe SSD的物理随机读性能确实和文件大小无关，但文件系统层的额外开销（元数据查找、缓存策略）会让不同大小的文件在用户态的读取延迟上体现出差异。

备注：内容来源于stack exchange，提问作者Oliver