plantegg
·
实战瓶颈定位-我的MySQL为什么压不上去
💡
原文中文，约23900字，阅读约需57分钟。
📝
内容提要
本文测试了在两台云上相同128C的EC2上使用Sysbench测试MySQL纯读场景的结果，发现瓶颈点在sysbench和MySQLD的网卡之间的链路上，似乎有限流、管控。通过验证，发现走本机127.0.0.1时MySQL跑满了CPU，证明瓶颈不在MySQL上。同时，还介绍了请求RT分布不符合正态分布的问题，并进行了其他网络业务验证。最后，进行了限速和拥塞算法的相关实验。
🎯
关键要点
- 测试在两台相同的EC2上使用Sysbench测试MySQL纯读场景，发现瓶颈在sysbench和MySQLD的网卡之间。
- 通过本机127.0.0.1测试，MySQL跑满CPU，证明瓶颈不在MySQL上。
- 请求RT分布不符合正态分布，进行了其他网络业务验证。
- 在压测过程中，1000并发和2000并发的RT没有显著变化，表明链路上存在瓶颈。
- 抓包分析确认瓶颈在sysbench和MySQLD的网卡之间，推测有限流和管控。
- 使用tcpperf测试不同拥塞算法的效果，发现限速条件影响了性能。
- 去掉限速后，1000并发压力下QPS达到30万，RT与无压力时相似。
- 总结了抓包分析的重要性，强调RT是评估性能的关键指标。
- 在纯写场景中，发现单线程CPU使用率高，导致整体性能下降，进一步分析磁盘IO情况。
- 通过对比正常环境和问题环境的IO TPS，发现问题源于sysbench脚本的修改。
➡️
