27丨案例：带宽消耗以及Swap（上）
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文通过一个真实案例，介绍了性能问题的分析过程。作者首先强调了性能问题分析需要遵循一定的思路，包括画架构图、描述场景、定位瓶颈等步骤。通过对应用服务器、数据库服务器和压力数据的分析，最终定位到带宽问题导致了性能瓶颈。在分析过程中，作者提到了监控工具的使用、网络带宽的判断、队列堆积等技术细节，展现了对性能问题的深入分析和解决思路。文章内容丰富，技术性强，适合需要了解性能问题分析思路的读者阅读。 在优化结果方面，通过过滤静态资源后再次执行场景，得出了应用服务器带宽、数据库服务器带宽、网络队列和资源监控等数据。这些数据显示了性能的改善，但也出现了Swap问题，为下一篇文章的分析留下了悬念。 总结部分强调了带宽问题在性能分析中的重要性，以及网络瓶颈的判断需要考虑多个因素，如队列长度、网络抖动、丢包、延时等。同时，Swap问题的解决关键在于明白其原理和关联参数。作者提出了思考题，引导读者思考网络瓶颈的判断方法。 整体而言，本文深入剖析了性能问题的分析过程，展现了对技术细节的关注和解决问题的思路，适合对性能问题感兴趣的读者阅读。
《性能测试实战 30 讲》，新⼈⾸单¥59
全部留言(22)
- 最新
- 精选
土耳其小土豆高老师，网络队列的截图的具体命令能告知以下嘛？我想打印跟你那一样的作者回复: netstat -naop就可以。
2020-07-0114- Geek_9e9d56高老师，应用和数据库服务器带宽截图的具体命令能否告知一下？谢谢
作者回复: 我最常用的就是iftop。
2021-11-235 
Geek_Jean高老师，谢谢您给大家分享这么多的干货，真的受益非浅，但看完这讲后，我有3个问题没明白： 1. 我有这样一个认知：服务端Send-Q如果有积压，那实时查看网络带宽的时候服务端的发送量和客户端的接收量不会对等。这个认知对吗？ 如果上面说的是对的，那我又有一个新问题： 服务端网络资源接收 900KB/s 左右，发送 11M 左右；然后通过查看压力机上的网络接收流量可以看到是93Mbps，换算之后也就是11M左右, 这么看服务端的发送量和客户端的接收量是一样的，带宽是对得上的。依据这样的推断服务端的Send-Q应该不会有积压才对。这个怎么理解呢？ 如果上面的认知不对：那我有另外一个新问题： 实时查看服务端的时候Send-Q都有积压了，那说明这些数据还没有到达客户端，那客户端的接收量就不会接近服务端的发送量了。但实际上他们都是93Mbps.这是怎么回事呢？作者回复: 有积压时，发送方和接收方的值确实不会对等，但这个偏差很小，你可以查看一下发送方的发送缓冲区大小和内核限制的写缓冲区最大值、以及接收方的接收缓冲区大小和内核限制的读缓冲区大小。 如果你可以在两边抓到同一时刻（记住是同一时刻）的网络带宽，那就会看到区别。 不过我觉得你不用纠结这一点。因为这个队列要长期有值才说明阻塞严重，偶尔有值或间歇性有值是不用关心的。
2021-09-024- Geek_237b86老师swapping标黄的是什么工具？
作者回复: spotlight。
2020-03-314 
糯糯老师 有个问题，如果说要找到系统上限，是找到系统瓶颈呢，还是尽可能的压测至服务器资源沾满呢作者回复: 瓶颈是上限的绊脚石，得先解决，再把资源占满才有意义。
2021-04-303- bettynie高老师，我们做内网测试时采用直连的方式，是不是可以更好的避免内网的网络问题，只考虑网卡的限制，这样可以把精力放在程序本身，先找出比较严重的性能问题再来考虑网络影响？
作者回复: 如果有必要的话，可以这样做。只是在内网中，网络设备的背板吞吐都是很大的。你的应用有这么大的流量吗？
2020-04-133 
大拇哥1）查看服务器发包数量，客户端接口数据包的量是不基本一致，如果出现明显的差别，可以基本确定客户端网络问题 2）查看jmeter聚会报告上面客户端接口数据量是否已经接近宽带的限制 队列： 服务端消息发送队列 客户端接收数据的队列 服务端超时队列作者回复: 1，当网络有问题的时候，主要看队列，不用再对比流量了，因为已经没有意义了。 2，对。
2020-02-212- Geek_a8d2eb压测时在应用服务上执行命令netstat -naop，发现Recv-Q和send-Q都有间歇性的非0状态，5秒内就恢复0了。网上搜说可接受短暂的非0情况，短暂的Send-Q队列发送pakets非0是正常状态。请问这种说法靠谱么，观察tps和响应曲线也会出现相应的锯齿状
作者回复: 短暂的非0确实是可能接受的。如果tps和响应时间跟网络队列相关，这就要有证据才可以了。那你需要的是拆分响应时间，看有没有在网络上消耗。
2021-02-271 
😂老师，如何判断带宽不够呀？1.服务器接受和发送的流量接近或超过带宽，说明带宽不够？2.压力机接受和发送的流量接近或变过带宽，说明带宽不够？作者回复: 看队列。
2020-12-0821- nelson文稿中提及“综上现象就是，单业务场景执行起来并不慢，但是一混合起来就很慢，应用服务器和数据库服务器的系统资源使用率并不高。请问慢在哪？” 经过一系列分析，没有给出单业务为什么不慢，如果是带宽问题，单业务也一定会慢
作者回复: 这里提的单业务不慢，是因为对于同样的带宽来说，单业务的TPS是没有业务限定的。而混合场景中会有业务目标限定。
2020-05-111
