MongoDB、NUMA 硬件、页面错误但有足够的 RAM 用于工作集、touch 命令或 vmtouch/dd 未加载到内存中

Question

MongoDB 2.46 & 2.4.8

用例:

1. 在具有 2 个索引的集合中加载 100.000 个文档。驻留内存增加(mongostat)，没有发生页面错误。
2. 重启mongod。驻留内存不足(这是预期的)
3. 尝试使用 touch 命令 db.runCommand({ touch: collection, data: true, index: true }) 或其他方式(在操作系统上，vmtouch/dd)
   a) 在此步骤中，在我的开发机器 (MacOS) 上，我在 mongostat 中看到许多页面错误试图加热它(预期)并提高常驻内存。从那时起，任何更新都不会引发页面错误
   b) 在 numa 服务器(256 GB RAM)上，即使我按照以下指南启动了 mongo:http://docs.mongodb.org/manual/administration/production-notes/#mongodb-on-numa-hardware (注意:我没有 super 用户访问权限。但是，第二步，在/proc/sys/vm/zone_reclaim_mode 中回显 0，已经是 0，所以我就这样离开了)，我似乎无法预热使用“触摸”命令内存。没有任何反应，即使它成功返回。 在mongostat中，只有'mapped'和'vsize'越来越高，常驻内存也一样(35m)。我什至尝试使用 vmtouch 和 dd 命令加载操作系统内存中的数据文件。 只有重新索引集合才会改变常驻内存。

问题是在我开始将数据加载到服务器后不久出现的。我做了很多更新插入，一开始的表现非常棒(3000 - 4000 更新插入/秒)。这是预料之中的，因为工作集将能够适合内存。在 30.000.000 个文件之后，该过程似乎出现了很多页面错误，我不知道为什么。 数据文件约为。 33GB，性能约为 500 upserts/sec，有很多页面错误。那应该意味着工作集不在内存中。但是，256GB RAM 应该绰绰有余。我尝试了“touch”命令，但驻留内存很低(我什至重新启动了 mongod 进程，运行了 touch 命令，即使“mapped”和“vsize”飙升到很多 GB，驻留内存仍然很低，35m) .我尝试重新索引集合，瞧瞧，驻留内存从 35m -> 20GB。但是，我又一次看到了页面错误。然后我尝试 vmtouch 数据文件(或使用 dd)。同样，很多页面错误。

问题是我不能“只有”500 upserts/sec。我应该更改我的应用程序逻辑吗？我认为使用 256GB 内存我的“事件”工作集(预计 60GB)应该适合内存。我在中间(30GB)，似乎我无法做任何事情来解决这个问题。是numa硬件吗？我应该进行任何其他更改吗？

提前致谢

Answer 1

我刚刚写了一个pretty detailed answer关于驻留内存、页面错误以及如何进行故障排除、调整和调整等的 ServerFault，所以我不会在这里重新散列。

我会说 Sammaye 的评论是正确的，touch(或 dd、vmtouch 等)命令不会导致内存被再次报告为常驻 mongod 进程，直到进程实际访问数据(在那之前它只是在 FS 缓存中)，然后你可以在 SERVER-9415 中解决这个问题。这可能导致常驻内存报告不足。

我认为您已经在查看此处的关键指标，并且您应该能够实现比报告更高的驻留内存(或者至少，将更多数据放入内存而不会出现明显的页面错误)。您所描述的情况听起来像是来自其他地方的内存压力，但我假设您会注意到另一个进程占用了大量内存。

我要指出的是，我之前曾花费数天(字面意思)尝试使特定 AWS 实例超过 30% 的内存阈值，但没有成功。

当我们最终放弃并尝试另一个实例时，没有改变任何东西(我们只是添加了一个新实例作为辅助实例并故障转移到它)它立即占用了超过 70% 的常驻内存。当然，那是在 m2.4xlarge 实例上进行的，因此与您的实例规模不同，但始终值得牢记。如果您可以在另一个实例上尝试，我建议您试一试。