Java 性能瓶劲分析之最佳实践

性能瓶颈分析
之
最佳实践
从现象中寻找根源 @ 分析过程及实用工具
综合研发部-邓飞鸽
2012-03-27

为什么要寻找性能瓶颈？
● 为性能优化提供依据，有效确定调优目标
对于程序员来说：
对于QA人员来说:
● 对有可能成为瓶颈的地方进行针对性的压力测试
● 更加有效的评估程序性能，而非单从表现上进行分析
● 提升压力测试工作效率，尽快从现象中分析问题是否未解决

性能瓶颈分析过程
寻找消耗资源的原因
据现状信息衡量目前系统资源的瓶颈
寻找执行慢的原因
● 先粗粒度划分
● 再粒度地具寻找体的点
● CPU
● 文件IO
● 内存JVM
● 网络IO

消耗资源原因 & CPU
关键因素
关键指标
● 运行队列: 较高的load值(建议每核平均 3-4 个)
● 利用率: 建议用户进程CPU使用(us)消耗/内核CPU使用(sy)
消耗的比率在 65%-70% / 30%-35% 左右
● sy%：过高，表示OS花费了大量时间在进行线程切换. 原因
通常是线程启动过多，并都处于不断阻塞状态或线程状态不
断在变化。
● us%：过高，表示应用消耗了大部分的CPU。原因通常是大
量计算或GC导致。
● 上下文切换: 过多线程切换

消耗资源原因 & CPU & 数据分析
vmstat
○ 查看系统的CPU利用率
■ 如 r(等待和正在运行队列的进程数) 数大于CPU个数，则有可能出现CPU瓶颈.
○ 数据分析
■ 如 b(等待IO的进程数) 经常过高，则io(网络IO/文件IO)消耗严重。
■ 通过应当结合CPU利用率和CPU Load average来判断性能问题。
■ 如果每个CPU的平均load值大于5(load/cpu count)则存在严重的性能问题(无
论CPU利用率如何)。

消耗资源原因 & CPU & 数据分析
可根据进程的 usr 和 system 来判定该进程是否对CPU消耗过高
top | pidstat
○ 查看各进程/线程对CPU利用率

消耗资源原因 & CPU & 分析过程
● top
us% or sy% 过高?
● pidstat 1 1000
查看 us / sy 过高的进程(PID)
● pidstat -p [pid] -t 1 5
找到指定pid中消耗较高的线程TID
● jstack -l [pid] | grep 'nid=0x[TID十六进制]' -C 20
查看消耗较高的线程执行的代码行(Stack Dump)
● vmstat 1 100
进一步确定消耗, 查看 r / b / cs /us 数据
HighCPUDemo.java 案例分析

● CPU高消耗的情况
附一: 对 Thread Dump 的几点补充:
● CPU低消耗较高响应时间
○ 在Dump中检查线程死锁(线程之间死锁、Vector、文件写
死锁等)
○ 存在远程调用，等待远程调用返回
● 如何看懂 Thread Dump?
○ Java Thread Dump
○ Analyzing Java Thread Dumps
○ Dump中所有或大多数线程都在执行同一方法和同一行代
码，几乎可以将该代码定义为罪魁祸首。

● 正确看待CPU瓶颈
附二: 对 CPU 的几点补充:
○ us+sy值接近100%表示CPU满负何工作，并不能直接证明
CPU瓶颈。
○ 唯一确定CPU瓶颈只有 vmstat 中的 r(运行队列)或 load
值。
● 关于CPU负荷
○ 最理想：CPU利用率较高并且load值等于CPU个数。
○ 高负荷：CPU利用率较高并且load值远远大于CPU个数。
(查看vmstat r值，CPU瓶颈)
○ 不平衡：CPU利用率一般或很低并且load值大于或等于
CPU个数。(查看vmstat b值,网络或文件io或内存导致)

