一次线上oom问题记录

某天早上发现服务无法正常访问，于是展开问题排查。

1。首先查看日志，发现有oom日志存在。

这时候看到oom，犯了想当然的错误，认为是内存不足，堆内存空间已经用完。于是查看代码发现某个模块中有如下代码：

谁写的，站出来，我保证不打你。当时盲目的认为就是使用这个线程池的问题(关于此线程池的弊端不再赘述)，于是心满意足的修改完这行之后重新执行了。

2。没想到过了一段时间，服务又无法正常访问了，这让笔者十分疑惑，查日志时又发现了相同的日志：

到了这里，笔者已经意识到，这应该是机器原因导致的，因为如果是线程池的原因，那么两次触发oom的时间应该大致相等，但是这次oom的发生却快了很多，几乎一开始运行就发生了oom。

3。于是开始debug之旅

首先，先根据服务名，找到进程id，1902

然后根据进程id，查出这个进程创建的线程数

可以看到这个服务的线程数是正常的，排除了这个服务的问题。

使用top命令，发现一个可疑的线程如下：

我们继续查看此进程的所有线程数：

问题已经基本确定，此服务进程居然用了3000多个线程，这明显是有问题的。

找到了有问题的服务，那么为什么会报一开始的错误呢？我们查看文件/etc/security/limits.d/20-nproc.conf

可以看出，除了root用户，其他用户可以创建的线程数最多是8192。如果要迅速解决oom的问题，可以把这个值改为unlimited。

但是最好的方式，肯定是优化出问题的程序，减少创建的线程数。

至此，问题的来龙去脉已经明了。

反思：当发现眼熟的错误时切忌想当然，要多思考，先从环境角度排查。另外，模块中使用newCachedThreadPool确实是有隐患，只是这次不是newCachedThreadPool的问题，也需要解决。