前言

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

  1. os: Linux 64位
  2. jdk:java version “1.8.0_121”, HotSpot(TM) 64-Bit Server VM
  3. 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 :每秒读/写的数据大小。
GitHub 加速计划 / li / linux-dash
6
1
下载
A beautiful web dashboard for Linux
最近提交(Master分支:3 个月前 )
186a802e added ecosystem file for PM2 4 年前
5def40a3 Add host customization support for the NodeJS version 4 年前
Logo

旨在为数千万中国开发者提供一个无缝且高效的云端环境,以支持学习、使用和贡献开源项目。

更多推荐