这是一个创建于 573 天前的主题，其中的信息可能已经有所发展或是发生改变。
生产环境使用 JDK8+SpringBoot2.x+SpringBoot 内嵌 tomcat9.x,
在 K8s Docker 环境部署，最近时有偶发的对方发起 HTTP 请求，这边隔了 2-10s 才会处理请求，网络抓包发现握手和响应请求报文 ACK 都很快，但是链路上看 Servlet 就是间隔了 2-10s 才进行处理
看了下当时的并发、资源情况和 GC 都很正常，由于是偶发的，本地也无法复现，所以想咨询各位大佬
- 这种偶发的阻塞还有可能是其他什么原因引起的，可以从哪方面进行排查?
- 是否有工具或者方法检测监控这种问题?
22 条回复 2024-05-25 22:29:35 +08:00
 | 1 defunct9 2024-05-24 10:04:49 +08:00 iptables 规则太多了？ |
 | 2 javak 2024-05-24 10:13:10 +08:00 感觉是 k8s 的问题，我们相同版本的 jdk + springboot 。 但是没有用 k8s ， 直接用的阿里云的 ecs, 没出现过这种问题。 |
 | 3 Scarb 2024-05-24 10:17:31 +08:00 服务端负载很高吗？把抓包文件或者截图放上来看看 |
 | 5 ThisDay 2024-05-24 11:01:38 +08:00 线程数满了？ |
 | 6 cheng6563 2024-05-24 11:02:55 +08:00 看是不是 swap 了 |
 | 7 jusNoBody 2024-05-24 11:14:53 +08:00 > 最近时有偶发的对方发起 HTTP 请求，这边隔了 2-10s 才会处理请求 想问一下这里的隔了 2-10s 才会处理请求是通过什么方式确认的？是查看具体的 tomcat http 线程任务打印的日志么？ 此外，能不能发一下 tomcat http 线程的配置以及实际的线程信息 |
 | 8 cloud107202 2024-05-24 11:25:49 +08:00 极大概率是 DNS 解析导致的(遇到过走 ipv6 解析，5s timeout 后回落到 ipv4)。从请求发送端看看，尤其是用了 alpine 镜像的服务容器 |
 | 9 2tongW 2024-05-24 11:35:16 +08:00 同意楼上的说法，之前我们也有个内网的服务器登录时耗时 10S+其他接口都没问题。最后排查原因是 InetAddress.getLocalHost().getHostName() 的问题。 参考:https://stackoverflow.com/questions/33289695/inetaddress-getlocalhost-slow-to-run-30-seconds |
 | 10 liuhailiang 2024-05-24 11:36:29 +08:00 加日志 逐步排查 提供个思路 增加请求 traceid 把请求日志串联起来，并返回给调用方 调用方给出耗时高的 traceid 你这边捞日志看耗时在哪里，当然最好是能接入 apm 系统，可以更直观看到耗时在哪 |
 | 11 bthulu 2024-05-24 11:49:04 +08:00 看看是不是有人在接口里写了一句 thread.sleep |
 | 12 zed1018 2024-05-24 12:03:46 +08:00 想办法抓个火焰图看看 |
 | 13 anyele 2024-05-24 13:29:50 +08:00 尽量别用 alpine 镜像 |
 | 14 jmychou OP @justNoBody #7 链路 trace 的 servet#service 方法以及过滤器打印的请求日志，这两个时间差不多， 并发不高，tomcat 线程没有满 |
| 15 jmychou OP @cloud107202 #8 走的注册中心，直接拿 IP 访问的，不用 DNS 解析了吧 |
| 17 jmychou OP @liuhailiang #10 已经有 trace 了，但是只 trace 到 servet#service 这层，前面 tomcat nio 那一层暂时 trace 不到 |
 | 20 YCNQc647Cfngdp89 2024-05-24 15:29:23 +08:00 https://stackoverflow.com/questions/9882357/how-to-set-java-net-preferipv4stack-true-at-runtime https://stackoverflow.com/questions/58991966/what-java-security-egd-option-is-for 我猜可能和这两个有关系，可以试一下；可以用 arthas trace 一下调用链路，看看耗时在哪儿 |
 | 21 Mystery0 2024-05-24 18:12:50 +08:00 获取随机数的时候很慢？ |
 | 22 xueling 2024-05-25 22:29:35 +08:00 偶发性的问题不太容易定位，跟很多因素有关，可能是外部原因，比如正在 GC ，或者某个时间段网络/磁盘 IO 过载导致的，也可能是你接口本身的问题，其实原因挺多的。最好监控一下接口在各个耗时区间的分布情况，然后在每个重要环节都添加上耗时监控，再把 trackId 找出来比对日志逐一排查。偶发性的问题其实不太好排查，都是笨方法。可以了解一下我的开源项目： https://github.com/xl-xueling/xl-lighthouse ，让你轻松实现任意细粒度的接口耗时监控。 |
Select Language