爱你定服务器性能瓶颈分析报告

2020-07-15 本文已影响0人 ArthurIsUsed

现象

分析

vmstat 显示CPU、内存都很正常，si/so都为零，且free还有6G可用，CPU空闲99%。由此可知，CPU、内存不存在瓶颈
iostat -x -m 5 10查看，此时能正常访问
- svctm，平均服务时长很低，但是wait这一栏数值比较高。大致来说一万转的机械硬盘是8.38毫秒，包括寻道时间、旋转延迟、传输时间。鉴于这是云主机、云磁盘，应该在5ms以下才正常。
- w_wait，写等待高的时候几十，上百。*_wait小于5ms是正常的，高于10ms都是表明系统存在问题。
- 综合这数据表明，写队列很长，都在排队，等着把CPU处理完的数据写入磁盘，但是需要写的太多了，w_wait时间达到20ms，甚至100多到200.
- 从iostat的数据返回可知，开始很正常，突然w_wait增加到几十、一两百，然后又降到小于5。

总结

由于多个程序都等待写入磁盘后，CPU返回结果给client端，但是w_wait高，让用户感觉到访问页面卡顿，或者慢，甚至请求不到数据，提示：网络请求超时，请稍后再试。（APP下拉菜单会报这个错）
只有一个公众号、一个APP，是提供服务的，是w_wait(写等待时间长)高，client端从server端读数据，就算wait高也是r_wait高。而且，一会突然高到一两百，猜测后端代码是把某些处理结果写入到缓存，然后再定期写入磁盘，但是写入磁盘后缓存不会清空，再次写磁盘又包含以前的数据，因此每次写入磁盘都造成巨大的IO压力（w_wait数值高）。这也验证了重启后端程序服务会好一些的情况。
结合现有服务的情况，
- 问题点1：此服务器CPU8核，内存16G，足够。但是有5个tomcat、dubbo、maven、 nexus、MySQL、redis都在跑，而且只有一块磁盘，所以存在IO瓶颈。
- 问题点2：后端程序架构有问题，提供服务的，wait高理应是r_wait高，而不是w_wait高，需要优化。但不能保证代码优化后不存在IO瓶颈，毕竟一台服务器上跑了太多的服务。就好像排队接水，分发杯子能很快处理，但是接水的人太多，又只有一个水龙头，所以流出的水有限，满足不了现有的服务。

解决