生产环境使用 JDK8+SpringBoot2.x+SpringBoot 内嵌 tomcat9.x,
在 K8s Docker 环境部署,最近时有偶发的对方发起 HTTP 请求,这边隔了 2-10s 才会处理请求,网络抓包发现握手和响应请求报文 ACK 都很快,但是链路上看 Servlet 就是间隔了 2-10s 才进行处理
看了下当时的并发、资源情况和 GC 都很正常,由于是偶发的,本地也无法复现,所以想咨询各位大佬
1
defunct9 201 天前
iptables 规则太多了?
|
2
javak 201 天前
感觉是 k8s 的问题,我们相同版本的 jdk + springboot 。 但是没有用 k8s , 直接用的阿里云的 ecs, 没出现过这种问题。
|
3
Scarb 201 天前
服务端负载很高吗?把抓包文件或者截图放上来看看
|
5
leeyuzhe 201 天前
线程数满了?
|
6
cheng6563 201 天前
看是不是 swap 了
|
7
justNoBody 201 天前
> 最近时有偶发的对方发起 HTTP 请求,这边隔了 2-10s 才会处理请求
想问一下这里的隔了 2-10s 才会处理请求是通过什么方式确认的?是查看具体的 tomcat http 线程任务打印的日志么? 此外,能不能发一下 tomcat http 线程的配置以及实际的线程信息 |
8
cloud107202 201 天前
极大概率是 DNS 解析导致的(遇到过走 ipv6 解析,5s timeout 后回落到 ipv4)。从请求发送端看看,尤其是用了 alpine 镜像的服务容器
|
9
2tongW 201 天前
同意楼上的说法,之前我们也有个内网的服务器登录时耗时 10S+其他接口都没问题。最后排查原因是 InetAddress.getLocalHost().getHostName() 的问题。
参考:https://stackoverflow.com/questions/33289695/inetaddress-getlocalhost-slow-to-run-30-seconds |
10
liuhailiang 201 天前
加日志 逐步排查 提供个思路
增加请求 traceid 把请求日志串联起来,并返回给调用方 调用方给出耗时高的 traceid 你这边捞日志看耗时在哪里,当然最好是能接入 apm 系统,可以更直观看到耗时在哪 |
11
bthulu 201 天前
看看是不是有人在接口里写了一句 thread.sleep
|
12
zed1018 201 天前
想办法抓个火焰图看看
|
13
anyele 201 天前
尽量别用 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 201 天前
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 201 天前
获取随机数的时候很慢?
|
22
xueling 200 天前
偶发性的问题不太容易定位,跟很多因素有关,可能是外部原因,比如正在 GC ,或者某个时间段网络/磁盘 IO 过载导致的,也可能是你接口本身的问题,其实原因挺多的。最好监控一下接口在各个耗时区间的分布情况,然后在每个重要环节都添加上耗时监控,再把 trackId 找出来比对日志逐一排查。偶发性的问题其实不太好排查,都是笨方法。可以了解一下我的开源项目: https://github.com/xl-xueling/xl-lighthouse ,让你轻松实现任意细粒度的接口耗时监控。
|