Java应用性能调优套路

  • 一切优化要基于确切的报告,而不是靠猜。
  • 我们只有通过压力测试才能知道程序性能几何。

压测前准备

我们应对单台应用服务器做压力测试,你只有知道了单台能够承受多少才能知道集群能承受多少。

然后要确定单台应用服务器性能目标:

  • 吞吐量,每秒处理多少请求
  • 延迟,平均、P50、P90、P99的请求在多少时间内完成

如果客户要求吞吐量为2000rps,能提供2台服务器,那么每台的吞吐量则为1000rps。

如果客户要求延迟P99 <= 2秒,那么和服务器就没有关系了,你需要优化程序算法。

压测时的观察和调优

下面我们对单台应用服务器开始压力测试。

保证CPU用满

压测期间我们首先要保证的是CPU利用率接近N * 100%(N为CPU核心数),如果CPU利用率不满那么压测报告就没有意义,因为机器并未全力运转。

发现CPU没有用满,那么有这么几种可能

  • 压力太小,可以调整压测工具来做到
  • 线程阻塞,后面会讲

保证CPU花在非GC上

好了现在CPU用满了,那么我们要通过jstat -gcutil来观察JVM是否把CPU花在了GC上,你也可以添加-XX:+PrintGC -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:/path/to/gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=1 -XX:GCLogFileSize=20M JVM参数得到更详细的GC日志。

重点关注Full GC的次数和占用时间,如果发现Full GC很频繁,有三个解决思路:

  • 增加内存
  • 优化算法,降低内存利用率,可以通过jmap导出内存dump,再使用MAT分析
  • 降低压力,可以是降低压测工具侧的压力,也可以是调小程序自身线程池

解决阻塞

用jstack导出thread dump来分析。

线程阻塞是常见的CPU利用率不满的元凶,因为阻塞时不占用CPU,你可以在压测期间用jstack收集几次堆栈数据,然后观察里面的BLOCKED、WAITING、TIMED_WAITING状态的线程的堆栈,找到线索。

如果发现阻塞不可避免,那么可以通过增加线程数的方式来利用CPU。

如果阻塞发生在连接池相关,那么调整连接池大小。如果阻塞发生在执行SQL有关,那么优化SQL语句。如果阻塞发生在其他地方,那么做针对性优化。

观察慢SQL

慢SQL是常见阻塞原因,找出这些慢SQL,对它进行优化,或者对数据库表做优化,提升程序响应速度,提高CPU利用率。

观察执行次数异常的SQL

执行次数异常的SQL也是很重要的一点,抓住这些SQL,对代码进行优化。

数据库连接池

连接池不够也是常见的阻塞元凶,线程在等待连接池导致CPU利用率上不去,不过还是那句话,不要盲目调整,你应该在jstack里看到大量获取jdbc connection的阻塞线程之后才去调整它。

线程池

按照理论上来说,如果线程不阻塞,那么只需要N个线程就能把CPU占满(N是CPU核心数)。线程阻塞占用比例越大,就需要越多线程来占用空闲CPU时间。

如果你优化之后把阻塞比例降低了,那么你也需要相应调小线程池尺寸。

过多的线程池不会带来更多好处,白白占用内存而已。

服务器异常日志

有时候服务器异常日志也会提供给你很好的线索,记得观察。特别是如果异常特别多的话,会直接影响性能的。

观察、优化、验证的循环

当你做了一个优化点后,你再压一遍,看看是否有改善,同时需要调整其他相关参数,比如前面提到的调小线程池。

同时,有些时候做了一个优化点之后,会发现新的问题,这个问题可能在之前被那个占大部分因素的性能瓶颈遮蔽掉了,现在大问题解决了,那这个小问题就显现出来了。此时,你需要针对这个新问题再收集报告,然后再优化。举个例子,原来是SQL慢,优化好之后会发现程序算法也有问题。

版权

评论