首页 > 编程语言 > 详细

Java 应用性能调优实践

时间:2019-07-11 11:23:25      阅读:39      评论:0      收藏:0      [点我收藏+]

标签:under   ren   调度   进行   知识   连续   今天   打印日志   分区   

Java 应用性能优化是一个老生常谈的话题,典型的性能问题如页面响应慢、接口超时,服务器负载高、并发数低,数据库频繁死锁等。尤其是在“糙快猛”的互联网开发模式大行其道的今天,随着系统访问量的日益增加和代码的臃肿,各种性能问题开始纷至沓来。

Java 应用性能的瓶颈点非常多,比如磁盘、内存、网络 I/O 等系统因素Java 应用代码,JVM GC,数据库,缓存等

笔者根据个人经验,将 Java 性能优化分为 4 个层级:应用层、数据库层、框架层、JVM 层,如图 1 所示。

       图 1.Java 性能优化分层模型

技术分享图片

每层优化难度逐级增加,涉及的知识和解决的问题也会不同。

比如应用层需要理解代码逻辑,通过 Java 线程栈定位有问题代码行等;

数据库层面需要分析 SQL、定位死锁等;

框架层需要懂源代码,理解框架机制;

JVM 层需要对 GC 的类型和工作机制有深入了解,对各种 JVM 参数作用了然于胸。

围绕 Java 性能优化,有两种最基本的分析方法:现场分析法和事后分析法。

现场分析法通过保留现场,再采用诊断工具分析定位。现场分析对线上影响较大,部分场景(特别是涉及到用户关键的在线业务时)不太合适。

事后分析法需要尽可能多收集现场数据,然后立即恢复服务,同时针对收集的现场数据进行事后分析和复现。下面我们从性能诊断工具出发,分享搜狗商业平台在其中的一些案例与实践。

性能诊断工具

性能诊断一种是针对已经确定有性能问题的系统和代码进行诊断,还有一种是对预上线系统提前性能测试,确定性能是否符合上线要求。本文主要针对前者,后者可以用各种性能压测工具(例如 JMeter)进行测试,不在本文讨论范围内。

针对 Java 应用,性能诊断工具主要分为两层:OS 层面和 Java 应用层面(包括应用代码诊断和 GC 诊断)。

OS 诊断

OS 的诊断主要关注的是 CPU、Memory、I/O 三个方面。

CPU 诊断

对于 CPU 主要关注平均负载(Load Average),CPU 使用率,上下文切换次数(Context Switch)

通过 top 命令可以查看系统平均负载和 CPU 使用率,图 2 为通过 top 命令查看某系统的状态。

图 2.top 命令示例

技术分享图片

平均负载有三个数字:63.66,58.39,57.18,分别表示过去 1 分钟、5 分钟、15 分钟机器的负载。按照经验,若数值小于 0.7*CPU 个数,则系统工作正常;若超过这个值,甚至达到 CPU 核数的四五倍,则系统的负载就明显偏高。图 2 中 15 分钟负载已经高达 57.18,1 分钟负载是 63.66(系统为 16 核),说明系统出现负载问题,且存在进一步升高趋势,需要定位具体原因了。

通过 vmstat 命令可以查看 CPU 的上下文切换次数,如图 3 所示:

图 3.vmstat 命令示例

 技术分享图片

上下文切换次数发生的场景主要有如下几种:

1)时间片用完,CPU 正常调度下一个任务;

2)被其它优先级更高的任务抢占;

3)执行任务碰到 I/O 阻塞,挂起当前任务,切换到下一个任务;

4)用户代码主动挂起当前任务让出 CPU;

5)多任务抢占资源,由于没有抢到被挂起;

6)硬件中断。

Java 线程上下文切换主要来自共享资源的竞争。一般单个对象加锁很少成为系统瓶颈,除非锁粒度过大。但在一个访问频度高,对多个对象连续加锁的代码块中就可能出现大量上下文切换,成为系统瓶颈。比如在我们系统中就曾出现 log4j 1.x 在较大并发下大量打印日志,出现频繁上下文切换,大量线程阻塞,导致系统吞吐量大降的情况,其相关代码如清单 1 所示,升级到 log4j 2.x 才解决这个问题。

清单 1. log4j 1.x 同步代码片段
1 for(Category c = this; c != null; c=c.parent) {
2  // Protected against simultaneous call to addAppender, removeAppender,…
3  synchronized(c) {
4  if (c.aai != null) {
5  write += c.aai.appendLoopAppenders(event);
6  }
7 8  }
9 }

Memory

从操作系统角度,内存关注应用进程是否足够,可以使用 free –m 命令查看内存的使用情况。通过 top 命令可以查看进程使用的虚拟内存 VIRT 和物理内存 RES,根据公式 VIRT = SWAP + RES 可以推算出具体应用使用的交换分区(Swap)情况,使用交换分区过大会影响 Java 应用性能,可以将 swappiness 值调到尽可能小。因为对于 Java 应用来说,占用太多交换分区可能会影响性能,毕竟磁盘性能比内存慢太多。

I/O

I/O 包括磁盘 I/O 和网络 I/O,一般情况下磁盘更容易出现 I/O 瓶颈。通过 iostat 可以查看磁盘的读写情况,通过 CPU 的 I/O wait 可以看出磁盘 I/O 是否正常。如果磁盘 I/O 一直处于很高的状态,说明磁盘太慢或故障,成为了性能瓶颈,需要进行应用优化或者磁盘更换。

除了常用的 top、 ps、vmstat、iostat 等命令,还有其他 Linux 工具可以诊断系统问题,如 mpstat、tcpdump、netstat、pidstat、sar 等。Brendan 总结列出了 Linux 不同设备类型的性能诊断工具,如图 4 所示,可供参考。

图 4.Linux 性能观测工具

 技术分享图片

....

 转载:https://www.ibm.com/developerworks/cn/java/j-lo-performance-tuning-practice/index.html

 

Java 应用性能调优实践

标签:under   ren   调度   进行   知识   连续   今天   打印日志   分区   

原文:https://www.cnblogs.com/luoshengjie/p/11168419.html

(0)
(0)
   
举报
评论 一句话评论(0
0条  
登录后才能评论!
© 2014 bubuko.com 版权所有 鲁ICP备09046678号-4
打开技术之扣,分享程序人生!
             

鲁公网安备 37021202000002号