美文网首页
JVM性能调优实践——性能测试篇

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

作者: 高级java架构师 | 来源:发表于2019-01-08 09:35 被阅读15次

    前言

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

    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

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

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

    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 

    1

    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

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    %util: 衡量device使用率的指标。处理I/O请求的时间与统计时间的百分比.大于60%的话,会影响系统性能。

    r/s, w/s :每秒处理,读、写的请求数量。

    rkB/s,wkB/s :每秒读/写的数据大小。

    ---------------------

    如果你想学好JAVA这门技术,也想在IT行业拿高薪,可以参加我们的训练营课程,选择最适合自己的课程学习,技术大牛亲授,8个月后,进入名企拿高薪。我们的课程内容有:Java工程化、高性能及分布式、高性能、深入浅出。高架构。性能调优、Spring,MyBatis,Netty源码分析和大数据等多个知识点。如果你想拿高薪的,想学习的,想就业前景好的,想跟别人竞争能取得优势的,想进阿里面试但担心面试不过的,你都可以来,q群号为:180705916 进群免费领取学习资料。

    相关文章

      网友评论

          本文标题:JVM性能调优实践——性能测试篇

          本文链接:https://www.haomeiwen.com/subject/botvrqtx.html