Linux内核技术实战课
邵亚方
前蘑菇街技术专家，Linux Kernel活跃贡献者
新⼈⾸单¥9.9
2877 人已学习
课程目录
已完结 24 讲
0/4登录后，你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 如何让Linux内核更好地服务应用程序？
免费
Page Cache管理问题 (5讲)
01 基础篇 | 如何用数据观测Page Cache？
02 基础篇 | Page Cache是怎样产生和释放的？
03 案例篇 | 如何处理Page Cache难以回收产生的load飙高问题？
04 案例篇 | 如何处理Page Cache容易回收引起的业务性能问题？
免费
05 分析篇 | 如何判断问题是否由Page Cache产生的？
内存泄漏问题 (5讲)
06 基础篇 | 进程的哪些内存类型容易引起内存泄漏？
07 案例篇 | 如何预防内存泄漏导致的系统假死？
08 案例篇 | Shmem：进程没有消耗内存，内存哪去了？
09 分析篇 | 如何对内核内存泄漏做些基础的分析？
10 分析篇 | 内存泄漏时，我们该如何一步步找到根因？
TCP重传问题 (6讲)
11 基础篇 | TCP连接的建立和断开受哪些系统配置影响？
12 基础篇 | TCP收发包过程会受哪些配置项影响？
13 案例篇 | TCP拥塞控制是如何导致业务性能抖动的？
14 案例篇 | TCP端到端时延变大，怎样判断是哪里出现了问题？
15 分析篇 | 如何高效地分析TCP重传问题？
16 套路篇 | 如何分析常见的TCP问题？
内核态CPU利用率飙高问题 (4讲)
17 基础篇 | CPU是如何执行任务的？
18 案例篇 | 业务是否需要使用透明大页：水可载舟，亦可覆舟？
19 案例篇 | 网络吞吐高的业务是否需要开启网卡特性呢？
20 分析篇 | 如何分析CPU利用率飙高问题 ？
加餐 (1讲)
加餐 | 我是如何使用tracepoint来分析内核Bug的？
结束语 (1讲)
结束语 | 第一次看内核代码，我也很懵逼
结课测试 (1讲)
结课测试 | 这些Linux内核技术实战技能你都掌握了吗？
14 案例篇 | TCP端到端时延变大，怎样判断是哪里出现了问题？
邵亚方 2020-09-19
你好，我是邵亚方。
如果你是一名互联网从业者，那你对下面这个场景应该不会陌生：客户端发送请求给服务端，服务端将请求处理完后，再把响应数据发送回客户端，这就是典型的 C/S（Client/Server）架构。对于这种请求 - 响应式的服务，我们不得不面对的问题是：
如果客户端收到的响应时间变大了，那么这是客户端自身的问题呢，还是因为服务端处理得慢呢，又或者是因为网络有抖动呢？
即使我们已经明确了是服务端或者客户端的问题，那么究竟是应用程序自身引起的问题呢，还是内核导致的问题呢？
而且很多时候，这种问题往往是一天可能最多抖动一两次，我们很难去抓现场信息。
为了更好地处理这类折磨人的问题，我也摸索了一些手段来进行实时追踪，既不会给应用程序和系统带来明显的开销，又可以在出现这些故障时能够把信息给抓取出来，从而帮助我们快速定位出问题所在。
因此，这节课我来分享下我在这方面的一些实践，以及解决过的一些具体案例。
当然，这些实践并不仅仅适用于这种 C/S 架构，对于其他应用程序，特别是对延迟比较敏感的应用程序，同样具备参考意义。比如说：
如果我的业务运行在虚拟机里面，那怎么追踪呢？
如果 Client 和 Server 之间还有一个 Proxy，那怎么判断是不是 Proxy 引起的问题呢？
确认放弃笔记？
放弃后所记笔记将不保留。
新功能上线，你的历史笔记已初始化为私密笔记，是否一键批量公开？
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Linux内核技术实战课》，如需阅读全部文章，
请订阅文章所属专栏，新⼈⾸单¥9.9
请订阅文章所属专栏，新⼈⾸单¥9.9
立即订阅
登录 后留言
精选留言(9)
邵亚方 置顶课后作业答案：
- 结合这堂课的第一张图，在这张图中，请问是否可以用 TCP 流到达 B 点的时刻（到达 Server 这台主机的时间）减去 TCP 流经过 A 点的时刻（到达 Client 这台主机的时间）来做为网络耗时？为什么？
很多同学在课后评论里都回答的很好了。比如：
“主要原因是两边的时间不统一。
有可能客户端的时间比服务端的快。
只有选取相同的时间基点，算出的差值才有意义。”
- 结合我们在“13 讲“里讲到的 RTT 这个往返时延，你还可以进一步思考：是否可以使用 RTT 来作为这次网络耗时？为什么？欢迎你在留言区与我讨论。
也不可以。
rtt时间不仅仅包含网络时间 还有内核软中断处理时间 另外还存在delayed ack，所以它不仅仅是网络传输耗时。2020-10-11- Geek_circle老师好
有个现象帮忙看下如何分析定位下
centos7.2 长连接redis ，应用日志会显示无规律的出现hmget 间歇性超过200ms，最长达6s返回的情况，持续几分钟后恢复。后续要求定位，
主服务器不可中断， 不准部署抓包，安装bcc 感觉工具又可能消耗资源。排除了中间网络监控的问题 ，redis服务端也未发现超时的记录，怀疑系统层面的，是否有什么思路或者工具手段监控定位呢？作者回复: 如果redis服务端未发生超时的情况，大概率是数据包阻塞在内核缓冲区太久导致的，也就是说数据包到达了内核缓冲区，但是redis没有及时读取它。没有及时读取的原因可能为：
1. 软中断打断redis
2. redis调度延迟
也可能会有其他原因。
排查思路也有的。这类问题我会有ftrace的kprobe_events机制来排查。比如追踪下面几个内核函数：
- tcp_rcv_established ： 数据包到达内核缓冲区
- tcp_recvmsg： 数据包被应用读取
这两个时间戳相减就是数据包在内核缓冲区停留的时间。2020-09-29 1 
王崧霁不可以，tcp有重传作者回复: 嗯 是的
2020-09-24
feihui课后思考题：1. 可以但不精确，涉及时间同步；2.不行，RTT包含服务器处理时间作者回复: 对的！
2020-09-20
我来也老师公司也在用CentOS7啊。
不知道有没有遇到过7.6版本的3.10.0.957内核bug，导致tcp的Send-Q居高不下的问题，哈哈。作者回复: 主要是centos7，也有centos6和8，还有一些是Ubuntu。
这个问题倒没有遇到过。2020-09-19- 我来也思考题2
RTT 是否可以作为这次网络耗时？
好像不行吧。
看图好像是可以，毕竟就是tcp的一去一回。
但是这个还取决于对方返回ACK时是否及时。
有时ack是会合并的。有些内核参数好像还会延迟ack的返回时机吧。作者回复: 对的 rtt时间不仅仅包含网络时间 还有内核软中断处理时间 另外还存在delayed ack
2020-09-19 - 我来也思考题1
我觉得tcp流到B点的时间减出A点的时间做网络延迟 不合适。
主要原因是两边的时间不统一。
有可能客户端的时间比服务端的快。
只有选取相同的时间基点，算出的差值才有意义。
另外，因为TCP流会有很多Segment，可能一次请求就包含多个Segment，取哪一个或平均值，都不好实现。
而取同一个节点的时间，可以取最后一个发出去的报文和第一个发出去的报文来计算真实的时间。
毕竟数据只接收了一半，也是无法开始执行逻辑的。作者回复: 是的！回答的很好。
2020-09-19 
0xFErtt统计的是tcp协议栈发出到收到的时间，包括客户端自身协议栈到发出网卡，网络传输，对方网卡接收并发到服务端协议栈，再经过返回流程到客户端协议栈的时间，rtt延时不能具体区分是哪个部分的问题。作者回复: 是的 另外还存在delayed ack这种情况。
2020-09-19- 0xFE1.请问作者公司线上机器都装了systemtap吗？
2.这个systemtap脚本和模块以后会开源吗？作者回复: 1. 部分线上机器装了systemtap，特别是centos7的系统上；在centos8的系统上，我们一般是使用ebpf，比如bcc或者boftrace。
2. 目前还没有开源计划，但是该模块的一些思想以及一些关键的tracepont我在这个系列课程里都讲到了 如果你看到仔细的话你会找到，利用这些tracepoint你也可以实现类似的模块。2020-09-19
收起评论