需要快速文件访问选项答案

【问题标题】：Fast file access options needed需要快速文件访问选项
【发布时间】：2010-02-28 07:08:39
【问题描述】：

我希望我的代码能够非常快速地处理文件。此文件大小从 1 KB 到 2 GB 不等。

即使我已经准备好为该单个文件创建一个单独的文件系统。

我会将文件拆分为固定大小的块（可能是 8KB）并访问它以进行数据读取和写入。代码方面，算法不能改变，因为它提供了良好的性能和稳定的性能。所以我不想改变。我还使用 mmap() 按需将块映射到内存。

是否可以将文件系统作为一个单独的块，以便文件访问、读写操作可以更快？

请提出你所有的建议，哪怕是一件对我有帮助的小事。

建议可以跨平台和文件系统。

谢谢，娜迦

【问题讨论】：

【解决方案1】：

通用，独立于操作系统的通用规则：

使用物理读取（而不是流）
使用大型 I/O 缓冲区进行读取。 I/O 操作的初始化（以及与旋转硬件的同步）的时间成本很高。几个小的读取比一个大的读取花费更长的时间。
创建一些基准来确定最有效的缓冲区大小。给定大小后，效率不会提高，您不想不必要地吞噬所有宝贵的 RAM。最佳缓冲区大小取决于您的硬件和操作系统。在当前硬件上，使用 500KB 到 1MB 范围内的缓冲区大小通常就足够了。
最小化磁盘磁头寻道。 IE。如果您必须将数据写回，如果它们是在同一个物理磁盘上，则读/写交替可能会非常昂贵。
如果你有一些重要的处理要做，使用双缓冲和异步 IO 来重叠 IO 和处理。

【讨论】：

【解决方案2】：

mmap 或MapViewOfFile 让您可以直接访问内存中的文件。操作系统将根据需要透明地在页面中出错，甚至可能提前读取（可以用madvise 或FILE_FLAG_* 暗示）。根据您的访问模式和文件大小，这可能比正常读取/写入文件要快得多。

不利的一面是，您将不得不更多地担心一致性（确保使用 msync 或 FlushViewOfFile 时要小心），并且由于需要进行分页表操作，它也可能会更慢。

【讨论】：

我知道 mmap() 将是更好的选择，我正在使用它。现在我将文件划分为 8k 块。块大小有什么硬性规定吗？示例：如果我访问一个特定的块，它将在单页错误中加载。
当今大多数常见平台上的块大小为 4kB 或 8kB，尽管linux-mm.org/HugePages Linux 允许您使用mmap(...MAP_HUGETLB...)，这可能会给您 2MB 或 4MB 页面；这样，页面错误就会减少，但每个页面错误都需要更长的时间才能满足。并且不要认为操作系统只按需映射页面然后将它们留在周围：它可能会提前读取并抢先映射更多页面，或者它可能会丢弃它需要/想要驱逐的页面。在您自己的系统上进行自己的实验，结果会因许多因素而异。

【解决方案3】：

Windows 允许您为原始读取和写入打开一个分区。它还可以让您为原始 IO 打开物理设备。因此，如果您愿意将硬盘或分区视为单个文件，则可以保证“文件”在磁盘上逻辑上是连续的。（由于硬盘修复坏扇区的方式，它实际上可能物理不连续。

如果您选择进行原始 io，那么您将不得不以设备块大小的倍数进行读写。这通常是 512 字节，但使用 4k 作为块大小可能更明智，因为这是较新的磁盘正在使用的，这就是 Win32 的页面大小。

要为原始读取打开分区，请使用 CreateFile 和文件名“\.\X:”，其中 X: 是分区的驱动器号。请参阅标题物理磁盘和卷

下的 CreateFile 文档

另一方面，很难超越内存映射文件的性能，请参阅此问题以获取示例 How to scan through really huge files on disk?

【讨论】：

【解决方案4】：

始终尝试按 64kB-1MB 的块顺序访问您的文件。这样您就可以利用预取并最大化每个 I/O 操作的数据量。

另外，首先尝试确保文件是连续的，这样磁盘磁头就不必在连续读取之间移动很多。如果您从设置文件结尾或一次对整个文件执行write() 开始，许多文件系统将创建一个尽可能连续的文件。在 Windows 上，您可以使用 sysinternals.com 实用程序 contig.exe 使文件连续。

【讨论】：