消耗资源原因 & 文件IO
● 衡量瓶颈的重要指标：iowait%
○ 多线程进行大量的内容写入动作
○ 磁盘设备本身的处理速度慢
○ 文件系统较慢
○ 操作的文件已经非常大
● 分析过程
○ top / iowait%
○ iostat
○ pidstat
○ jstack thread dump

消耗资源原因 & 文件IO & 数据分析
top | iostat
○ 查看各硬盘IO负载信息
■ 通过 top 查看 iowait% 百分比，如高于30%, IO压力则已经较高，详情可
进一步使用 iostat 查看具体细则。
○ 数据分析
■ IO 操作对时间消耗可从 util% 看出，如将近100%表示 io 请求(tps)过多。
■ 确定 IO瓶颈重要指标在于 r/s、w/s 及 rkB/s、wkB/s，前者为 tps, 后者为
吞吐量。
■ 如 await 远远大于 svctm，说明等待的系统IO处理的队列太长，则会导致
响应时间变慢。

消耗资源原因 & 文件IO & 数据分析
注： pidstat / iotop 查看线程 io详细，Linux 内核( uname -r )必须 >= 2.6.20.
pidstat | iotop
○ 查看各进程/线程的 IO 详细信息
■ 可看到具体线程组(TGID)及具体线程(TID)的IO读写信息，找到 r/s 或 w/s
较高的线程。如 java 线程，则可通过 TID 找到具体 IO 消耗代码行。
○ 数据分析

消耗资源原因 & 网络IO
关键因素
● 数据传输数量远远高于网络本身传输量
sar -n DEV 1 1000
● 连接数
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

消耗资源原因 & 内存(JVM)
关键因素
内存监控
● 堆外内存: swap及物理内存消耗(过多线程或BufferByte
过大)
● 堆内： jstat | jmap | jconsole
● 堆外： top | vmstat | pidstat
● 堆内内存: GC/增加CPU消耗/线程增加/OOM
分析过程
● 物理内存消耗分析
● JVM内存消耗分析

消耗资源原因 & 内存(JVM) & 数据分析
■ 从 vmstat可看出swpd(虚拟内存)信息，如过高是由于系统物理内存不够
用，则可能产生 swap io (si / so)影响系统性能。
○ 数据分析
■ 从 free 可以看出系统当前可用的物理内存为: free+buffers+cached
vmstat ｜ free
○ 查看系统物理内存消耗信息

■ %mem，该进程占用系统物理内存的百分比
○ 数据分析
■ 如对于 JVM 的内存使用分析准确的信息应该使用 jvm 相关工具查看
top | pidstat
○ 查看各进程对物理内存消耗

■ 如 O 或 P 长时间持续 90%以上则可能导致 FGC，从而致使系统响应时
间变长
○ 数据分析
jstat -gcutil [javapid] 1000
○ 实时查看内存消耗/GC情况
■ 从 FGCT 可看到每次 GC 的JVM暂停时间，其暂停时间可导致系统暂
时，造成请求阻塞

系统资源消耗非常低，响应时
间却还是很高？

寻找执行慢原因
● 锁竟争激烈
● 末充分使用使用硬件资源
● 远程调用/远程访问
锁竞争激烈会直接导致程序执行变慢。典型例子：Tomcat最大线程数/Linux最
大连接数/Apache最大连接数等
程序末充分利用硬件资源。如多核CPU上使用单线程工作
本身应用存在对其它机器的远程调用。典型例子：Reverse中的Tomcat访问其
它机器的Netty服务/某服务访问其它机器的C++服务

实践经验
● 性能分析原则：8/2法则, 80%的性能问题集中于20%代码(瓶颈)中。
● 不要表面现象“迷惑”，应当从不同的角度/方式确定现象根源，从而避免被假象误
导。
● 在没十拿九稳确定性能瓶颈前不要想当然的做"大面积"的优化，否则将可
能“得不尝失”。

Java 性能瓶劲分析之最佳实践

More Related Content

Viewers also liked

Similar to Java 性能瓶劲分析之最佳实践

Java 性能瓶劲分析之最佳实践