Mongodb 4.2.8：无法将会话添加到缓存中，因为活动会话数太高

Question

在连接 Mongo 的过程中，我们突然开始遇到以下问题：

{u'code': 261, u'ok': 0.0, u'$clusterTime': {u'clusterTime': Timestamp(1614532995, 3141), u'signature': {u'keyId': 0L, u'hash': Binary('\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00', 0)}}, u'codeName': u'TooManyLogicalSessions', u'operationTime': Timestamp(1614532995, 3141), u'errmsg': u'Unable to add session into the cache because the number of active sessions is too high'}

.

我们使用的任何连接驱动程序都会发生这种情况：

• 蒙古壳
• pymongo 3.6
• pymongo 3.11

并不是每个查询都会发生，但大约占所有查询的 30-40%。

与此同时，

maxSession

具有默认值（1000000），我从数据库状态中获得以下数据：

"logicalSessionRecordCache" : {
        "activeSessionsCount" : 2244,
        "sessionsCollectionJobCount" : 48430,
        "lastSessionsCollectionJobDurationMillis" : 0,
        "lastSessionsCollectionJobTimestamp" : ISODate("2021-02-28T16:56:03.438Z"),
        "lastSessionsCollectionJobEntriesRefreshed" : 0,
        "lastSessionsCollectionJobEntriesEnded" : 0,
        "lastSessionsCollectionJobCursorsClosed" : 0,
        "transactionReaperJobCount" : 49566,
        "lastTransactionReaperJobDurationMillis" : 1,
        "lastTransactionReaperJobTimestamp" : ISODate("2021-02-28T17:03:17.631Z"),
        "lastTransactionReaperJobEntriesCleanedUp" : 0,
        "sessionCatalogSize" : 33
    },

发现问题后，我定期检查

config.system.sessions

中的多个会话。它从11k到560k不等（大部分时间在80k到350k之间），这似乎很高。 然而，问题仍然无视会话数量。

一个错误是突然的，我们有和以前一样的负载（我不知道我们以前有多少会话，但我们没有添加任何新客户端 - 我们有大约 3k 连接。

没有分片，只有副本（一主一副）。

我真的很感激任何关于如何克服这个问题的建议。

UPD：另一件对我来说很奇怪的事情：

> db.system.sessions.count()
416068
> db.currentOp(true).inprog.length
2911

怎么可能有这样的差别？

Answer 1

您很可能需要在应用程序中进行一些调试以找出泄漏会话的位置。

0. 将驱动程序和服务器更新到最新版本。

1. 确定您的应用程序在哪里使用显式会话。显式会话是您通过 start_session 调用启动的会话。驱动程序自己也会自动使用会话，这些被称为隐式会话。

2. 缺乏相反的证据，你有一个会话泄漏。使用 https://docs.mongodb.com/manual/reference/command/killAllSessions/ 销毁所有会话，然后绘制随时间变化的活动会话数以查看趋势。

3. 检查您的代码并将每个 start_session 调用与该会话的结束方式（如果有）相匹配。如果您不使用像 https://docs.mongodb.com/ruby-driver/master/tutorials/ruby-driver-sessions/#creating-a-session-from-a-mongo-client 这样的作用域 API，您需要仔细考虑每个会话将在哪里被销毁。

4. 检查您的代码是否没有超时游标。那些可能会持有会话引用（显式或隐式）。

根据您在问题中提供的信息，我猜您的会话状态检查没有正确完成，因此请再次检查并确保您正在寻找正确的东西。

Answer 2

我们解决了这个问题。就我而言，有一些步骤：

1. 更新所有分片到 5.0.16（至少）；
2. db.system.sessions.drop() 在主配置分片服务器中；
3. 删除 config.collections 中带有 {"_id": "config.system.sessions"} 的文档；
4. 然后，在缓存更新的下一次迭代中，版本 >5.0.16 的 MongoDB 将自动创建新集合“config.system.sessions”并对其进行分片。

就是这样。但是，我建议，仅在万不得已时才执行此步骤，因为 MongoDB 开发人员不建议手动更改配置数据库）

祝你好运！

MongoDB Jira 票