一次服务大量超时的java排查过程经验

一次应用提供的服务化接口收到报警大量超时,报404.赶忙着手处理:

１)查看监控报表的cpu  load ,jvm gc情况,jvm内存,io都正常,如果没有做监控可以手工到服务器上命令查看

２)检查网络包括http响应及tcp网络响应请求情况均正常

３)登陆服务器,jps -v把java进程打出来,或者top发现j该java进程的cpu使用率及内存占用率均正常

4)top -H -p PID 命令查看该进程里对应的当前线程数量正常,各线程占用的cpu和内存正常.和上次cpu load过高时不一样,当时的线程是有几个占用了较高的cpu.

5)jstack pid  打出来一台服务超时和一台重启后正常提供服务的stack信息,发现差不多,都有类似信息:

6)执行 jstack [进程pid]|grep -A 100 [线程pid]

发现有问题的这台机器单个线程出现上面的信息较多,正常服务的服务器打出来的线程上面的并发销等待信息较少

对上面信息分析后,结合自己的应用情况得到下面的信息:

应用报404是做了超时控制,请求大于500ms就报404请求,监控到后台服务平均响应基本是1000ms左右.从日志报错情况来看,有一个搜索的接口不停打超时日志,但咨询接口方说该接口正常.这个接口是http请求,curl这个请求返回正常.

但异步加载框架设置的超时刚好１秒钟.所以基本断定这个接口不可用,直接给异步框架做超时控制１秒钟返回,因为大于500ms直接报404.

重启后的机器这个接口没有报错,说明connection出现了问题.

至于为什么突然出现这个问题,这个错误的信息很重要,初步看是nio报的,问题远没想象的简单.后继再找接口方排查