![消耗资源原因 & 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 案例分析](https://image.slidesharecdn.com/random-130905215620-/85/Java-7-320.jpg)
![消耗资源原因 & 网络IO
关键因素
● 数据传输数量远远高于网络本身传输量
sar -n DEV 1 1000
● 连接数
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'](https://image.slidesharecdn.com/random-130905215620-/85/Java-13-320.jpg)
![消耗资源原因 & 内存(JVM) & 数据分析
■ 如 O 或 P 长时间持续 90%以上则可能导致 FGC，从而致使系统响应时
间变长
○ 数据分析
jstat -gcutil [javapid] 1000
○ 实时查看内存消耗/GC情况
■ 从 FGCT 可看到每次 GC 的JVM暂停时间，其暂停时间可导致系统暂
时，造成请求阻塞](https://image.slidesharecdn.com/random-130905215620-/85/Java-17-320.jpg)
More Related Content
Viewers also liked (7)
Similar to Java 性能瓶劲分析之最佳实践 (20)
Java 性能瓶劲分析之最佳实践
- 2. 为什么要寻找性能瓶颈？ ● 为性能优化提供依据，有效确定调优目标 对于程序员来说： 对于QA人员来说: ● 对有可能成为瓶颈的地方进行针对性的压力测试 ● 更加有效的评估程序性能，而非单从表现上进行分析 ● 提升压力测试工作效率，尽快从现象中分析问题是否未解决
- 3. 性能瓶颈分析过程 寻找消耗资源的原因 据现状信息衡量目前系统资源的瓶颈 寻找执行慢的原因 ● 先粗粒度划分 ● 再粒度地具寻找体的点 ● CPU ● 文件IO ● 内存JVM ● 网络IO
- 4. 消耗资源原因 & CPU 关键因素 关键指标 ● 运行队列: 较高的load值(建议每核平均 3-4 个) ● 利用率: 建议用户进程CPU使用(us)消耗/内核CPU使用(sy) 消耗的比率在 65%-70% / 30%-35% 左右 ● sy%：过高，表示OS花费了大量时间在进行线程切换. 原因 通常是线程启动过多，并都处于不断阻塞状态或线程状态不 断在变化。 ● us%：过高，表示应用消耗了大部分的CPU。原因通常是大 量计算或GC导致。 ● 上下文切换: 过多线程切换
- 5. 消耗资源原因 & CPU & 数据分析 vmstat ○ 查看系统的CPU利用率 ■ 如 r(等待和正在运行队列的进程数) 数大于CPU个数，则有可能出现CPU瓶颈. ○ 数据分析 ■ 如 b(等待IO的进程数) 经常过高，则io(网络IO/文件IO)消耗严重。 ■ 通过应当结合CPU利用率和CPU Load average来判断性能问题。 ■ 如果每个CPU的平均load值大于5(load/cpu count)则存在严重的性能问题(无 论CPU利用率如何)。
- 6. 消耗资源原因 & CPU & 数据分析 可根据进程的 usr 和 system 来判定该进程是否对CPU消耗过高 top | pidstat ○ 查看各进程/线程对CPU利用率
- 7. 消耗资源原因 & 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 案例分析
- 8. ● CPU高消耗的情况 附一: 对 Thread Dump 的几点补充: ● CPU低消耗较高响应时间 ○ 在Dump中检查线程死锁(线程之间死锁、Vector、文件写 死锁等) ○ 存在远程调用，等待远程调用返回 ● 如何看懂 Thread Dump? ○ Java Thread Dump ○ Analyzing Java Thread Dumps ○ Dump中所有或大多数线程都在执行同一方法和同一行代 码，几乎可以将该代码定义为罪魁祸首。
- 9. ● 正确看待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或内存导致)
- 10. 消耗资源原因 & 文件IO ● 衡量瓶颈的重要指标：iowait% ○ 多线程进行大量的内容写入动作 ○ 磁盘设备本身的处理速度慢 ○ 文件系统较慢 ○ 操作的文件已经非常大 ● 分析过程 ○ top / iowait% ○ iostat ○ pidstat ○ jstack thread dump
- 11. 消耗资源原因 & 文件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处理的队列太长，则会导致 响应时间变慢。
- 12. 消耗资源原因 & 文件IO & 数据分析 注： pidstat / iotop 查看线程 io详细，Linux 内核( uname -r )必须 >= 2.6.20. pidstat | iotop ○ 查看各进程/线程的 IO 详细信息 ■ 可看到具体线程组(TGID)及具体线程(TID)的IO读写信息，找到 r/s 或 w/s 较高的线程。如 java 线程，则可通过 TID 找到具体 IO 消耗代码行。 ○ 数据分析
- 13. 消耗资源原因 & 网络IO 关键因素 ● 数据传输数量远远高于网络本身传输量 sar -n DEV 1 1000 ● 连接数 netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
- 14. 消耗资源原因 & 内存(JVM) 关键因素 内存监控 ● 堆外内存: swap及物理内存消耗(过多线程或BufferByte 过大) ● 堆内： jstat | jmap | jconsole ● 堆外： top | vmstat | pidstat ● 堆内内存: GC/增加CPU消耗/线程增加/OOM 分析过程 ● 物理内存消耗分析 ● JVM内存消耗分析
- 15. 消耗资源原因 & 内存(JVM) & 数据分析 ■ 从 vmstat可看出swpd(虚拟内存)信息，如过高是由于系统物理内存不够 用，则可能产生 swap io (si / so)影响系统性能。 ○ 数据分析 ■ 从 free 可以看出系统当前可用的物理内存为: free+buffers+cached vmstat ｜ free ○ 查看系统物理内存消耗信息
- 16. 消耗资源原因 & 内存(JVM) & 数据分析 ■ %mem，该进程占用系统物理内存的百分比 ○ 数据分析 ■ 如对于 JVM 的内存使用分析准确的信息应该使用 jvm 相关工具查看 top | pidstat ○ 查看各进程对物理内存消耗
- 17. 消耗资源原因 & 内存(JVM) & 数据分析 ■ 如 O 或 P 长时间持续 90%以上则可能导致 FGC，从而致使系统响应时 间变长 ○ 数据分析 jstat -gcutil [javapid] 1000 ○ 实时查看内存消耗/GC情况 ■ 从 FGCT 可看到每次 GC 的JVM暂停时间，其暂停时间可导致系统暂 时，造成请求阻塞
- 19. 寻找执行慢原因 ● 锁竟争激烈 ● 末充分使用使用硬件资源 ● 远程调用/远程访问 锁竞争激烈会直接导致程序执行变慢。典型例子：Tomcat最大线程数/Linux最 大连接数/Apache最大连接数等 程序末充分利用硬件资源。如多核CPU上使用单线程工作 本身应用存在对其它机器的远程调用。典型例子：Reverse中的Tomcat访问其 它机器的Netty服务/某服务访问其它机器的C++服务
- 20. 实践经验 ● 性能分析原则：8/2法则, 80%的性能问题集中于20%代码(瓶颈)中。 ● 不要表面现象“迷惑”，应当从不同的角度/方式确定现象根源，从而避免被假象误 导。 ● 在没十拿九稳确定性能瓶颈前不要想当然的做"大面积"的优化，否则将可 能“得不尝失”。
- 21. Q & A End!