读取db服务器信息出错,一段mongodb服务器读取数据超时的故事

北京时间 2016年9月25日  22:58:30 PM

近期线上生产环境mongodb的总是发现读取数据超时的问题，今天下午坐下来细细的研究了一番，大致过程如下：

业务背景

线上有一对mongodb主从的服务器，只是简单做了mongodb的主从，master - slave。

开始以为做了主从就能确保数据不丢的问题了，确实，数据没有发生丢失的问题，但是近期发现好多用户在点击某些操作要读取mongo里面的数据内容的时候，要等待很长的时间，这样的等待是叫人无法忍受的。

最开始的时候，以为做了主从，然后在Tomcat的mong配置文件中设置好读写分离的步骤就能做到读写分离了，可是不然，并没有想象的那么好，实际的结果是不管读还是写都被无情的把任务分发到了主的上面，这样一来主的压力就恨到了，导致了用户读取数据的时候，需要花费很长的时间来进行等待，沿着这个问题，我们就有了下文

问题排查：

问题排查之：网卡流量君

先使用sar命令查看了服务器的网卡流量信息，发现正常：

sar -n DEV 1  #1秒钟刷新一次网卡流量信息

23时05分26秒 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s

23时05分27秒 lo0.00 0.00 0.00 0.00 0.00 0.00 0.0023时05分27秒 eth1909.18 818.37 64.31 148.47 0.00 0.00 0.00

问题排查之：服务器CPU君

查看了cpu之后发现并没有什么异常，8核的cpu使用率不到1%

top 时时显示服务器资源信息

Cpu0 : 57.4%us, 2.6%sy, 0.0%ni, 32.3%id, 0.0%wa, 2.6%hi, 5.2%si, 0.0%st

Cpu1 :0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Cpu2 :0.6%us, 0.0%sy, 0.0%ni, 99.4%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Cpu3 :0.6%us, 0.0%sy, 0.0%ni, 99.4%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Cpu4 :0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Cpu5 :0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Cpu6 :0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Cpu7 :0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

问题排查之：服务器内存君

查看了内存使用情况，可用内存还很多，16GB的内存，可用内存还有5GB之多

free -m 显示内存信息

total used freeshared buffers cached

Mem:15950 10338 5612 0 105 8925

-/+ buffers/cache: 1307 14642Swap:1023 682 341

问题排查之：外来进程君

ps -ef 显示系统进程

这里不方便把服务器开启了那些进程罗列到此处，还请见谅；最后的分析结果就是，并无异常进程

这就奇怪了，到底是哪的问题呢？

此时io这个词，在我头脑中转悠，我想会不会硬盘io堵塞，导致读取数据超级慢呢？来，继续

问题排查之：系统io君

iostart -x 1 每一秒钟查看一下系统下所有磁盘的io使用状况

avg-cpu: %user %nice %system %iowait %steal %idle11.64 0.00 1.13 0.00 0.00 7.23Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util

sda0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00sdb0.00 7.00 0.00 5.00 0.00 104.00 20.80 0.00 0.20 0.20 99.10dm-0 0.00 0.00 0.00 12.00 0.00 104.00 8.67 0.01 0.67 0.08 0.10

找到了一个可疑的元凶，磁盘io的等待很高，磁盘超负荷运转。

沿着这个思路，顺藤摸瓜，找到了研发同事问了下对mongodb做了什么，他们淡定的说，就是简单的增加、查询之操作；好吧，那我就看看到底mongo的使用状态吧

顺藤蘑菇啊之：mongo系统使用状况

insert query update delete getmore command flushes mapped vsize res faults locked db idx miss % qr|qw ar|aw netIn netOut conn repl time

*0 *0 *0 *0 0 2|0 0 31g 62.7g 999m 0 young:0.0% 0 0|0 0|0 120b 3k 18 SLV 23:19:57

*0 *0 *0 *0 0 1|0 0 31g 62.7g 999m 0 young:0.0% 0 0|0 0|0 62b 3k 18 SLV 23:19:58

*0 *0 *0 *0 0 8|0 0 31g 62.7g 999m 0 local:0.0% 0 0|0 0|0 468b 5k 18 SLV 23:19:59

*0 *0 *0 *0 0 5|0 0 31g 62.7g 999m 0 young:0.0% 0 0|0 0|0 294b 4k 18 SLV 23:20:00

*1 *0 *0 *0 0 6|0 0 31g 62.7g 999m 0 .:0.1% 0 0|0 0|0 352b 4k 18 SLV 23:20:01

*0 *0 *0 *0 0 2|0 0 31g 62.7g 999m 0 young:0.0% 0 0|0 0|0 120b 3k 18 SLV 23:20:02

的

原文：http://www.cnblogs.com/xinzhiyu/p/5907542.html