系统性能调优必知必会期中

你好，我是陶辉。

时间过得真快，从4月27日课程上线，转眼已经一月有余了，不知道你的收获如何呢？在这期间，我收到了很多同学的反馈，很感谢大家的认可，也非常开心能与你一起交流技术。

那从我个人而言呢，这已经是我在极客时间开的第三门课了，前两门都是视频课。那切换到文字专栏的话，其实是完全不同的感受，视频课可以通过演示把问题讲清楚；而文字专栏则要反复打磨内容，并且和写书的方式还不一样，从每节课的内容设计、讲述方式到大纲以及具体细节的编辑，真真是掉了不少头发。

目前专栏已经更新一半了，前两个模块我们已经学完了，包括单主机如何提升性能，以及到了瓶颈后开始使用网络编程会出现的一些问题，第三模块我们也接触了一点点。学到这里，相信你应该感觉到了，系统性能问题的涉及面就是很广很深，往往需要在多个环境中反复验证分析才可以。那每清楚一个问题，你的实力其实就会有一定的沉淀，直到跳跃式的进步。

这其实也是我本人在学习性能优化过程中一个很深的体会，即问题驱动。特别是我在腾讯、阿里时，不断增长的业务流量导致系统需要持续地进行优化和扩容，再然后就自然地进行系统化总结，我那时候就发现大学里的《数据结构》课白学了，所以我又重头开始学习《算法导论》，然后发现《网络原理》课白学了，又开始学习《TCP/IP协议详解》，等等（当然，这里不是为了吐槽，而是想告诉你，学习时选对教材真的很重要）。这就是一个螺旋上升的过程。

所以，阶段性的验证和总结其实还是非常重要的，这里我特别设置了这场期中考试，精选了20个问题，知识范围就是咱们专栏的1～15课，希望你能认真完成，发现问题及时解决。

这里特别说明一下：我们的期中考试为期一周，从6月3日开始到6月9日结束，这期间我们会暂停更新正文内容，也就是说我们会从6月10日开始更新第16课。你可以好好利用这一周的时间，去回顾一下前15课的知识，做一个巩固。另外，在这一周中，我还会提供两篇加餐给你，一篇是福利加餐，我会从我的视频课中精选出3节和本专栏具有强关联的课程送给你；另一篇是答疑精选，期待你能借由大家的问题和增量信息，去引发更多的思考。

有标准才有追求，有追求才有动力，有动力才有进步，真心希望性能优化能成为你职业生涯的重武器。最后，来挑战一下吧，开启你的期中考试之旅。

 

 

你好，我是陶辉。

不知道你的期中考试成绩如何呢？是否发现了一些新的问题？成绩好的同学请继续努力了，咱们还有一半的课程未学，希望你能一如既往地跟着我深挖系统性能，这门课的内容设计是由浅入深的，第三、四模块会重点往集群方向转了，内容相对会更加烧脑。成绩略差的同学也不要气馁，就像我上节课说的，问题驱动是一种很好的学习方式，查漏补缺才是这场期中考试的目的。

聊完考试，我就来兑现承诺了，精选3节我的视频课作为福利送给你，它们来自《Web协议详解与抓包实战》，这3节课都是与咱们专栏有强关联的。

我还记得在开篇词中有位同学问我，学习咱们专栏需要哪些基础？我是这么回复的：

1. 对操作系统的原理有简单的了解，比如，文件是怎么读取的，HTTP请求是怎么发送和接收的；
2. 对网络协议要有所了解，毕竟分布式系统就是靠网络将操作系统上的进程连接在一起。这块《Web协议详解与抓包实战》可以先学下。
3. 大致知道什么是分布式系统，这块网上的文章有很多。

其中第1点和第3点，我想还是很容易的，所以我就在第2点上为你加码了。以下就是3节视频课，你可以直接点击观看。

第1节

与第7课有联系的《Web协议详解与抓包实战》第117课。我在第7课讲解组播时，有推荐你如果想要进一步了解组播的细节，可以观看以下视频课。

第2节

与第14课有联系的《Web协议详解与抓包实战》第51课。我在第14课讲解用 Chrome 浏览器配合 Wireshark 解密消息，可以帮助你分析 TLS 协议的细节时，具体的操作方法有推荐你观看以下视频课。

第3节

与第15课有联系的《Web协议详解与抓包实战》第9课。第15课我们介绍了 Chrome 浏览器开发者工具的 Network 面板，通过它可以快速判断各站点使用了哪些HTTP性能优化技术，有关 Network 面板的详细用法，我推荐你观看以下视频课。

