写入的最佳缓冲区大小(2)答案

【问题标题】：Optimal buffer size for write(2)写入的最佳缓冲区大小(2)
【发布时间】：2012-02-06 21:05:34
【问题描述】：

假设我想使用write(2) syscall 将 1 GB 的数据写入文件，例如ext3 Linux 文件系统，这发生在非常繁忙的环境（许多类似的 I/奥斯同时）。间隔中的最佳缓冲区大小是多少，例如，[4 kB, 4 MB] 何时这样做

不使用O_DIRECT打开标志，或者
使用O_DIRECT?

请不要“自己检查”的答案——我想从“文件系统”的人那里得到一些答案。

【问题讨论】：

尝试对自己进行基准测试。我相信大小无关紧要，至少在[16kb, 1MB] 范围内......而且我认为它对大小不是很敏感......（真正的瓶颈是磁盘硬件）
您可以通过在文件上调用stat（例如stat(".")）来获取文件系统的块大小。我认为结果将是一个很好的缓冲区大小。
@BasileStarynkevitch：尝试读取几个字节而不是每次调用几千字节。读取大块时的性能提升是巨大的。但话又说回来，在你给的范围内你可能是对的。
是的，我给出的范围很重要。我确实知道 4kb 通常是文件系统上的页面大小和块大小。
如果您可以与块大小对齐并分配那么多，那么这将是一个不错的选择。不幸的是，对齐的内存分配有点偶然。 MSVC 为您提供了一个特定的功能 (_aligned_malloc)，还有另一个称为 memalign 的功能有时会实现。

标签： c++ c linux gcc filesystems

【解决方案1】：

根据我的经验，答案更多地取决于底层设备和硬件，而不是文件系统本身——即设备上的缓冲区缓存，以及设备写入小块的能力等——但是你应该永远不要以小于文件系统块大小的大小写入（stat(.) - 可能约为 4kb） - 同样，您不应真正超出 CPU 的 L2/L3 缓存大小，其中许多案例可以低至 512kb。

鉴于 SSD 设备和类似的设备喜欢将 64kb 作为操作单元，那么我建议 64kb-128kb 的缓冲区大小是最佳的 --这也符合我的经验，即吞吐量最高。

【讨论】：

【解决方案2】：

正如在 cmets 中所讨论的，我相信确切的大小并不重要，假设它是：

文件系统大小的小倍数（请参阅 Joachim Pileborg 建议 stat(".") 等的评论）
2 的幂（因为计算机和内核与它们类似）
不要太大（例如适合处理器内部的某些缓存，例如 L2 缓存）
在内存中对齐（例如，使用 posix_memalign 对齐页面大小）。

因此，16kbytes 和几兆字节之间的 2 的幂应该是合适的。大部分时间都花在读取磁盘上。文件系统和磁盘基准在该范围内相当平坦。

4Kbytes 似乎通常是页面大小和磁盘块大小。

当然，您可以在使用mke2fs 制作文件系统时调整文件系统块大小。

我敢打赌，最佳性能确实取决于您的硬件（SSD、硬盘？）和您的系统（及其负载）。

【讨论】：

【解决方案3】：

包括 stdio.h 应该将 BUFSIZ 定义为系统的最佳大小。这绝不是保证，但如果您没有能力进行广泛的基准测试，那么使用它是正确的值，并且它是此类基准测试的良好起点。

【讨论】：

我相信<stdio.h> 中定义的BUFSIZ 与那里提供的FILE 抽象相关。原始海报谈论的是 Linux 上的 write(2) 系统调用，没有 FILE 抽象。我不明白为什么BUFSIZ 会与此相关。
AFAIK，BUFSIZ 是传递给 setvbuf 的缓冲区大小。 FILE 抽象旨在进行高效的 IO，通常在选择缓冲区大小时考虑到这一点。
同意，但是为什么setvbuf-ed 的大小要和write 的大小一样呢？
因为选择缓冲区大小是为了最大限度地提高缓冲效率。
出于二进制兼容性的原因，我认为BUFSIZ 变化不大。我猜BUFSIZ 已在十多年前被选中，用于与我们当前机器相比具有不同约束和优化的系统。