Mongodb - Timeout waiting for a pooled item after 120000 MILLISECONDS

前言

        生产出现了mongodb的连接超时问题导致了整个系统不可用,遂进行排查

问题排查

原因一

        首先是翻看当天有什么代码更新,看到了同事提交了如下代码, 直接在代码里面进行了休眠,这个肯定是不行的.经过询问以后是说登录后直接去查数据(打开日志)直接查不到,所以需要延时进行处理,但是如果这里阻塞了的话是会占用应用的线程的,导致其他地方没有线程可用

        改正方式, 这里的逻辑是登录日志后触发的逻辑,因此在登录日志后要发布的时候用延时线程池进行发布,就可以避免过多占用应用本身线程了,因为线程池的原理只会用特意的几个进行轮询排队,本质只用了那几个线程(限制了线程池的任务大小)

原因二

        这个原因可能比较重要,那就是小程序有个游戏小礼包的功能,需要查询最近的数据,但是由于没有加索引导致扫描了 1000多万的数据, 每个请求的处理时间都需要36秒,从而引起了慢日志,占用了很多链接和资源引起挂机

        这个到阿里云后台看慢日志,然后针对性的加上索引即可,只是阿里云的后台没有按耗时排序的功能,得自己一个个慢慢才能翻找到

原因三

        这个是之前发现的bug了,也是通知问题,顺便一起记录过来了. 这个是因为登录日志是要放到mongo的,然后大促时很多人登录,而登录日志是实时插入的导致量过多从而占用了太多的链接资源来不及释放引起的问题

       

        解决方法也不是很复杂,就是把登录日志移动到异步事件中进行处理即可.业务上其实本就该如此,之前设计这块代码的人没有提前考虑到了

总结

        问题的解决其实并不复杂,麻烦的是需要定位到是哪里占用的频繁资源.这就得一步步走了,具体的思路有以下几个方面

 

1: 排查慢日志语句,根据语句做相关的处理

2: 查看哪里报的异常,根据异常去进行反向定位处理

3: 对业务进行分析查看了,写的时候尽量小范围查询,并且要加索引