我正在做一个项目，我将文件系统用作数据库。我每天做一个批处理作业，写入数万个小文件，然后从这些文件中读取。
这些文件可以完全放入机器的 RAM 中，尽管仍然有几十 GB。
各种各样的问题：
【问题讨论】：
标签： performance filesystems batch-processing disk solid-state-drive
单个大读取比许多相同大小的小读取快还是慢？
这取决于，但通常是的。
一方面，SSD 每秒可以执行的 IO 请求数（请参阅IOPS）是有限的。虽然与 HDD（尤其是新的 SSD）相比，SSD 的这个限制相当大，但这通常是有效读取许多小文件的限制。请注意，当前的高性能 NVMe SSD 可以达到大约 300K IOPS。但是，文件系统需要对每个文件执行多个 IO 请求。因此，请记住，读取的小文件数量通常要少得多。
另一方面，读取大缓冲区可能会更慢，因为操作系统通常需要执行缓冲区的内部副本，当缓冲区不适合高性能 SSD 上的 CPU 缓存时，这会带来很大的开销。请注意，这非常依赖于用于读取目标文件的 API（请参阅this 相关答案的第二部分）。大多数用于读取/写入文件的标准库实际上是缓冲，因此读取非常小的块并没有那么慢（由于额外的调用/操作，它仍然比中等大小的块慢）。缓冲只有在顺序读/写时才有可能。
我是否可以通过首先将所有文件以我的语言写入“内存中”FS 并稍后在单个批处理中写入磁盘来提高性能？
可能不会。这高度依赖于操作系统实现和应用程序的访问模式。如果写入是连续的，我不希望在快速 SSD 上显着加快速度，因为在 RAM 中写入+读取文件会增加开销，并且管理文件的成本会支付两倍。此外，请注意，某些操作系统会限制 in-RAM FS 的大小，并且可以保留此空间（需要对其进行调整并且通常需要高级权限）。此外，大多数操作系统都倾向于在 RAM 中缓存读取/写入的文件（但以比 RAM FS 更有效的方式）。默认情况下Windows 和Linux 都是这种情况。
同样的问题。将整个文件夹加载到内存中的 FS 与分派许多散布在处理代码中的小读取相比更快吗？
大多数操作系统可以在内存中缓存读取/写入的文件，以便以后更快地读取它们。当进程请求内存时，操作系统负责释放缓存。你通常很难控制它的行为。如果文件已经被写入/读取，并且您有足够的可用内存并且缓存缓冲区足够大，那么就不需要 in-RAM FS（因为它可能会比缓存慢）。如果您不按顺序读取文件并且它们往往会从缓存中被逐出，那么使用专用线程实现预取策略可能有助于加快读取速度。此外，在这种情况下，映射文件和异步低级 API 也可能有助于更有效地实现这一点。
请注意，将许多小文件压缩到一个大文件中可以显着提高性能，因为它大大降低了 FS 子系统的开销（打开系统调用、关闭系统调用、递归目录获取在关键情况下会导致许多额外的 IOPS 等）。
【讨论】：
块引用 单个大读取比许多相同大小的小读取快还是慢？
它往往更高效，因为内存和磁盘之间的往返次数更少。然而，有一个收益递减点，可以使用像 iometer 或 fio 这样的工具（取决于您的操作系统 - 有很多这样的工具）来确定一个好的聚合大小，特别注意直接模式（它绕过OS FS 缓存）和回写或直写模式。考虑低延迟还是高吞吐量是最重要的，因为它们通常是相互矛盾的。
Can anyone recommend disk I/O benchmarking software for Windows?
对于您的特定设备，通常有一些带有评论的存储站点可以显示最大读/写速度，这可以提供有价值的性能目标。您正在使用的总线接口（例如 SATA 或 PCIe）也起着主要作用。
【讨论】：