博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
一个cp命令引发的mongodb大量慢查询
阅读量:5856 次
发布时间:2019-06-19

本文共 869 字,大约阅读时间需要 2 分钟。

遇到问题:凌晨收到报警,某mongodb服务器cpu load超过8。由于没有影响到业务,第二天一早开始查原因。

查原因:

1. 先了解该服务器上的应用有哪些

    该db服务器主要应用只有mongodb。于是开始查询mongodb日志:

通过凌晨的日志mongodb.log查看,有大量的慢查询,但实际上这些表都非常小,只有几百行数据,而且表还有索引,却仅仅一个查询花了60~80s,慢查询之后的日志显示该节点不被其他节点检测到(mongodb复制集形式)。

由于一个小表的查询都需要判断70s左右,而且mongodb部署的是复制集形式(其他的查询节点都是正常的)可以判断,可能是这台db的性能方面影响了mongodb,而非mongodb本身的性能影响。

2. 于是查看凌晨有什么任务再跑。

crontab -l 发现确实凌晨有一个任务。是一个切割日志的脚本。大概就是把日志cp到另一个目录,然后将当前日志清空,继续记录新的一天的日志。

但这个日志平时都较小,也运行了很长时间.只能试一试的看看日志目录

看到日志突然就这么大了。难道是因为晚上cp 文件的时候导致了?

差不多判断问题出现在 cp导致了io负载过高,进而导致了cpu load 过高。

3. 复现问题

由于该操作在夜间操作,未影响线上业务。故手动操作cp,复现问题。

cp 了一个近3g的文件, 如下图:看到产生的I/O请求太多,I/O系统已经满负荷,该磁盘可能存在瓶颈。

跟着cpu load也 上升到10 (每一分钟的cpu load 值)左右。

解决问题:

将较大的日志从mongodb服务器分离出。

将小日子日志脚本切割改为系统logrotate切割。logrotate会在系统空闲的状态进行操作。

可是为什么拷贝了一个3g的文件,就会导致cpu load 高达10. 进而导致mongodb查询性能直线下降。

于是我们联系了某云,一个普通云盘的性能怎会如此低!

以上查问题的思路,最开始也没有很顺利。起初文件较小并没有猜测到是日志拷贝。查问题的时候不能以惯性思维排除。

转载地址:http://fhajx.baihongyu.com/

你可能感兴趣的文章
白帽子技术分析会话劫持实战讲解
查看>>
我的友情链接
查看>>
yum的三种方式
查看>>
Redis分布式缓存安装和使用
查看>>
20天精通 Windows 8:系列课程资料集
查看>>
html5 <figure> 标签
查看>>
开源监控软件 Hyperic 的两种插件
查看>>
TOMCAT
查看>>
Spark学习记录(二)Spark集群搭建
查看>>
短信猫JAVA二次开发包SMSLib,org.smslib.TimeoutException: No response from device解决方案...
查看>>
CloudStack 4.4学习总结之cloudstack-management安装
查看>>
VTSS Error code
查看>>
360提供的Php防注入代码
查看>>
windows phone (12) 小试自定义样式
查看>>
Linux后台启动脚本
查看>>
jna dll c
查看>>
CentOS 升级现有PHP版本
查看>>
(一) pyhon 基础语法(数值 字符串 元组 列表 字典)
查看>>
HDOJ 1003:求一串数字中和最大的连续子串
查看>>
RedHat 5.6_x86_64 + ASM + RAW+ Oracle 10g RAC (二)
查看>>