随机访问 C++ 和 Python 时 Linux 内存映射文件性能不佳

在尝试使用内存映射文件创建多 GB 文件（大约 13 GB）时，我遇到了 mmap() 的问题。最初的实现是在 Windows 上使用 boost::iostreams::mapped_file_sink 在 c++ 中完成的，一切顺利。然后代码在 Linux 上运行，在 Windows 上花费几分钟的时间在 Linux 上则变成了几个小时。

这两台机器是相同硬件的克隆：Dell R510 2.4GHz 8M 高速缓存 16GB RAM 1TB 磁盘 PERC H200 控制器。

Linux 是 Oracle Enterprise Linux 6.5，使用 3.8 内核和 g++ 4.83。

有人担心 boost 库可能存在问题，因此使用 boost::interprocess::file_mapping 和本机 mmap() 完成了实现。所有三个人都表现出相同的行为。当 Linux 性能严重下降时，Windows 和 Linux 性能在一定程度上相当。

完整的源代码和性能数据链接如下。

// C++ code using boost::iostreams
void IostreamsMapping(size_t rowCount)
{
   std::string outputFileName = "IoStreamsMapping.out";
   boost::iostreams::mapped_file_params params(outputFileName);
   params.new_file_size = static_cast<boost::iostreams::stream_offset>(sizeof(uint64_t) * rowCount);
   boost::iostreams::mapped_file_sink fileSink(params); // NOTE: using this form of the constructor will take care of creating and sizing the file.
   uint64_t* dest = reinterpret_cast<uint64_t*>(fileSink.data());
   DoMapping(dest, rowCount);
}

void DoMapping(uint64_t* dest, size_t rowCount)
{
   inputStream->seekg(0, std::ios::beg);
   uint32_t index, value;
   for (size_t i = 0; i<rowCount; ++i)
   {
      inputStream->read(reinterpret_cast<char*>(&index), static_cast<std::streamsize>(sizeof(uint32_t)));
      inputStream->read(reinterpret_cast<char*>(&value), static_cast<std::streamsize>(sizeof(uint32_t)));
      dest[index] = value;
   }
}

最后一个测试是用 Python 完成的，以便用另一种语言重现这一点。掉落发生在同一个地方，所以看起来是同样的问题。

# Python code using numpy
import numpy as np
fpr = np.memmap(inputFile, dtype='uint32', mode='r', shape=(count*2))
out = np.memmap(outputFile, dtype='uint64', mode='w+', shape=(count))
print("writing output")
out[fpr[::2]]=fpr[::2]

对于 C++ 测试，Windows 和 Linux 具有相似的性能，最多可达 3 亿个 int64（Linux 看起来稍快一些）。对于 C++ 和 Python，Linux 上的性能似乎下降了大约 3Gb（每个 int64 4 亿 * 8 字节 = 3.2Gb）。

我知道在 32 位 Linux 上 3Gb 是一个神奇的边界，但我不知道 64 位 Linux 上有类似的行为。

结果的要点是，在 4 亿个 int64 下，Windows 上的时间为 1.4 分钟，Linux 上的时间为 1.7 小时。我实际上正在尝试映射近 13 亿个 int64。

谁能解释一下为什么 Windows 和 Linux 之间的性能差距如此之大？

任何帮助或建议将不胜感激！

负载测试.cpp http://pastie.org/9645329

Makefile http://pastie.org/9645338

负载测试.vcxproj http://pastie.org/9645344

更新了 mmap_test.py http://pastie.org/9649752

原始mmap_test.py http://pastie.org/9645348

更新结果 http://goo.gl/Xqhngt更新了 Python 代码...Python 速度现在可与 C++ 相媲美

原始结果 http://goo.gl/n8QMff注意：Python 结果已过时

编辑：升级为“正确答案”。问题出在 Linux 处理“脏页”的方式上。我仍然希望我的系统时不时地刷新脏页，所以我不允许它有太多未完成的页面。但与此同时，我可以证明这就是正在发生的事情。

我这样做了（使用“sudo -i”）：

# echo 80 > /proc/sys/vm/dirty_ratio
# echo 60 > /proc/sys/vm/dirty_background_ratio

这给出了这些设置 VM 脏设置：

grep ^ /proc/sys/vm/dirty*
/proc/sys/vm/dirty_background_bytes:0
/proc/sys/vm/dirty_background_ratio:60
/proc/sys/vm/dirty_bytes:0
/proc/sys/vm/dirty_expire_centisecs:3000
/proc/sys/vm/dirty_ratio:80
/proc/sys/vm/dirty_writeback_centisecs:500

