首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >一次线上tomcat应用请求阻塞的排查经过

一次线上tomcat应用请求阻塞的排查经过

作者头像
老白
发布2018-03-19 16:19:43
2.6K0
发布2018-03-19 16:19:43
举报
文章被收录于专栏:架构之路架构之路

今天早上,收到一个报警,有个服务器的http往返时延飙升,同时曝出大量404,很是折腾了一番,特记录下思考和排查经过。

1.这是单纯的时延增大,还是有什么其他情况还未掌握?

因为不知道是只有时延变大而已,还是同时有别的情况,第一反应是先看日志有没有异常。

看了一下,一片风平浪静,既是好消息也是坏消息。好消息是核心业务还在,不然一定会打日志,坏消息是日志提供不了任何信息。当然这也说明了我们的日志肯定有不到位的地方。

2.换个思路,日志风平浪静,是否只是服务器启动了什么任务,占用了大量cpu/IO等?GC呢?

于是去看监控,服务器CPU利用率、磁盘利用率、内存利用率、Swap交换次数都很正常。

那么会不会是一次长时间的FGC导致请求大量堆积了呢?又去看gc,结果发现也很正常,这段时间连fgc都没有触发过,minorGC的时间也在合理范围内。此路不通

3.再换个思路,往返时延增大,又没有全部404,看起来像是服务器处理不过来了,那么既然服务器资源充足,为什么处理不过来了呢?是不是tcp的问题

于是去查tcp连接和端口,果然发现了一点端倪,服务器上有大量的close_wait。熟悉tcp的人应该知道,close_wait是tcp连接时,被动关闭的一方会产生的状态。所以往返时延增大就有了一个合理的解释:大量处于close_wait的未关闭socket无法被释放,导致tomcat的可用连接非常少,从而请求堆积,往返时延增大,甚至超时。

4.继续思考,为何有大量的close_wait?

通常情况下,可能是程序员没有关闭socket,我们的项目里不存在这种情况。那么,目前最大的可能是:请求阻塞在什么地方了,客户端已经超时发送fin,所以服务端就变成了close_wait,在等待请求执行完之后才能切换状态。TCP的状态切换是排错基本功,同学们一定要掌握啊!

5.被阻塞的请求阻塞在了什么地方?

这个其实比较好处理,因为通常情况下,阻塞发生在IO处。再顺一下业务逻辑,最大的嫌疑是数据库。查一下sql执行时间,发现一条简单的select 1 from dual,执行时间都非常长。那就好解释了,sql执行太慢,连接池连接耗尽,后续请求只能阻塞。打电话给运维,运维:啊?我刚刚做表迁移来着,忘了告诉你们......我:*%&&@*@@&&¥&……()*

6.小插曲,sql超时是会报异常的,为何日志里没有报警呢?

答案是,服务器的主业务压根不走数据库,丫只是因为可用连接太少了所以才时延上升。走数据库的那个链接应该是报了异常的,只是有位大仙把测试时的日志输出到console的设置覆盖了线上输出到文件的设置...

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2018-01-30 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1.这是单纯的时延增大,还是有什么其他情况还未掌握?
  • 2.换个思路,日志风平浪静,是否只是服务器启动了什么任务,占用了大量cpu/IO等?GC呢?
  • 3.再换个思路,往返时延增大,又没有全部404,看起来像是服务器处理不过来了,那么既然服务器资源充足,为什么处理不过来了呢?是不是tcp的问题
  • 4.继续思考,为何有大量的close_wait?
  • 5.被阻塞的请求阻塞在了什么地方?
  • 6.小插曲,sql超时是会报异常的,为何日志里没有报警呢?
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档