MongoDB突然降级答案

【问题标题】：MongoDB abrupt degradationMongoDB突然降级
【发布时间】：2022-10-02 03:15:57
【问题描述】：

我也在运行 MongoDB 4.2.9 版（4.2.1 中也有同样的问题）。

当我们在 MongoDB 上进行持续负载测试时，突然延迟开始飙升并且实例进入不良状态。这发生在大约 5k 读取 qps 和 50 次写入 qps（这些是通过主键查询获得的，因此访问模式肯定不是问题）。读取 qps 的活动数据集小于 1 gb。而Wired Tiger的缓存大小如果超过30gb。在MongoDB forum 上也提出了同样的问题，但还没有答案。

查看 PMM 仪表板，我可以看到在集群进入降级状态之前，分叉进程的数量出现了巨大的峰值。

一个。 MongoDB 何时以及如何分叉子进程？

湾。我们可以限制子进程创建率的数量吗？

C。有没有关于 MongoDB 进程管理的文档？

d。这个分叉是其他问题的原因还是副作用？

在我们的 MongoDB 配置中，我们设置了 processManagement.fork: true。

显然，根据this question，也无法限制子进程的数量。

标签： mongodb

【解决方案1】：

发生这种情况的原因可能有很多。我是根据我们的情况来回答这个问题的。但是答案的某些部分可用于检测其他问题。

摘要：由于linux libc库问题，oplog应用程序存在错误。 MongoDB 已经做了一些变通修复，但在我们使用的 MongoDB 版本中没有该修复。

这个错误有据可查here。您可以更新您的数据库版本以获得修复。

一个。 MongoDB 何时以及如何分叉子进程？

每个新连接最终都会创建一个新进程和新文件描述符。

我们可以限制子进程创建率的数量吗？

我们可以根据this 页面上的建议限制net.maxIncomingConnections

C。有没有关于 MongoDB 进程管理的文档？

this

d。这个分叉是其他问题的原因还是副作用？

就我而言，这是 MongoDB 中 this 错误的副作用。由于 MongoDB 引擎中的一些错误（因为除了我的情况之外可能还有其他问题），一些查询没有返回。因此，对于新请求，应用程序创建了更多数量的连接，因此创建了更多数量的文件描述符。

【讨论】：