作者回复: 如果redis服务端未发生超时的情况,大概率是数据包阻塞在内核缓冲区太久导致的,也就是说数据包到达了内核缓冲区,但是redis没有及时读取它。没有及时读取的原因可能为:
1. 软中断打断redis
2. redis调度延迟
也可能会有其他原因。
排查思路也有的。这类问题我会有ftrace的kprobe_events机制来排查。比如追踪下面几个内核函数:
- tcp_rcv_established : 数据包到达内核缓冲区
- tcp_recvmsg: 数据包被应用读取
这两个时间戳相减就是数据包在内核缓冲区停留的时间。
作者回复: 嗯 是的
作者回复: 对的!
作者回复: 主要是centos7,也有centos6和8,还有一些是Ubuntu。
这个问题倒没有遇到过。
作者回复: 对的 rtt时间不仅仅包含网络时间 还有内核软中断处理时间 另外还存在delayed ack
作者回复: 是的!回答的很好。
作者回复: 是的 另外还存在delayed ack这种情况。
作者回复: 1. 部分线上机器装了systemtap,特别是centos7的系统上;在centos8的系统上,我们一般是使用ebpf,比如bcc或者boftrace。
2. 目前还没有开源计划,但是该模块的一些思想以及一些关键的tracepont我在这个系列课程里都讲到了 如果你看到仔细的话你会找到,利用这些tracepoint你也可以实现类似的模块。