一个cp命令引起的mongodb大量慢查询

遇到问题：凌晨收到报警，某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查询性能直线降低。

因而咱们联系了某云，一个普通云盘的性能怎会如此低！

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