现象
- 贵司反馈公众号点击一些页面会特别卡，很慢
- 笔者下过APP体验，下拉菜单提示： 网络请求超时，请稍后再试
分析
-
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瓶颈，毕竟一台服务器上跑了太多的服务。就好像排队接水，分发杯子能很快处理，但是接水的人太多，又只有一个水龙头，所以流出的水有限，满足不了现有的服务。
解决
- 更换代码架构，分清楚到哪些数据是写磁盘，哪些是读磁盘，写也要分批逐次写入，而不是每次都将上次已写的缓存再次写入。
- 将应用服务跟MySQL、redis等数据库分离，降低单块磁盘的IO压力
网友评论