一次系统高LOAD优化之经验

现象

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

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

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

指标

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

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

分析

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

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

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

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

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

优化

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

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

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

结果

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

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

思考

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