一次系统高LOAD优化之经验

现象

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

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

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


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


指标

屏幕快照 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。


sudo /opt/taobao/java/bin/jstack -F 1908 > stack.log


屏幕快照 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,说明优化还是有一定的效果的。但是,同时发现,优化不明显,说明还有其他原因,还需要进一步排查是否有其他系统未知问题。


思考

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

发布了349 篇原创文章 · 获赞 26 · 访问量 55万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览