pd server timeout

只能说提供一个方向吧。
tcp retrans这个图的监控内容我跟踪了一下。
是从prometheus下的node_exporter组件里面取的值node_netstat_Tcp_RetransSegs

实现在这里:
https://github.com/prometheus/node_exporter/blob/master/collector/netstat_linux.go#L39C323-L39C334

大致和
netstat -s | grep 'segments retransmited' | awk '{print $1}'
是等效的。

而segments retransmited看下来,解释都是说

|RetransSegs|所有重传出去的TCP包|tcp_v4_rtx_synack()和tcp_v6_rtx_synack()中
统计重传的SYNACK包,
tcp_retransmit_skb()中统计其他重传包|
| --- | --- |

https://perthcharles.github.io/2015/11/09/wiki-rfc2012-snmp-proc/

这个值单独是不能判断网络是否存在异常,搜索的结果大多赞同使用
netstat -s | grep ‘segments send out’ | awk ‘{print $1}’
算一个比值。这个值的高低才是一个客观的网络情况。

这个out segment 在node_exporter里面是有采集的。看能不能在这个图上调出来。
原始指标名称是node_netstat_Tcp_OutSegs。算算看这个值是否超过1%。

tcp和ping是不同的协议,ping值很低,但tcp重传很高的话,也很难说网络没有问题。不过定位的难度确实很大,就不清楚是什么问题造成的。
往下走我也没有什么思路了。看看其他大神是否有更好的办法。

官方给的错误诊断是让检查网络波动,我觉得他们能这么写出来肯定是遇到过类似的报错总结的经验

1 个赞

我原本也觉得应该有这类日志,不该只是一些调度的日志,那些调度日志看着都挺正常的。

应该是tidb和pd之间的网络有中断

tcp retrans比较高的那台服务器是一个pd follower节点,因为上面部署着haproxy,业务连接的入口,所有连接数很多,但是实际上pd leader那台服务器的负载是很低的,tcp retrans也很低,出问题那个时间点为0

目前也只能猜测是网络问题了,看black_exporter,tidb server到pd server leader的ping latency倒是都很正常,也可能是tcp有些问题

一开始是朝这个方向排查,目前是没什么证据,先猜测是网络问题了,看会不会再次出现了

1 个赞


到这看着都正常啊,pd在处理区域心跳时发生了什么阻塞?而且这种状态一直持续到操作超时!
PD的日志是看不出来了,TiKV的日志不知道有没有哪个节点有报错

这个图我编辑了一下,倒确实是可以把out的包也调出来。不过怎么让2者相除计算重发率就搞不出来了。
也算是一个排查方向,供参考。

1 个赞

好的,多谢

看看是不是有网络丢包或者重传?

网络是不是有问题

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。