29丨案例：如何应对因网络参数导致的TPS呈锯齿状？

感觉学到了什么，又感觉好像都不懂，看完估计前面的也忘了差不多了。这真是要不断时间和经验的积累，总结方法。但是一点记住的就是全局--定向

读完老师的文章，有下面几点疑惑 1. TCP 四次挥手中，主动断开链接的一方才会处于 TIME_WAIT 状态呢，老师在文中有说 客户端主动断开，服务端也会出现 TIME_WAIT 状态，这是什么情况呢？ 2. nf_conntrack 模块对 TCP 链接进行追踪，然后 nf_conntrack 的表有限制，表满了就丢包，这个因导致了服务器出现大量的 TIME_WAIT 状态，但为什么反应到 TPS 是锯齿状呢？一会儿好，一会儿坏，就算是 nf_conntrack 表会释放，难道还会瞬时释放很多，这样 TPS 就上去了，然后又满了，TPS 又下降？ 思考题 1.如何在分析一通后，最后定位到防火墙？ 因为老师在经过对操作系统的 CPU、I\O、内存等资源还有数据库、Tomcat、Nginx 等监控数据没有发现什么问题，最后定位到网络连接状态有问题，即出现了大量的 timewait 状态的链接，然后老师想通过修改 TCP 相关的参数来达到复用处于 timewait 状态的链接（这些参数的本质是释放服务端的句柄和内存资源，但不能释放端口，而 源IP+源端口+目的IP+目的端口+协议号才是 TCP 五元组），修改完后没有解决问题 然后老师分析客户端主动断开时，服务端也会处于 timewait 状态（这块是我疑惑的，应该是主动断开链接的一方才会处于 timewait 状态），然后打开了 Nginx 的 proxy_ignore_client_abort 配置，即让 Nginx 忽略掉客户端主动断开时报的错，但问题还是没有解决，然后把 Nginx 和 Nginx 所在服务器也换了，问题没有解决。 开始考虑操作系统层面，网络收发数据那儿可以通过查看发送端和接收端的 Recv_Q 和 Send_Q 这四个队列是否有值，来判断瓶颈点，然后没有发现问题。 在最后才考虑防火墙了 2.为什么 timewait 的 TCP 链接只是问题的现象？ 因为能引起链接处于 timewait 状态的原因还是有很多的，这就需要不断透过现象看本质，根据不断地排查锁定最根本的原因

 既然跟加入的nginx没有关系，那么第一次性能测的时候为啥没有发现有这种性能问题呢？

现象： * 测试环境压测曲线正常，线上环境曲线杂乱 * “TPS 在上升到一个量级的时候就会掉下来，然后再上到同样的量级再掉下来，非常规律” * “响应时间，在第一次 TPS 掉下来之后，就变得乱七八糟了。响应时间不仅上升了，而且抖动也很明显” 检查过程： 1. 问题检查 * 看操作系统CPU/io/memory/net * 看数据库、tomcat/nginx 2. 第1阶段结论： 网络连接有问题 * 发现了大量timewait 3. 尝试优化 * timewait是发起断开后的一个状态，修改服务端TCP相关配置 1. timewait资源允许重用+快速回收 等 * 修改nginx，只做转发，去除其它逻辑 * 将nginx部署到另一台服务器上 * 上述都没发现问题===》防火墙还没看 * 关闭防火墙，服务TPS正常 4. 第2阶段结论：瓶颈在防火墙 5. 问题分析 * dmesg 查下系统日志 * 发现 nf_conntrack 数据满了 * 查文档，知道其是干什么的；怎么改 * 修改配置，重新打开防火墙==》服务正常 6. 结束：瓶颈处理完成

老师，linux tcp连接的限制(最大不能超过65535) ，对吗？ 既然nf-conntrack默认也是65535 对最大tcp连接对应的？ 这边没有看到 系统究竟建立了多少tcp连接，如果是超过65535个，那么丢包是合理的吧？

想起了自己以前处理iptables限制tcp syn次数的性能调优，

说TIME_WAIT是现象，是因为它只是“果”，导致它的“因”有很多可能，就是本课里老师采取的多种尝试。 当然，从分析链路的角度来说，它是TPS不稳的一个中间“因”，但还不能作为全局——定向分析的最终定位，所以是“现象。”

分析思路很重要，还有分析问题的时候不要着急

如果用1.5个月做性能测试，那就不要做了，1.5个月一个全新的产品可以上线了，预期线下费时，从投入产出比看，不如灰度放量，让实际场景暴露问题

看不大明白只感觉nb，要学习的太多了