资讯专栏INFORMATION COLUMN

Mongodb日常性能问题处理案例分享

IT那活儿 / 2921人阅读
Mongodb日常性能问题处理案例分享
[
问题描述
]


某日午间,业务侧反馈mongodb数据库异常,业务侧报错信息如下:

11:33:09Closed connection [connectionId{localValue:1182, serverValue:2880879}] to 10.**.**.**:27017 because there was a socket exception raised by this connection.

并且该问题从10:45开始影响业务,业务侧异常情况突增:


[
问题分析处理
]


看到socketexception,立马想到前段时间出现的因为网络和连接风暴导致的连接延迟从而引起业务侧重启的问题,重启过程中就出现大量的socket异常报错。所以立即用shell脚本分析每秒连接和断开连接情况,但是并未出现会话异常断开。但从后台日志上可看到如下信息:

2020-10-30T10:30:03.324+0800 I ACCESS   [conn2875701] Successfully authenticated as principal ringbacktone on admin from client 10.25.148.159:24045

2020-10-30T10:30:04.520+0800 I COMMAND  [conn2875694] command ri***one_prod.D**bt command: find { find: "D***rbt", filter: { dataStatus: { $in: [ "9", "10", "11", "12" ] }, activityId: "PAC_***ECYDSHD" }, sort: { _id: 1 }, skip: 10700, limit: 1

00, $db: "rin***rod" } planSummary: IXSCAN { activityId: 1 } keysExamined:1626656 docsExamined:1626656 fromMultiPlanner:1 cursorExhausted:1 numYields:16621 nreturned:100 reslen:310338 locks:{ Global: { acquireCount: { r: 33244 } }, Database: { acqu

ireCount: { r: 16622 } }, Collection: { acquireCount: { r: 16622 } } } protocol:op_query 8827ms

2020-10-30T10:30:04.520+0800 I NETWORK  [conn2875694] Error sending response to client: SocketException: Broken pipe. Ending connection from 10.25.148.210:12170 (connection id: 2875694)


从上面的日志上可以看到日志在刷慢查询,并提示socket异常,分析慢查询,可知其已经是索引扫描,但是是skip……limit分页查询。将语句拿到备库执行,毫秒级出结果。而慢查询一般不会导致socket异常,在以往的运维工作中,十分钟以上的查询都未导致socket异常。


继续检查主机负载,发现主机CPU、内存耗尽,并出现少量内存换页


此时检查currentOp会话并发情况:


由上图可以看出,日志中出现的慢查询并发数高达912个。

至此,问题基本确认,大并发的分页查询导致数据库性能急剧下降,导致主机CPU、内存耗尽。通知业务侧检查,该语句是某活动的接口查询业务。业务侧停止此部分业务后,机器性能恢复,CPU下降到10%以内,但是主机内存并未释放。此时,数据库占用内存情况如下:


数据库使用虚拟内存56GB,物理内存近48GB,而我们的WT引擎的cache配置才20G,那么内存耗费在什么地方呢??继续检查db.serverStatus()输出结果进行分析,发现tcmalloc分配器缓存了大量的内存。


消耗的内存找到了,但是我们没法通过通过命令立即释放缓存,而通过其他方案强制回收内存也可能导致严重的性能问题,此时我们发现业务停了后,机器未再出现换页,所以不再对内存进行特别的处理,等mongodb逐渐释放内存。


[
总结
]


无论在什么数据库中,分页问题均是越到后面越慢,当出现大并发分页查询的时候,可能导致数据库性能急剧下降。在mongodb中,如果要使用到分页,建议不要使用skip……limit的方式分析,而采用seekmethod,即每次分页取出最后一条数据的某个值,然后再根据该值取limit的方式进行。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/130103.html

相关文章

  • Leaf in the Wild: Stratio整合Apache和MongoDB为世界上最大的银行

    摘要:以及大数据平台都已经进行了集成并且处于企业就绪状态。因此,顾客避免浪费时间在安装配置及监控系统方面。注意防止数据频繁移动。 本文源地址:http://www.mongoing.com/blog/post/leaf-in-the-wild-stratio-integrates-apache-spark-and-mongodb-to-unlock-new-customer-insights...

    BDEEFE 评论0 收藏0
  • 开源|性能优化利器:数据库审核平台Themis的选型与实践

    摘要:正是存在问题,促使我们考虑引入数据库审核平台。的确,与很多互联网公司相比,数据库数十套的估摸并不是太大但与互联网类公司不同,类似宜信这类金融类公司对数据库的依赖性更大,大量的应用是重数据库类的,且其使用复杂程度也远比互联网类的复杂。 作者:韩锋 出处:DBAplus社群分享 Themis开源地址:https://github.com/CreditEaseDBA 拓展阅读:宜信开源|数...

    wenhai.he 评论0 收藏0
  • 数据库收集 - 收藏集 - 掘金

    摘要:前言在使用加载数据数据库常见的优化操作后端掘金一索引将放第一位,不用说,这种优化方式我们一直都在悄悄使用,那便是主键索引。 Redis 内存压缩实战 - 后端 - 掘金在讨论Redis内存压缩的时候,我们需要了解一下几个Redis的相关知识。 压缩列表 ziplist Redis的ziplist是用一段连续的内存来存储列表数据的一个数据结构,它的结构示例如下图 zlbytes: 记录整...

    Little_XM 评论0 收藏0

发表评论

0条评论

IT那活儿

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<