记一次tomcat报错Too many open files的排查历程

本文的技术细节并不具通用性，但是排查的思路过程值得自己mark下，上次遇到这样的刺激线上故障已经是去年3月了～～～这次排查花了3个小时，还算快啦，也算最近的一个小彩蛋。

昨天在公司coding，测试组的同事突然来找我，告知预发环境的系统挂了，请求都是异常，打开业务日志和tomcat的日志排查，满屏的Too many open files，果然 lsof -p pid 预发机器，已经打满到了65535个，很多都是anon_inode pipe FIFO REG，真的不知道这是什么鬼：

内心一紧，赶紧用lsof -p pid 查看了下线上所有生产机器的文件描述符个数，所幸都在正常范围，这才放下心对预发环境的故障进行排查。

首先保存事故现场，用新端口给qa紧急部署了一个新的环境，nginx转发到新的端口。

接下来就是jstack对堆栈进行检查。jstack的结果是有10个左右的线程处于innative的状态，其他线程都是处于blocked的状态。处于innative状态的线程，有一个明显是tomcat的主线程，有6，7个处于epoll的epoll_wait状态，还有一个是我们开启的内部端口监听，也是wait状态，剩下的数百个blocked线程都在tomcat的quene take的wait状态。我想了想，又谷歌了下，会不会是epoll_wait的bug呢࿰