这是一个创建于 1178 天前的主题，其中的信息可能已经有所发展或是发生改变。
背景：电商场景某些线上接口，在调用中台服务时会报超时，这种情况导致可用率在百分之 99.xx%
分析原因：查看上下游 RPC 接口调用时长，基本在 50-100ms ，最大也就在 100ms 。但是 rpc 报的 ClientTimeoutException 长达 3000ms ，没有启动多线程调用，排除线程池耗尽线程等待的情况。
然后实在分析不出来原因了，有人遇到过么，在此请教
分析原因：查看上下游 RPC 接口调用时长，基本在 50-100ms ，最大也就在 100ms 。但是 rpc 报的 ClientTimeoutException 长达 3000ms ，没有启动多线程调用，排除线程池耗尽线程等待的情况。
然后实在分析不出来原因了，有人遇到过么，在此请教
 | 1 jj783850915 2022-07-21 16:26:56 +08:00 带宽？ |
 | 2 coderxy 2022-07-21 17:14:04 +08:00 我遇到过类似的。 当时的原因是 cpu load 很高造成的。 还有一种，是 grpc 的一个参数限制了最大并发数，造成 client 在等待中消耗了过多的时间。 |
 | 3 diyazhu 2022-07-21 17:47:48 +08:00 偶尔的网络抖动？ |
 | 4 hhyvs111 2022-07-21 18:14:30 +08:00 就是 cpu 受限了 |
 | 5 ccagml 2022-07-21 22:24:45 +08:00 via Android 没有可用端口？ |
 | 6 cs419 2022-07-22 06:34:26 +08:00 查超时时间 没日志么？ |
 | 7 dwlovelife OP @cs419 有日志 日志报的 A->B [调用] 接口超时-超时时间 3000ms ，但是 B 接口查看所有被调用时间没有超过 3000ms 的 |
 | 8 chenshun00 2022-07-22 09:32:39 +08:00 A 有没有 GC 啥的 |
| 9 dwlovelife OP @chenshun00 GC 才多久 |
 | 10 zuiye111 2022-07-22 10:07:04 +08:00 是偶现还是常态？ 偶现的话，看是否网络抖动导致 B 的回包超时； A 节点负载是否过高； 常态的话，分析 A 模块逻辑，除了简单 rpc 调用，是否还做了其他耗时逻辑，导致你统计本身就不对？框架本身是否有自动换机重试机制？例如 A 调用 B1 ，超时 1s ，换机调用 B2 ，又超时 1s 再者，是否有链路追踪，traceid 之类，分析超时前后上下文日志 |
| 11 cs419 2022-07-23 08:17:39 +08:00 A 调 B 超时 3000ms B 这边无异常 这就分两种情况 1. A 的请求送出去了，但 B 一直没收到 2. B 的回信送出去了 但 A 一直没收到 日志如果有全局的 traceid 那就可以排查出是哪种情况 |