我正在调查我的 mongo 设置中的一些性能问题。我有 3 个查询控制器和 6 个分片。我正在执行大批量导入/更新，在 3 个查询控制器上，我每秒收到大约 200 个查询。但是，在调查分片时，我看到了大量故障，例如每秒 50 个。当我在分片服务器上运行 top 时，我发现它们只使用了大约 8% 的内存。这对我来说意味着 mongo 没有在分片服务器上配置为使用所有可用内存。我错了吗？感谢您的任何建议。
答案1
我有 3 个查询控制器和 6 个分片。
我猜你的意思是三台mongos机器，也就是“路由器”？我从未听说过 MongoDB 中“查询控制器”这个术语。它不够标准，足以让问题令人困惑。
我正在进行大批量导入/更新，在 3 个查询控制器上，每秒大约有 200 个查询。
好的，每秒大约有 600 个查询进入您的分片环境。
但是，在调查分片时，我发现了大量故障，比如每秒 50 次。当我在分片服务器上运行 top 时，我发现它们只使用了大约 8% 的内存。这对我来说意味着分片服务器上的 mongo 没有配置为使用所有可用内存。我错了吗？谢谢您的任何建议。
我假设您是top在主机操作系统上使用，而不是mongotop针对正在运行的分片成员。我的感觉是，您将需要研究 MongoDB 的内存映射特性。这是一个很大的话题，值得花一个周末的时间阅读，但以下是 Cliff 的注释：
- MongoDB 使用主机操作系统内存管理在 RAM 中缓存数据库文件。
- 仅仅因为 MongoDB 进程占用了 X 数量的 RAM 并不意味着它没有有效地使用 Y 数量。
- 在 Linux 中，查看缓存的内存，其中大部分很可能是 MongoDB 在 中“发生故障”的地方
mongostat。 发生故障mongostat并不意味着磁盘发生硬故障，而是意味着进程mongod正在使用的工作集之外的故障。 不过，它仍然可能会影响 RAM 中的文件，并且速度几乎与内存实际上被 所拥有一样快mongod。 - 如果要确定 MongoDB 是否内存不足，则需要查看主机的硬故障编号。如果发生硬故障并访问磁盘以获取数据，则只有此时 MongoDB 内存不足。对我来说，不清楚您所说的故障是
mongostat故障、操作系统软故障还是操作系统硬故障。 - MongoDB 使用 MongoDB 想要使用的内存。除了使用之外，没有太多可以优化的方法触碰在预热脚本中，通过强力将数据拉入内存，而不是让其
mongod在应用程序的常规查询负载的生命周期内有机地加载工作集。但是，这样做的理由很少，除非在降压后快速让内存在新的主节点上升温，或者为新的mongodPID 快速升温内存（例如，可能是由于重新启动）。 - 嘿孩子们！MongoDB 内存故障排除很难！让我们去阅读它！ᕕ(ᐛ)ᕗ
在我看来，除了硬故障之外，您没有描述 MongoDB 的任何异常情况。相mongod对于主机上可用的 RAM，本身可能只占用很少的 RAM，但操作系统的缓存将充满 MongoDB 引用的内存映射文件。我最近正在排除故障的一个 MongoDB 实例有 144GB 的 RAM，而使用的内存mongod不到 10%，但主机 Linux 操作系统有超过一百 GB 的 RAM 被列为缓存内存，并且没有磁盘故障。即 MongoDB 很开心。
如果这是操作系统中的硬故障，并且操作系统的交换正在被使用……那将会很奇怪，并且是一个操作系统级别的调整问题。