资讯专栏INFORMATION COLUMN

Java应用性能调优

gaara / 2053人阅读

摘要:针对应用,性能诊断工具主要分为两层层面和应用层面包括应用代码诊断和诊断。诊断对于主要关注平均负载,使用率,上下文切换次数。常用的应用诊断包括线程堆栈等方面的诊断。

性能诊断工具

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

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

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

通过 top 命令可以查看系统平均负载和 CPU 使用率,图 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 命令示例

for(Category c = this; c != null; c=c.parent) {
 // Protected against simultaneous call to addAppender, removeAppender,…
 synchronized(c) {
 if (c.aai != null) {
 write += c.aai.appendLoopAppenders(event);
 }
 …
 }
}

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 性能观测工具

Java 应用诊断工具

应用代码诊断
应用代码性能问题是相对好解决的一类性能问题。通过一些应用层面监控报警,如果确定有问题的功能和代码,直接通过代码就可以定位;或者通过 top+jstack,找出有问题的线程栈,定位到问题线程的代码上,也可以发现问题。对于更复杂,逻辑更多的代码段,通过 Stopwatch 打印性能日志往往也可以定位大多数应用代码性能问题。

常用的 Java 应用诊断包括线程、堆栈、GC 等方面的诊断。

jstack
jstack 命令通常配合 top 使用,通过 top -H -p pid 定位 Java 进程和线程,再利用 jstack -l pid 输出线程栈到控制台 .jstack -l pid >> xxxfile.dump到文件。由于线程栈是瞬态的,因此需要多次 dump,一般 3 次 dump,一般每次隔 5s 就行。将 top 定位的 Java 线程 pid 转成 16 进制,得到 Java 线程栈中的 nid,可以找到对应的问题线程栈。

图 5. 通过 top –H -p pid查看运行时间较长 Java 线程

如图 5 所示,其中的线程 24985 运行时间较长,可能存在问题,转成 16 进制后,通过 Java 线程栈找到对应线程 0x6199 的栈如下,从而定位问题点,如图 6 所示。

图 6.jstack 查看线程堆栈

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/71423.html

相关文章

  • Java性能调优概述

    摘要:性能调优概述性能优化有风险和弊端,性能调优必须有明确的目标,不要为了调优而调优盲目调优,风险远大于收益程序性能的主要表现点执行速度程序的反映是否迅速,响应时间是否足够短内存分配内存分配是否合理,是否过多地消耗内存或者存在内存泄漏启动时间程序 [TOC] Java性能调优概述 性能优化有风险和弊端,性能调优必须有明确的目标,不要为了调优而调优!!!盲目调优,风险远大于收益!!! 程序性...

    ad6623 评论0 收藏0
  • [译]GC专家系列3-GC调优

    摘要:原文链接本篇是专家系列的第三篇。但是,请记住调优是不得已时的选择。缩短耗时的单次执行与相比,耗时有较明显的增加。创建文件过程中,进程会中断,因此不要在正常运行时系统上做此操作。因此校验结果并根据具体的服务需要,决定是否要进行调优。 原文链接:http://www.cubrid.org/blog/dev-platform/how-to-tune-java-garbage-collecti...

    leap_frog 评论0 收藏0
  • 这就是我和大佬的差距吗?看看别人是怎么做性能调优

    摘要:这就是我和大佬的差距吗看看别人是怎么做性能调优的性能调优后来的几年里,我又陆续参与过物流电商游戏支付系统的研发,这些项目都存在一个共性,就是经常会运营一些大促以及抢购类活动。 先给大家讲个故事吧。多年前我加入了一家大型互联网公司,刚进入就以 996 标准,参与新品研发。公司业务发展急需互联网产品,因此我们的时间很紧张,4 ...

    番茄西红柿 评论0 收藏2637
  • Java垃圾回收调优

    摘要:垃圾回收调优应该是提升应用吞吐量的最后一个选择。在你发现应用由于长时间垃圾回收导致了应用性能下降出现超时的时候,应该考虑垃圾收集调优。全面垃圾收集调优要花费大量的努力和时间,这里没有一尘不变的硬性调优规则。 Java垃圾回收调优应该是提升应用吞吐量的最后一个选择。在你发现应用由于长时间垃圾回收导致了应用性能下降、出现超时的时候,应该考虑Java垃圾收集调优。如果你在日志里看到 java...

    laoLiueizo 评论0 收藏0

发表评论

0条评论

gaara

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<