故障案例--mongo 3.0鉴权导致cpu居高不下
来源:互联网 发布:2017 a号黑豹数据 编辑:程序博客网 时间:2024/05/18 02:20
故障现象
CPU奇高,达到接近物理机核数上限;
错误日志中的业务SQL执行较快,SQL不存在问题;
错误日志大量的刷屏以下信息
原因分析
从错误日志看,绝大部分情况都处于saslStart,查看资料发现这是mongo 3.0的鉴权机制正是SCRAM-SHA-1,于是怀疑是这个鉴权机制导致了CPU飙升;
通过了解,业务采用的是短连接,进一步确定原因应该是短时间大量的连接过来触发的鉴权操作导致了大量CPU计算;
进一步用perf工具查看,整台物理机的资源很大程度都被以下函数占用,猜测这些函数涉及到很多计算,查看代码发现绝大部分函数都在文件src/mongo/crypto/tom/sha1.c ,这是实现加密的代码,涉及到复杂的哈希计算,关于这个SCRAM-SHA-1的介绍,可以参考官方文档https://docs.mongodb.com/v3.0/core/security-scram-sha-1/#authentication-scram-sha-1
解决方法
短时间的方案
1 弃用鉴权2 或许换一种鉴权方式也行,其他鉴权方式或许不涉及这么多的计算工作(不确定)
当时紧急做了弃用用户鉴权的处理,CPU立马得到下降,大概控制在5个核以内(之前32核全占满)
值得一提的是,去掉鉴权后(我这就是整个集群去掉keyfile认证),如果不改连接uri,实际上这时虽然也能登陆,因为账户和密码是正确的,但这时应该还是有鉴权的,错误日志依旧会打印这些认证信息,所以还需要修改下连接URI,将用户名和密码值为空。
长期的方案
弃用短连接的方式,改用连接池
阅读全文
0 0
- 故障案例--mongo 3.0鉴权导致cpu居高不下
- 故障案例--mongo备份文件损坏,导致mongorestore中断
- Glide 加载Gif 导致cpu居高不下的解决办法
- 故障案例,mongo副本集主节频繁切换
- CPU居高不下原因之一
- linux cpu居高不下 调试
- 循环使用正则导致进程挂起和CPU使用率达到100%居高不下测试Demo
- 断电故障导致ASM DiskGroup 故障及恢复案例
- 断电故障导致 ASM DiskGroup 故障及恢复案例
- 生产环境上线程序导致服务故障案例解析
- 故障案例:一个子查询导致服务崩溃
- oracle数据库cpu占用居高不下的解决办法
- JAXB的使用陷阱,CPU居高不下
- .net runtime optimization services cpu居高不下
- 数据库cpu使用率居高不下的解决方案
- Mysql的cpu占用居高不下的解决办法
- oracle数据库操作系统CPU利用率居高不下
- 故障案例--mongo shell从库无法读的处理方法
- [easy]566. Reshape the Matrix
- [World Final 2017 E] Need For Speed (二分)
- 数据结构实验之图论六:村村通公路
- 部分和问题
- 面试热题——进制转换(n进制转换成2进制)
- 故障案例--mongo 3.0鉴权导致cpu居高不下
- nyoj 487点数(向量积判断三角形内部的整点)
- 如何查看codeblock的头文件
- HTML基础[思维导图]
- [线段树 点更新 段查询]A
- hdoj1074 Doing Homework (状态压缩 DP)
- 互信息(Mutual Information)和χ 2特征选择方法去噪处理
- laravel学习
- 权限修饰符、状态修饰符、抽象修饰符使用规则