linux - linux下运行MongoDB需要调sysctl.conf吗？

Question

我们在 MongoDB 日志中看到偶发性大量写入磁盘，有效地长时间锁定 MongoDB。网上很多人都在反射(reflect)类似的问题，但我至今没有找到好的答案。

 Tue Mar 11 09:42:49.818 [DataFileSync] flushing mmaps took 75264ms  for 46 files

根据 mongo 统计数据，我服务器上的平均 mmap 刷新时间约为 100 毫秒。

我们的大部分 MongDB 数据都会在几个小时内更新。这让我推测我们是否需要调整 Linux sysctl 虚拟内存参数，如 Neo4J 性能指南中所述，这是另一个内存映射工具:http://docs.neo4j.org/chunked/stable/linux-performance-guide.html

There are a lot of blocks going out to IO, way more than expected for the write speed we are seeing in the benchmark. Another observation that can be made is that the Linux kernel has spawned a process called "flush-x:x" (run top) that seems to be consuming a lot of resources.

The problem here is that the Linux kernel is trying to be smart and write out dirty pages from the virtual memory. As the benchmark will memory map a 1GB file and do random writes it is likely that this will result in 1/4 of the memory pages available on the system to be marked as dirty. The Neo4j kernel is not sending any system calls to the Linux kernel to write out these pages to disk however the Linux kernel decided to start doing so and it is a very bad decision. The result is that instead of doing sequential like writes down to disk (the logical log file) we are now doing random writes writing regions of the memory mapped file to disk.

TOP 显示我们确实有一个运行了很长时间的刷新进程，所以这似乎是匹配的。

      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
    28352 mongod    20   0  153g 3.2g 3.1g S  3.3 42.3 299:18.36 mongod
     3678 root      20   0     0    0    0 S  0.3  0.0  26:27.88 flush-253:1

推荐的 Neo4J sysctl 设置是

    vm.dirty_background_ratio = 50
    vm.dirty_ratio = 80

这些设置与 MongoDB 安装有任何关系吗？

Answer 1

简短的回答是"is"。选择什么值在很大程度上取决于您的写入模式。 This提供有关 MongoDB 如何管理其映射的确切背景 - 这并不意外。

一个问题是，在面向 Web 的数据库应用程序中，您可能更关心延迟而不是吞吐量。 vm.dirty_background_ratio 给出了开始写脏页的阈值，而 vm.dirty_ratio 告诉何时停止接受新的写入(即阻塞)，直到所有写入都被刷新。

如果您正在锤击一个相对较小的工作集，您可以将这两个值都设置得相当高，并依靠 Mongo(或操作系统)的周期性基于时间的刷新到磁盘来提交写入。

如果您正在进行大量插入和一些修改，这听起来可能是您的情况，这是一种取决于插入与重写的平衡行为 - 过早开始刷新将导致写入很快重写，“浪费”io。开始刷新太晚会导致在刷新大量写入时出现暂停。

如果您主要执行插入操作，那么您很可能需要较大的 dirty_ratio(以避免阻塞)和相对较小的 dirty_background_ratio(小到足以在插入时始终写入以减少延迟，并且刚好足够大线性化一些写入)。

正确的解决方案是使用这些 sysctl 参数的各种选项重放一些虚拟数据，并通过强力优化它，同时牢记您的平均延迟/总吞吐量目标。