Mongodb数据服务器相关情况：
Mongodb版本：3.4.0
部署模式：分片（4个分片，每个分片都是1主2从）
数据量：每个分片有15亿数据(记录数)
机器配置：分片都是虚拟机,SSD 硬盘，32G内存，8C
出现的情况：4个分片，有一个分片的主在日志里出现大量的“serverStatus was very slow"日志，但是从没有出现这样的日志，还有一种问题就是：三个节点，无论那个节点为Mongodb的主时，日志才会出现。排除了系统本身的影响。
” serverStatus was very slow: { after basic: 0, after advisoryHostFQDNs: 0, after asserts: 0, after backgroundFlushing: 0, after connections: 0, after dur: 0, after extra_info: 0, after globalLock: 0, after network: 0, after opLatencies: 0, after opcounters: 0, after opcountersRepl: 0, after oplog: 1220, after repl: 1220, after security: 1220, after sharding: 1220, after storageEngine: 1220, after tcmalloc: 1220, after wiredTiger: 1220, at end: 1220 }"
根据以前的经验：问题出在“ after oplog: 1220”上。
先看系统的IO，CPU及LOAD，一切数据表明都很正常，没有让人感觉问题所在!
还看了系统的各种内核参数（主要是Limit），也都有安照官方的说法进行了修改，没有问题！
再看oplog.rs的大小，最大值是50G，现在有近10亿条记录，难道是记录数太多的原因，有点不敢信。好吧测试改下
附：修改oplog.rs的修改（Mongodb3.6已经支持在线修改了，但是3.4还是老实的按步骤修改吧）
#######################
在从上执行：db.shutdownserver(),然后以单实例启动数据库后，shell执行
use local
db.temp.drop()
db.temp.save( db.oplog.rs.find( { }, { ts: 1, h: 1 } ).sort( {$natural : -1} ).limit(1).next() )
db.oplog.rs.drop()
db.runCommand( { create: "oplog.rs", capped: true, size: (20 * 1024 * 1024 * 1024) } )
db.oplog.rs.save( db.temp.findOne() )
#查看一下是否有条记录了！
db.oplog.rs.find()
确认后以ReplSet重启，重新加入集群
##################
好了，现在oplog.rs的记录清空了，应该没有问题了吧，等整个集群正常后，强制这台成为主。
看日志，一万头马在心里碾过，问题依旧存在。抽支烟后继续研究！
另附一个Mongodb3.4的strace使用，如果直接使用：strace -p mongondPID的话，将不会有任何结果出来，必须加上另一个参数：-f
使用strace命令：strace -cf -p mongondPID 看一下有什么异常没有!()
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
45.89 82.805333 2103 39381 5898 futex
43.57 78.623487 28580 2751 recvfrom
3.41 6.153932 8559 719 nanosleep
3.32 5.999088 88222 68 select
2.05 3.704592 374 9918 epoll_wait
1.40 2.528608 126430 20 13 restart_syscall
0.14 0.252668 4 62720 clock_gettime
0.10 0.183186 273 671 fdatasync
0.05 0.086402 4 19708 gettimeofday
0.02 0.037975 56 681 pread
0.01 0.023175 4 5927 2221 recvmsg
0.01 0.015350 21 727 pwrite
0.01 0.012949 7 1851 sendmsg
0.01 0.009036 7 1377 sendto
真的让人抓狂呀，如何做，如何做
日志还是一样的狂打”very slow"
无奈之重启Mongodb，结果问题一样
XFS格式好像性能会好很多，好吧试一下，先停Mongodb服务（从节点），减少LV的大小，减少文件系统的大小，然后在空出来的空间上新建一个LV，格式化成xfs格式，然后把数据CP过去，重启Mongodb加入集群后，再把从变成主，再看日志，希望有奇迹出现。问题还是一样没有解决。
后来注意到启动命令里有这些参数：--nojournal 会不会跟这个有关呢！
反正已经到这一步，show hands
干掉这个参数，重启
世界突然清净了！
"serverStatus was very slow"字样竟没有出现了！
问题解决！但是如何解释这个问题，请听下回分解！