JVM性能调优实践——性能测试篇

最新推荐文章于 2025-07-27 20:47:57 发布

置顶智秒数服.未闻

最新推荐文章于 2025-07-27 20:47:57 发布

阅读量6.9k

点赞数 2

CC 4.0 BY-SA版权

分类专栏：架构 JVM 深入JVM 文章标签：性能测试性能调优 CPU 内存性能指标分析

本文链接：https://blog.youkuaiyun.com/lijingyao8206/article/details/80325670

架构同时被 3 个专栏收录

28 篇文章

订阅专栏

深入JVM

15 篇文章

订阅专栏

JVM

9 篇文章

订阅专栏

本文针对Web应用性能调优，介绍了如何确定性能目标、关注的主要性能指标及系统资源使用情况，并详细解析了CPU、内存和磁盘性能指标的监控与分析。

前言

本文主要基于工作中，关于性能调优的一些零散的信息整理。总结性的信息，以测试环境为例。系统信息如下：

os: Linux 64位
jdk：java version “1.8.0_121”, HotSpot(TM) 64-Bit Server VM
docker version: 17.04.0-ce

第一篇先整理一些性能指标。第二篇整理一下jvm的性能问题分析，以及基于docker容器的微服务性能分析。第三篇再整理下GC相关的优化，主要基于G1垃圾收集器。

确定性能目标

性能优化不是漫无目的的去优化。结合不同的业务场景以及应用的特点去进行重点优化。主动的优化需要结合业务未来的发展以及业务目标，参考当前的系统资源和监控数据情况来决定一些性能优化的优先级。为了不让性能成为未来业务发展的瓶颈，需要提前准备和布局。比如通过搜索、Cache等优化对于DB的请求。
在实际的情况中，也会存在一些被动的优化。当系统中的一些资源成为瓶颈，已经影响了当前用户、业务的情况。需要技术同学能有结合性能需求进行问题分析和救火能力。

性能指标、资源

对于Web应用一般重点关注的性能指标主要是吞吐量、响应时间、QPS、TPS等、并发用户数等。
系统资源一般指如CPU、内存、磁盘IO、网络IO等资源。以下说明以Linux为例，性能测试中，主要观察的cpu、内存、磁盘等指标的信息。

CPU

CPU资源一般可以使用vmstat来采样（例如每秒采样一次： vmstat 1）查看CPU上下文切换。如下：

$ vmstat 1 
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 284628 234036 859100    0    0     1    15    0    1  3  1 96  0  0
 0  0      0 284536 234036 859204    0    0     0     0 4952 9461  4  2 95  0  0
 0  0      0 284536 234036 859208    0    0     0   200 5081 9768  3  3 94  1  0
 0  0      0 284568 234036 859212    0    0     0    16 5126 9757  3  2 96  0  0
 0  0      0 284900 234036 859236    0    0     0     0 5431 10230  4  3 94  0  0
 1  0      0 285608 234036 859256    0    0     0     0 5325 10005  6  2 92  0  0
 0  0      0 285452 234036 859256    0    0     0     0 5037 9653  3  1 96  0  0
 0  0      0 285484 234036 859264    0    0     0    60 5068 9599  3  1 96  0  0
 0  0      0 285452 234036 859264    0    0     0    36 5163 9825  4  2 94  0  0

一般最主要关注的主要是以下指标：

us：用户占用CPU的百分比
sy：系统(内核和中断)占用CPU的百分比
id：CPU空闲的百分比
in: 系统中断数
cs: 每秒上下文切换次数
r: 可运行进程数，包括正在运行(Running)和已就绪等待运行(Waiting)的。在负载测试中，其可接受上限通常不超过CPU核数的2倍。

CPU使用率通常用us + sy来计算，一般大于80%说明，CPU资源出现瓶颈。同时也要综合参考CPU平均负载Load Average信息。Linux系统中，一般取运行队列的值 + 处于task_uninterruptible状态的进程数(vmstat输出的b)。可以通过top命令查看1分钟、5分钟和15分钟的平均负载值。一般来说平均负载的15min采样大于核数*0.7 就要关注和排查一下高负载的原因。
top 命令的load average信息如下：

top - 10:41:04 up 11 days, 23:32,  2 users,  load average: 0.25, 0.22, 0.18

0.25, 0.22, 0.18 ,分别是1分钟，5分钟，15分钟采样数据

内存

vmstat也输出了内存信息。

free: 系统可用内存，对于稳定运行的系统，free可接受的范围通常应该大于物理内存的20%。
so/si : 每秒从内存写入到SWAP的数据大小/每秒从SWAP读取到内存的数据大小。如果出现频繁的swap交换，会影响系统性能，需要一起注意。
swpd：系统当前的swap空间占用。可以和so/si 综合分析。如果swpd为0 ，内存资源没有成为瓶颈。

磁盘

对于磁盘，首要关注使用率，IOPS和数据吞吐量，在Linux服务区，可以使用iostat来获取这些数据。

$ iostat -dxk 1
Linux 4.4.0-63-generic  _x86_64 
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     2.69    0.07    2.21     1.28    28.96    26.53     0.00    1.85    1.19    1.87   0.31   0.07

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    2.00    0.00    12.00     0.00    12.00     0.02   10.00   10.00    0.00  10.00   2.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00    29.00    0.00    2.00     0.00   124.00   124.00     0.00    2.00    0.00    2.00   2.00   0.40

%util: 衡量device使用率的指标。处理I/O请求的时间与统计时间的百分比.大于60%的话，会影响系统性能。
r/s， w/s ：每秒处理，读、写的请求数量。
rkB/s,wkB/s :每秒读/写的数据大小。