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 那就可以排查出是哪种情况 |