这个问题已经发生两个月了，原本不想额外记录，因为从原理上讲，这是个很常规且低级的技术问题，但是一直出现类似的低级技术问题，让我思考根因恐怕是管理问题，因为现在发现的问题并不是最近才有的，而历史问题不出故障就没人关注，系统都是只要能跑就行。虽然有监控，但是开发无权查看，就是演给领导看的。只能说技术人的困难从来不是来自于疑难杂症。起因就是某天半夜，系统异常频繁告警并收到消息mongo节点故障，流量从故障节点打到备节点，不久备节点也挂了，重启节点后告警停止，但是查询的接口耗时还是很高，代码没有改动，业务上的变化就是最近的用户量快速增加，对系统性能的要求会更高些。但是为什么会导致mongo节点挂掉还是不知道原因。本着起都起来了，反正也睡不着的原则，我又继续排查。这里有个隐藏的坑，根据后来分析的结果，虽然Mongo有分片，但是实际上分片并没有承担请求，只是个备份，所以相应的表查询还是只打到一个分片上。首先看正常的mongo节点的负载接下来是有问题的mongo节点的负载虽然机器是32核，按说不能算不正常，但是明显高于其他节点的负载很可能有隐患，那到底是什么导致的系统负载变高？要怎么查？当时也是没什么头绪，索性就按照查Java服务的方法去查了，查到mongo的进程ID，然后top -Hp看哪些线程cpu使用高，但是不能像Java一样用jstack查对应线程做了什么，就比较棘手。好在top有一列COMMAND，可以通过这个去查。