一次服务大量超时的java排查过程经验
来源:互联网 发布:劲舞团做图软件 编辑:程序博客网 时间:2024/06/18 02:40
一次应用提供的服务化接口收到报警大量超时,报404.赶忙着手处理:
1)查看监控报表的cpu load ,jvm gc情况,jvm内存,io都正常,如果没有做监控可以手工到服务器上命令查看
2)检查网络包括http响应及tcp网络响应请求情况均正常
3)登陆服务器,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这个请求返回正常.
但异步加载框架设置的超时刚好1秒钟.所以基本断定这个接口不可用,直接给异步框架做超时控制1秒钟返回,因为大于500ms直接报404.
重启后的机器这个接口没有报错,说明connection出现了问题.
至于为什么突然出现这个问题,这个错误的信息很重要,初步看是nio报的,问题远没想象的简单.后继再找接口方排查
- 一次服务大量超时的java排查过程经验
- 一次服务大量超时的java排查过程经验
- 一次segfault错误的排查过程
- 一次segfault错误的排查过程
- 一次mysql死锁的排查过程
- 一次线上OOM过程的排查
- 一次mysql死锁的排查过程
- 一次Mysql死锁排查过程的全纪录
- 一次频繁Full GC的排查过程
- 记一次线上问题的排查过程
- 记一次 BUG 的排查过程
- 一次OOM排查过程
- 记一次服务停止排查
- 一次slab异常排查过程
- 记一次troubleshooting排查过程
- 记录一次对代码完全陌生的问题排查过程
- 一次php进程诡异退出的排查过程
- 一次oracle 中用户被锁的排查过程
- 数字图像处理学习笔记:图像保存路径问题
- vb.net 总结
- n a^o7 ! 2012年"浪潮杯"山东省第三届ACM大学生程序设计竞赛 队友不在,只好划水。。。
- vim编辑显示行号
- PHP封装验证码类
- 一次服务大量超时的java排查过程经验
- 深入浅出UML类图(一)
- leetcode 17 Letter Combinations of a Phone Number
- 树 Path Sum
- 第三章作业 3.24
- Linux内存管理
- android开发之事件处理(祥谈)
- HTTP中GET与POST之间的区别
- 在Android上用AChartEngine绘制图表并嵌入Activity