北京时间 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秒        lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00
23时05分27秒      eth1    909.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       free     shared    buffers     cached
Mem:         15950      10338       5612          0        105       8925
-/+ buffers/cache:       1307      14642
Swap:         1023        682        341 

问题排查之：外来进程君

ps -ef 显示系统进程

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

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

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

问题排查之：系统io君

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

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          11.64    0.00    1.13    0.00    0.00   7.23

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb               0.00     7.00    0.00    5.00     0.00   104.00    20.80     0.00    0.20   0.20   99.10
dm-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

的