谈到MongoDB“ cannot add session into the cache”异常不得不从一个MongoDB的BUG说起,即https://jira.mongodb.org/browse/SERVER-39044。最早遇到这个问题的时候是在19年的时候,当时MongoDB4.0产品刚上线样子,经常会遇到当实例的请求量累积达到一定数量后,实例不能执行新的查询,即报错“ cannot add session into the cache”。最开始我们认为是这个上述BUG导致,只能通过重启解决。这对于非常敏感的数据库业务是无法接受的,更致命的是这种触发条件随时都可能出现,所以迫使不少对MongoDB4.0新特性没有业务依赖的用户只能回退到MongoDB3.6。很久之后,我们发现MongoDB3.6 及以上版本的副本集去掉分片sharding.clusterRole配置项可以完美解决这个问题。
然后,最近遇到的MongoDB“ cannot add session into the cache”异常却不是sharding.clusterRole配置项参数引起的,而是由于MongoDB logicalSession打满导致。
推荐两篇logicalSession相关的文章:(1)叮咚买菜自建MongoDB上云实践、(2)mongo can not add session to cache问题排查和解决。
官网介绍:https://docs.mongodb.com/manual/reference/server-sessions/
从MongoDB-3.6版本开始,MongoDB开始逐步支持单文档事务,从而开始引入session逻辑会话模块。不论是副本集mongod还是分片集群的mongos,都会启动一个定时器刷新cache中缓存的session信息到config库的system.session表中。官方默认logicalSessionRefreshMillis刷新时间是5min。
(1)sessions会话信息统计方法
db.serverStatus().logicalSessionRecordCache { "activeSessionsCount" : 1000000, # logicalSession实时数量统计,最大100w "sessionsCollectionJobCount" : 1688, "lastSessionsCollectionJobDurationMillis" : 1344, "lastSessionsCollectionJobTimestamp" : ISODate("2022-01-15T14:07:38.978Z"), "lastSessionsCollectionJobEntriesRefreshed" : 0, "lastSessionsCollectionJobEntriesEnded" : 0, "lastSessionsCollectionJobCursorsClosed" : 0, "transactionReaperJobCount" : 0, "lastTransactionReaperJobDurationMillis" : 0, "lastTransactionReaperJobTimestamp" : ISODate("2022-01-17T11:02:38.976Z"), "lastTransactionReaperJobEntriesCleanedUp" : 0 }
(2)输出参数说明
统计类型 | 统计项 | 统计内容说明 |
Session统计 | activeSessionsCount | 当前活跃会话数 |
lastSessionsCollectionJobEntriesRefreshed | 上一个周期刷新到system.session表的活跃会话数 | / |
lastSessionsCollectionJobEntriesEnded | 上一个周期刷新到system.session表的endSessions会话数 | / |
lastSessionsCollectionJobCursorsClosed | 上一个周期内清理的 | / |
Transaction统计 | lastTransactionReaperJobEntriesCleanedUp | 本周期内清理的transactions表数据条数 |
问题汇总:
(1)logicalSession打满100w导致数据库查询异常,报错cannot add session into the cache
(2)logicalSession周期性(默认5min)刷新,导致业务IO抖动。
解决建议:
(1)针对 logicalSession打满的问题,数据库侧:建议可以调低 logicalSession周期性刷新时间,由默认logicalSessionRefreshMillis 5min调整为2min或者更短些,但不建议过短,物极必反;业务侧:建议优化掉不必要的短连接请求,或者必要时采用长连接。
(2)针对 logicalSession刷新带来的性能问题,数据库侧:建议可以使用分片集群,打散业务请求到不同数据分片上,避免单节点session堆积,定时刷新update config库的system.sessions表时,消耗大量IO,导致业务突刺抖动;业务侧:如果业务类型大多为长连接请求,建议适当调大logicalSessionRefreshMillis默认值,减少周期性刷新频率或者通过连接池控制logicalSession cache数量。
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/128138.html
摘要:但是对于锁来说,之后引入事务级别的锁不论对还是都是生效的。因此从版本开始引入了锁,来保护表的元数据信息,用于解决或者保证操作与操作之间的一致性。支持事务的引擎表和不支持事务的引擎表,都会出现等待现象。 本文由云+社区发表 一、 问题是这样来的 2018年某个周末,接到连续数据库的告警,告警信息如下: showImg(https://segmentfault.com/img/...
摘要:但是对于锁来说,之后引入事务级别的锁不论对还是都是生效的。因此从版本开始引入了锁,来保护表的元数据信息,用于解决或者保证操作与操作之间的一致性。支持事务的引擎表和不支持事务的引擎表,都会出现等待现象。 本文由云+社区发表 一、 问题是这样来的 2018年某个周末,接到连续数据库的告警,告警信息如下: showImg(https://segmentfault.com/img/...
摘要:而阿里云自研的秒级监控系统已经可以做到秒点的真秒级粒度,全量指标采集无一疏漏甚至对曾经没有出现过的指标进行自动采集,实时数据展示。最后,秒级监控已经在阿里云控制台开放,云的用户可以自主进行监控开启,体验秒级监控带来的高清体验。 在我们平时的数据库使用当中,监控系统,作为排查故障,告警故障的重要辅助系统,对dba、运维、业务开发同学进行问题诊断、排查、分析有着重要的作用。并且一个监控系统...
摘要:而阿里云自研的秒级监控系统已经可以做到秒点的真秒级粒度,全量指标采集无一疏漏甚至对曾经没有出现过的指标进行自动采集,实时数据展示。最后,秒级监控已经在阿里云控制台开放,云的用户可以自主进行监控开启,体验秒级监控带来的高清体验。 在我们平时的数据库使用当中,监控系统,作为排查故障,告警故障的重要辅助系统,对dba、运维、业务开发同学进行问题诊断、排查、分析有着重要的作用。并且一个监控系统...
摘要:而阿里云自研的秒级监控系统已经可以做到秒点的真秒级粒度,全量指标采集无一疏漏甚至对曾经没有出现过的指标进行自动采集,实时数据展示。最后,秒级监控已经在阿里云控制台开放,云的用户可以自主进行监控开启,体验秒级监控带来的高清体验。 在我们平时的数据库使用当中,监控系统,作为排查故障,告警故障的重要辅助系统,对dba、运维、业务开发同学进行问题诊断、排查、分析有着重要的作用。并且一个监控系统...
阅读 1246·2024-02-01 10:43
阅读 353·2024-01-31 14:58
阅读 416·2024-01-31 14:54
阅读 795·2024-01-29 17:11
阅读 2184·2024-01-25 14:55
阅读 1463·2023-06-02 13:36
阅读 2055·2023-05-23 10:26
阅读 457·2023-05-23 10:25