这使得我的基准测试运行如下：

$ ./a.out m64 200000000
Setup Duration 33.1042 seconds
Linux: mmap64
size=1525 MB
Mapping Duration 30.6785 seconds
Overall Duration 91.7038 seconds

与“之前”比较：

$ ./a.out m64 200000000
Setup Duration 33.7436 seconds
Linux: mmap64
size=1525
Mapping Duration 1467.49 seconds
Overall Duration 1501.89 seconds

其中有这些虚拟机脏设置：

grep ^ /proc/sys/vm/dirty*
/proc/sys/vm/dirty_background_bytes:0
/proc/sys/vm/dirty_background_ratio:10
/proc/sys/vm/dirty_bytes:0
/proc/sys/vm/dirty_expire_centisecs:3000
/proc/sys/vm/dirty_ratio:20
/proc/sys/vm/dirty_writeback_centisecs:500

我不确定应该使用什么设置来获得理想的性能，同时仍然不会将所有脏页永远留在内存中（这意味着如果系统崩溃，则需要更长的时间才能写入磁盘）。

对于历史：这是我最初写的“非答案” - 这里的一些评论仍然适用......

不是真正的答案，但我发现相当有趣的是，如果我将代码更改为首先读取整个数组，然后将其写出，那么它比在同一个循环中执行这两个操作要快得多。我明白，如果您需要处理非常大的数据集（大于内存），那么这是完全没有用的。使用发布的原始代码，100M uint64 值的时间为 134 秒。当我分割读和写周期时，它是 43 秒。

这是DoMapping修改后的功能[仅我更改的代码]：

struct VI
{
    uint32_t value;
    uint32_t index;
};


void DoMapping(uint64_t* dest, size_t rowCount)
{
   inputStream->seekg(0, std::ios::beg);
   std::chrono::system_clock::time_point startTime = std::chrono::system_clock::now();
   uint32_t index, value;
   std::vector<VI> data;
   for(size_t i = 0; i < rowCount; i++)
   {
       inputStream->read(reinterpret_cast<char*>(&index), static_cast<std::streamsize>(sizeof(uint32_t)));
       inputStream->read(reinterpret_cast<char*>(&value), static_cast<std::streamsize>(sizeof(uint32_t)));
       VI d = {index, value};
       data.push_back(d);
   }
   for (size_t i = 0; i<rowCount; ++i)
   {
       value = data[i].value;
       index = data[i].index;
       dest[index] = value;
   }
   std::chrono::duration<double> mappingTime = std::chrono::system_clock::now() - startTime;
   std::cout << "Mapping Duration " << mappingTime.count() << " seconds" << std::endl;
   inputStream.reset();
}

我目前正在运行一个包含 200M 记录的测试，这在我的机器上需要大量时间（在没有代码更改的情况下需要 2000 多秒）。很明显，所花费的时间来自磁盘 I/O，并且我看到 IO 速率为 50-70MB/s，这非常好，因为我并不真正期望我相当简单的设置能够提供太多比那更多的。对于较大的尺寸，改进并不那么好，但仍然是一个不错的改进：总时间为 1502 秒，而“在同一循环中读写”则为 2021 秒。

另外，我想指出，对于任何系统来说，这都是一个相当糟糕的测试 - Linux 明显比 Windows 差的事实不是重点 - 你并不真的想映射一个大文件并写入 8 个字节 [意思是4KB 页必须随机读入] 每个页。如果这反映了您真实的应用程序，那么您应该认真地以某种方式重新考虑您的方法。当您有足够的可用内存以使整个内存映射区域适合 RAM 时，它将运行良好。

我的系统中有足够的 RAM，所以我相信问题是 Linux 不喜欢太多“脏”的映射页面。

我感觉这可能与此有关：https://serverfault.com/questions/126413/limit-linux-background-flush-dirty-pages https://serverfault.com/questions/126413/limit-linux-background-flush-dirty-pages更多解释：http://www.westnet.com/~gsmith/content/linux-pdflush.htm http://www.westnet.com/~gsmith/content/linux-pdflush.htm

不幸的是，我也很累，需要睡觉。明天我会看看是否可以尝试这些 - 但不要屏住呼吸。就像我说的，这并不是一个真正的答案，而是一个不太适合评论的长评论（并且包含代码，在评论中阅读这完全是垃圾）