今天的特别福利就到这里，这3节视频课对于你学习咱们专栏有一定的辅助作用，希望你能把它作为拓展认真学完。如果你有更多想要了解的内容和期待的学习资料，欢迎在留言区中提出。

 

 

 

 上一讲：期中考试｜行至半程，你的收获如何呢？

 

 

你好，我是陶辉。今天是期中周的第2篇加餐，按照约定，这节课我从1～15课的留言区精选出了15个问题，这里一部分是与内容强相关的，还有一部分是属于拓展型的问题，选择标准就是是否存在增量信息以及问题价值，希望你能从别人的疑问中进行一次自检，引发更多的思考。

第1课

鲤鲤鱼：我们集群有一个问题，某一台物理机的CPU会被Hadoop yarn的查询任务打满，并且占用最多的pid在不停的变化，我查看了TIME_WAIT的个数好像也不是很多，在顶峰的时候还没达到一万，能够持续一两个小时。这个问题您有没有什么思路呢？

作者：解决性能问题，一般有两种方法：经验派和“理论”派。前者就是基于自己的经验概率，将能想到的优化方法都试一遍，这种方式通常又有效又快速，但无法解决复杂的问题。而所谓理论派，就是沿着固定的思路，使用二分法，从高至低慢慢下沉到细节。

具体到你的问题，我建议你先看看，CPU占用的是用户态还是系统态，用户态的话就要分析代码了，系统态还要进一步分析。火焰图通常是个很好的办法，虽然搭能画火焰图的环境很麻烦，但这种底层方法很有效（第19课会具体讲到火焰图的用法）。

第2课

alan：老师好，这节课真好，第一次了解到内存池也是有层次的。我遇到一个问题想请教一下：我有一个和数据库交互的Groovy程序，运行起来后会占用很大内存，启动时，将Xmx设置为多少，该程序的内存占用就不会超过Xmx指定的上限。比如，Xmx=10g，程序就稳定占10g内存，但如果不限制的话，最高见过占用30G左右。这个您觉得有什么可能的原因吗？

作者：每种Java虚拟机都有自己独特的垃圾回收机制，有时为了时间更快就会牺牲更多的内存空间，这是正常的。我建议在服务器上长时间运行的Java进程，一定要通过Xmx去明确内存占用，否则内存不可控会很麻烦。

第3课

杨文宇：链表的内存地址不连续是如何影响序列化的？老师能具体说一下吗？

作者：当数组外还有链表中的元素时，序列化就必须遍历所有元素，比如，至少要做1次循环，把每1个遍历到的元素的值，序列化写入至另一段内存中。而使用闭散列时，可以直接将这个数组占用的内存作为序列化后的数据来直接落地或使用。

第4课

helloworld：“第二，读取磁盘数据时，需要先找到数据所在的位置，对于机械磁盘来说，就是旋转磁头到数据所在的扇区，再开始顺序读取数据。其中，旋转磁头耗时很长，为了降低它的影响，PageCache 使用了预读功能。”那是不是使用SSD这类固态硬盘（不用旋转磁头），PageCache就没有很大的影响？

作者：对的！其实，当下的操作系统对SSD磁盘的支持还不够，当SSD广泛应用时，文件系统还需要跟上，得获得很大的性能提升才可以。

第5课

Robust：“然而，共享地址空间虽然可以方便地共享对象，但这也导致一个问题，那就是任何一个线程出错时，进程中的所有线程会跟着一起崩溃。”这里的出错应该表示一些特殊的错误吧，或者是说和共享内存有关的错误，比如申请不到内存等。老师，我理解得没错吧？

作者：这里指无法恢复的错误，不仅是内存申请错误，比如访问已经释放的资源，且没有捕获异常或者无法捕获异常，进而操作系统只能杀死线程时，进程里的其它线程也会被杀死。

第6课

范闲：用户态的协程不能用互斥或者自旋，会进入内核态与其设计初衷相悖，Python里面用的yield。

作者：是的，用户态协程需要用户态的代码将锁重新实现一遍，其中实现时不能用到内核提供的系统调用。

第7课

重返归途：广播功能属于双工吗？当多个客户机向主机响应时，会有性能瓶颈吗？

作者：广播不是双工，因为广播是由网络设备实现的，所以服务器无法感知到每个客户端的响应，因此客户端对服务器的响应，与本次广播消息链路无关，它必须是另一个通道。

第8课

龙龙：“因此，哪怕有 1 千万并发连接，也能保证 1 万 RPS 的处理能力，这就是 epoll 能在 C10M 下实现高吞吐量的原因。”老师，这段话我不太理解，1千万的并发连接，只有1万的RPS这能算高吞吐量吗？相当于每秒只有1000个人中的1个人得到响应。还是我理解错了，您表述的是另一层意思？

作者：这里有2层意思，都是服务于epoll的设计思想这一个目的。

