我们在三台裸机服务器（无虚拟化，无 docker/kubernetes）上运行一个小型 mongodb 副本集，使用 Debian 11 和 mongodb 5.0.6：
机器A：128GB RAM，1TB 磁盘，主机器B：128GB RAM，1TB 磁盘，次机器C：8GB RAM，20GB 磁盘，仲裁器
突然间，我们遇到了中断，应用程序日志中出现了“NotWritablePrimary”/“MongoNotPrimaryException”等错误 - 我们假设我们的连接字符串可以确保不会发生中断：
mongodb://machineA:27017,machineB:27017/?replicaSet=MyRepl&waitQueueMultiple=10&readPreference=primaryPreferred
事实证明，主 mongodb 实例被 Linux 内核杀死，因为它消耗了太多 RAM。副本集现在已运行 3 个月，没有任何问题。但突然间我看到 RAM 消耗如下：
突然间，mongodb 的 RAM 使用量大幅增加：
内核终止 mongod 进程后，SystemD 会将其重新启动，因为它以服务形式运行。但重新启动后，它会再次消耗最大数量的 RAM，直到再次死亡。
今天早上，这种现象突然停止了。我们没有对应用程序进行任何更改，所以现在的问题是：是什么在 mongodb 进程中消耗了这么多 RAM？
据我所知，WireTiger 引擎使用了约 50% 的可用 RAM，但这并不能解释机器总 RAM 的最大使用量。我还从 Percona mongodb_exporter 获得了一些指标，这些指标显示 RAM 由 mongodb 使用，而系统上没有其他进程：
有趣的是，SECONDARY 的内存使用量当时根本没有变化：
有人知道或暗示这里发生了什么吗？
答案1
我们发现我们的某个应用服务在某些情况下运行失常，这对我们来说有点难以发现。
当不断敲击 MongoDb 时，似乎内存使用率越来越高，而不是像我预期的那样使用更多的 CPU 资源。在某个时候，mongod 进程被 Linux 内核杀死。
当我们在应用程序中修复该问题后，这种情况就消失了。