一次系统高LOAD优化之经验-阿里云开发者社区

开发者社区> 开发与运维> 正文

一次系统高LOAD优化之经验

简介:


现象


某个应用,机器数增加到了150台,但是发现其load较高。


屏幕快照 2020-03-24 上午9.18.29.png


对于4核机器来说,负载率高峰期超过4,意味着高峰期几乎满载,这是一个不正常的现象。




<div class="lake-codeblock-content" style="border: 1px solid rgb(232, 232, 232); max-width: 750px; color: rgb(89, 89, 89); margin: 0px; padding: 0px; background: rgb(249, 249, 249);">
  <div class="" style="color: rgb(89, 89, 89); margin: 0px; padding: 16px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);"><pre class="cm-s-default" style="color: rgb(89, 89, 89); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);"><span class="lake-preview-line" style="color: rgb(89, 89, 89); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);"><span class="lake-preview-line-number lake-lm-pad-level-0" style="color: rgb(191, 191, 191); margin: 0px 8px 0px 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);"></span><span class="lake-preview-codeblock-content" style="color: rgb(89, 89, 89); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);">经验法则如下:

当系统负荷持续大于0.7,你必须开始调查了,问题出在哪里,防止情况恶化;
当系统负荷持续大于1.0,你必须动手寻找解决办法,把这个值降下来;
当系统负荷达到5.0,就表明你的系统有很严重的问题,长时间没有响应或者接近死机了。

  </div>
</div>




指标


屏幕快照 2020-03-24 上午9.20.40.png




首先确认系统无FullGC、Java线程符合预期。




屏幕快照 2020-03-24 上午9.21.55.png


查看CPU,CPU一直运行在较高的峰值。当然对于4核CPU来说,这个比例就不算太高。




分析


那么我们分析出来了比较明显的结论,CPU运行低和LOAD较高,则表示等待IO的进程比较多。我们进一步定位问题,我们DUMP线程,看看线程在等待什么了,为什么会导致如此高的IO。




<div class="lake-codeblock-content" style="border: 1px solid rgb(232, 232, 232); max-width: 750px; color: rgb(89, 89, 89); margin: 0px; padding: 0px; background: rgb(249, 249, 249);">
  <div class="" style="color: rgb(89, 89, 89); margin: 0px; padding: 16px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);"><pre class="cm-s-default" style="color: rgb(89, 89, 89); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);"><span class="lake-preview-line" style="color: rgb(89, 89, 89); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);"><span class="lake-preview-line-number lake-lm-pad-level-0" style="color: rgb(191, 191, 191); margin: 0px 8px 0px 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);"></span><span class="lake-preview-codeblock-content" style="color: rgb(89, 89, 89); margin: 0px; padding: 0px; background: none 0% 0% / auto repeat scroll padding-box border-box rgba(0, 0, 0, 0);">sudo /opt/taobao/java/bin/jstack -F 1908 &gt; stack.log</span></span></pre>
  </div>
</div>




屏幕快照 2020-03-24 上午10.02.10.png




经过统计,发现大量的线程都BLOCKED在红色的代码代码内,那么这段代码到底是做了什么,为什么会BLOCK大量的请求。




继续使用线程诊断,发现大量的线程都在等待状态,其中等待的代码段是logback的日志打印。


屏幕快照 2020-03-24 上午10.24.50.png




根据业务情况,我们就得到了结论,即本系统有大量线程的相同代码块同步打印同一个日志,导致加锁并行处理,进而导致多个没有取到锁的线程在等待上个线上打印日志释放资源。




优化


很简单的一个办法,就是利用Logback的异步打印日志,可以参考文档:


https://examples.javacodegeeks.com/enterprise-java/logback/logback-ayncappender-example/




核心原理是同步打印日志是直接对文件同步操作,而异步打印日志原理就是打印日志写将日志写到队列,然后将队列异步写到文件里去。




结果


优化后,发布线上观察机器的LOAD情况如下:


屏幕快照 2020-03-24 下午5.38.44.png




可以看到,发布优化后的LOAD已经小于昨日的同比LOAD,说明优化还是有一定的效果的。但是,同时发现,优化不明显,说明还有其他原因,还需要进一步排查是否有其他系统未知问题。




思考


系统调优是难度非常大的一个课题,也是需要具备非常深的基础底层知识,才能更快的定位和分析以及解决问题。


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章