1. 这段话的上下文，是指单次获取网络事件时，你可以理解为调用epoll_wait系统调用，它的速度与并发连接总数无关，相对于之前的select/poll系统调用（它们都与并发连接总数相关），因此epoll_wait速度很快，这是实现高吞吐量的关键。
2. 有些应用会长时间保持TCP长连接，但并没有消息通讯（比如GPS等IoT设备与服务器之间的通讯），此时1千万并发连接下，如果能够维持1万RPS，这也是只有epoll才能做到的，poll/select是不可能做到的。

第9课

Geek_007：看评论区，很多同学都说是长连接，普通的HTTP keep-alive会不会有坑，三大运营商或者中间网络设备都会将超过一定时间的链接drop掉。如果没有H2这种ping保活的机制，有可能客户端长链接莫名其妙的就被drop掉，客户端只能依赖超时来感知异常，反倒是影响性能了。

作者：是的，不只网络设备，一些代理服务器为了减轻自己的负担，也会把长连接断掉，比如Nginx默认关闭75秒没有数据交互的keep-alive长连接。

第10课

安排：TTL每一跳减少1，这些怎么和MSL对应起来呢？每一跳减少的1相当于1秒？

作者：不是，这是一个预估值，所谓每一跳，是指每经过一个路由器网络设备，将IP头部中的TTL字段减少1，并不等于1秒，通常推荐的TTL的初始值是64。

第11课

Trident：带宽时延积如何衡量呢？网络时延不是固定的，是要多次取样计算平均网络时延，然后估算出这个时延积吗？

作者：是的，需要多次取样做估算，再乘以带宽，得到带宽时延积。

第12课

妥协：为什么报文5之后的ack都是ack6呀？

作者：TCP是有序的字符流，因此接收方收完报文5后，只能接收报文6，但现在却接收到了报文7、8、9、10，此时接收方该怎么办呢？

当然，它可以当做不知道，什么也不做，坐等报文6的到来。报文6什么时候会到呢？RTO时间超时后，发送方会重发报文6，因为发送方一直没收到ACK7！但是，RTO是很长的时间，接收方直接反复地传递ACK6，这样发送方就能明白，报文6丢了，它可以提前重发报文6。这叫做快速重传！

第13课

有铭：“寻找宕机服务时，只要看队列首部最老的心跳包，距现在是否超过 5 秒，如果超过 5 秒就认定宕机。”这里的逻辑无法理解。如果要用这种方式检测心跳，那么肯定要不停地把队列首部的心跳包移除，让新的心跳包从尾部加入，那么如果这个加入的过程卡一点，岂不是就会误判？

作者：这种设计下，还必须限制每次移除心跳包的数量（分多次执行），以防止加入过程长时间得不到执行。而且，在这种极限场景下，必须监控CPU的使用率，如果长期维持在高占用率（可能你的集群规模已经超大，要每秒处理数百万心跳包），那么应当通过扩容更多的CPU核、分布式系统等其它方案来解决，这已经不是单台机器能解决的了。

第14课

东郭：请问老师，我在Nginx配置中，不管ssl_certificate和ssl_certificate_key是否配置ecc证书，抓包查看服务器的server hello响应中的Cipher Suite字段都是TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256，这是正常的吗？

作者：这是正常的，TLS握手阶段Nginx的Cipher Suite，要通过ssl_ciphers指令来配合支持的suites，并可通过ssl_prefer_server_ciphers指定优先选用的算法。证书只是包含了密钥、身份等信息，它们与密钥协商方式、对称加密算法并无关系。

第15课

Geek_007：FB也搞了一套压缩算法ZSTD，对比起来也比gzip性能强很多，不清楚这些压缩算法的原理是啥？怎么对比？另外普通的JSON和PB有不同适合的压缩算法吗？怎么比较呢？

作者：

1. 压缩算法的原理都是基于香农的信息论，将高频出现的信息用更少的比特编码。虽然原理是一致的，但实现上却有很大的差别，比如Huffman通过建立Huffman树来生成编码，而LZ77却是通过滑动窗口，这就造成了压缩比、压缩速度都很不相同。

2. 比较它们的优劣，主要看3个指标：

• 压缩比，比如Brotli的压缩比好于ZSTD；
• 压缩与解压的速度，比如ZSTD比gzip速度快；
• 浏览器等中间件的支持程度，现在几乎所有浏览器都支持Brotli（即br），但ZSTD少有支持。

3. 普通的JSON和PB没有最适合的算法，还是要针对具体场景，比较方法参见我刚刚说的那3个指标。

今天的答疑精选就到这里，期待大家能一如既往的在留言区进行交流，如果有更多问题，也欢迎一并提出。