生产环境使用 JDK8+SpringBoot2.x+SpringBoot 内嵌 tomcat9.x,
在 K8s Docker 环境部署，最近时有偶发的对方发起 HTTP 请求，这边隔了 2-10s 才会处理请求，网络抓包发现握手和响应请求报文 ACK 都很快，但是链路上看 Servlet 就是间隔了 2-10s 才进行处理
看了下当时的并发、资源情况和 GC 都很正常，由于是偶发的，本地也无法复现，所以想咨询各位大佬

这种偶发的阻塞还有可能是其他什么原因引起的，可以从哪方面进行排查?
是否有工具或者方法检测监控这种问题?

iptables 规则太多了？

感觉是 k8s 的问题，我们相同版本的 jdk + springboot 。 但是没有用 k8s ， 直接用的阿里云的 ecs, 没出现过这种问题。

服务端负载很高吗？把抓包文件或者截图放上来看看

哥们怎么哪都有你 老摸鱼怪呀

线程数满了？

看是不是 swap 了

最近时有偶发的对方发起 HTTP 请求，这边隔了 2-10s 才会处理请求想问一下这里的隔了 2-10s 才会处理请求是通过什么方式确认的？是查看具体的 tomcat http 线程任务打印的日志么？此外，能不能发一下 tomcat http 线程的配置以及实际的线程信息

极大概率是 DNS 解析导致的(遇到过走 ipv6 解析，5s timeout 后回落到 ipv4)。从请求发送端看看，尤其是用了 alpine 镜像的服务容器

同意楼上的说法，之前我们也有个内网的服务器登录时耗时 10S+其他接口都没问题。最后排查原因是 InetAddress.getLocalHost().getHostName() 的问题。参考: stackoverflow.com/questions/33289695/inetaddress-getlocalhost-slow-to-run-30-seconds

加日志 逐步排查 提供个思路增加请求 traceid 把请求日志串联起来，并返回给调用方调用方给出耗时高的 traceid你这边捞日志看耗时在哪里，当然最好是能接入 apm 系统，可以更直观看到耗时在哪

看看是不是有人在接口里写了一句 thread.sleep

想办法抓个火焰图看看

尽量别用 alpine 镜像

＃7 链路 trace 的 servet＃service 方法以及过滤器打印的请求日志，这两个时间差不多， 并发不高，tomcat 线程没有满

＃8 走的注册中心，直接拿 IP 访问的，不用 DNS 解析了吧

＃9 走的注册中心，直接拿 IP 访问的，不用 DNS 解析了吧

＃10 已经有 trace 了，但是只 trace 到 servet＃service 这层，前面 tomcat nio 那一层暂时 trace 不到

＃13 用的麒麟

＃3 负载并发不高

stackoverflow.com/questions/9882357/how-to-set-java-net-preferipv4stack-true-at-runtime stackoverflow.com/questions/58991966/what-java-security-egd-option-is-for我猜可能和这两个有关系，可以试一下；可以用 arthas trace 一下调用链路，看看耗时在哪儿