性能测试分析与调优

随笔1个月前发布 生活的态度
5 0 0

Linux服务器性能查看分析调优 – 知乎 (zhihu.com)

步骤:

确定问题。根据性能测试的结果来分析确定bug —— 测试⼈员职责
分析原因。分析问题产⽣的原因 —— 开发⼈员职责
给出解决⽅案。可以是修改软件配置、增加硬件资源配置、修改代码等 —— 开发⼈员职责验证解决⽅案。—— 测试⼈员回归测试
分析验证结果 —— 既要保证有问题的指标得到解决,⼜要保证其他指标没有出现新问题

注意:性能分析和调优需要经过很多轮,才能最终解决问题。以上步骤是循环的。

性能测试监控关键指标

性能问题可能产生的原因

服务器的资源 —— 影响应⽤服务器和数据库服务器处理的速率 和 ⽹络传输速率
JVM瓶颈分析 —— JAVA程序运⾏的环境
数据库瓶颈分析 —— 数据库程序运⾏环境分析
程序内部实现机制 —— 开发⼈员编写的代码分析
压测机 —— 影响性能结果

常见性能瓶颈分析

1. 服务器资源分析

CPU瓶颈分析

CPU已压满(接近100%),需要再看其他指标的拐点出现的时刻是否与CPU压满的时刻基本一致

内存瓶颈分析

内存不足时,操作系统会使用虚拟内存,从虚拟内存读取数据,影响处理速度

磁盘I/O瓶颈分析

磁盘I/O成为瓶颈时,会出现磁盘I/O繁忙,导致交易执行时在I/O处等待

网络带宽

如果接口传递的数据包过大,超过了带宽的传输能力,就会造成网络资源竞争,导致TPS上不去

2. JVM瓶颈分析

分析JVM的内存

3. 数据库瓶颈分析

慢查询
数据库的连接池设置太小,导致数据库连接出现排队
数据库出现死锁

4. 程序内部实现机制

5. 压测机

JMeter单机负载能力有限,如果需要模拟的用户请求数超过其负载极限,也会导致TPS压不上去

服务器资源分析

服务器的硬件

CPU、内存、磁盘、外设(键盘、⿏标、显示器、散热器、机箱)

运行速度从快到慢:CPU >> 内存 >> 磁盘

存储空间从大到小:磁盘 >> 内存 >> CPU

vmstat、sar、iostat 检测是否是CPU瓶颈
free、vmstat 检测是否是内存瓶颈
iostat 检测是否是磁盘I/O瓶颈
netstat 检测是否是网络带宽瓶颈

1. CPU

CPU:单位HZ,将CPU划分为若干个时间⽚,为每个程序分配对应的时间片,保证所有的程序占⽤时间片来串行执行。

CPU使⽤率 = 已使⽤的时间⽚ / 总时间⽚ * 100%

已使⽤的时间⽚ = ⽤户CPU + 系统CPU
总时间⽚ = ⽤户CPU + 系统CPU + 空闲CPU
⽤户CPU:所有应⽤程序运⾏时消耗的CPU
系统CPU:操作系统运⾏消耗的CPU

CPU监控命令:top  # CPU时间 = us + sy + id

性能测试分析与调优

测试的关注点:

CPU⾼时,需要确认是⽤户CPU⾼还是系统CPU⾼
如果是⽤户CPU⾼,需要进⼀步分析对应的应⽤程序的执⾏效率是否有问题
如果是系统CPU⾼,需要进⼀步观察其他的资源(内存、磁盘、⽹络等)是否存在问题

2. 内存和虚拟内存

内存:实际内存/物理内存,机器实际的内存空间,所有的程序运行都必须加载到内存中才能运行。

虚拟内存:⼀种虚拟化的技术。当内存空间不⾜时,从磁盘中读⼊数据,处理完成后写回磁盘,以此进行交换,保证在内存不足时,程序也能够运行。

注意:由于虚拟内存,实际上完成了数据在磁盘和内存之间的读写过程,磁盘的速度要远慢于内存时,因此当使⽤虚拟内存时,说明内存已经不⾜,可能存在问题

命令:

查看总量:top
查看虚拟内存的使⽤量:vmstat  # Virtual Meomory Statistics,虚拟内存统计

swap in:即si,表示虚拟内存的页导入,即从SWAP DISK交换到RAM
swap out:即so,表示虚拟内存的页导出,即从RAM交换到SWAP DISK

性能测试分析与调优

测试关注点:

实际内存:查看内存使⽤百分⽐,检查是否超过80%
虚拟内存:查看swap的si和so是否为0,如果不为0,说明内存可能不足

3. 磁盘IO

关注是磁盘读入和写出的速度,不是磁盘大小。

命令:iostat -x 1 2  # 输入/输出统计,查看硬盘的I/O性能(每秒显示一次,显示2次)。-x:磁盘利用率。-c:CPU利用率。

%idle:空闲CPU的时间百分比。如idle小于70%,I/O的压力就比较大了,说明读取进程中有较多的wait。

await:平均每次设备I/O操作等待时间(毫秒)。svctm:平均每次设备I/O操作的服务时间(毫秒)

svctm ≈ await,表示几乎没有I/O等待,磁盘性能很好;await >> svctm,则表示I/O队列等待太长,系统上运行的应用程序将变慢, 此时可以通过更换更快的硬盘来解决问题。

%util:一秒中有百分之几的时间用于I/O操作。衡量磁盘I/O重要指标,如%util接近100%,表示磁盘产生的I/O请求太多,I/O系统已经满负荷工作,该磁盘可能存在瓶颈。

性能测试分析与调优

测试关注点:

%util⾼,说明磁盘⻓时间占⽤CPU在发送数据,说明磁盘传输速度不足,存在瓶颈
%iowait⾼,说明磁盘IO传输数据的任务很多,在等待,说明磁盘传输速度不足,存在瓶颈

4. 网络

关注是网络传输数据的速度。

命令:sar -n DEV 1 2  # -n DEV 查看当天从零点到当前时间的网卡流量信息。每秒一次,共2次

rxKB/s:每秒接收的数据量(千字节数)。txKB/s:每秒发送的数据量(千字节数)

性能测试分析与调优

测试关注点:

实际统计的发送速率和接收速率,与⽹络的总带宽进⾏对⽐,查看使⽤的百分⽐(如果⽆限接近100%,说明存在⽹络性能瓶颈)

补充介绍

宽带:⽤户(业务)维度来描述⽹络速率的⽅式。例如:20M宽带、100M宽带、1000M宽带

速率单位:b(bit)/s

带宽:数据在网络中传输的速率,在技术中都是通过带宽来描述速率。

速率单位:B(Byte)/s1B = 8bit

实际情况:1000M宽带 —— 对应着的带宽速率为 1000Mb/s / 8bit = 125MB/s

JVM瓶颈分析

Java应用瓶颈分析 —— JVM内存分析

JVM内存:Java 虚拟机在执行 Java 程序的过程中所管理的不同的内存数据区域。可简单分为:堆内存和非堆内存

堆内存:主要存放用new关键字创建的对象,所有对象实例以及数组都在堆上分配。 —— 给开发人员使用的(关注)
非堆内存:保存虚拟机自己的静态数据,存放加载的Class类级别静态对象如类、方法等。 —— 给JVM自己使用的

性能测试分析与调优

Java内存瓶颈分析 —— jvm内存监控

工具位置:JDK的bin目录下的 jvisualvm.exe,双击启动。

具体使用请看:Java自带的jvisualVM简单介绍 – Taider_Yang – 博客园 (cnblogs.com)

数据库瓶颈分析

数据库瓶颈分析 —— 慢查询

slow_query_log:慢查询日志开启状态
slow_query_log_file:慢查询日志存放位置
long_query_time: 慢查询时间阈值(超过该时长才会被记录,单位:秒)

查询慢查询的相关参数:show variables like “”;

性能测试分析与调优

知道了慢查询日志存放位置,就可以用cd命令进入该目录,然后用 tail -f xxx.log 命令实时查看sql日志了,再去操作数据库增删改查,产生日志(超过慢查询时间阈值)。

性能测试分析与调优

设置慢查询的相关参数:set global 参数名 = 值;

性能测试分析与调优

数据库瓶颈分析 —— 数据库连接池

数据库连接池定义:数据库连接池是负责分配、管理和释放数据库连接,它允许应用程序重复使用一个现有的数据库连接,而不是再重新建立一个。

作用:可以提高对数据库操作的性能。

性能测试分析与调优

测试关注点:

利用率 = 当前使用的连接数/最大连接数,建议:85%左右。
如果利用率超过85%,需要增加最大连接数设置,否则会造成连接失败
如果利用率小于10%,那显然设置的过大,会造成系统资源的浪费,可能影响其它性能指标。

show variables like '%max_connections%';  # 最大连接数
show status like 'Threads_connected';  # 已使用连接数

性能测试分析与调优

数据库瓶颈分析 —— 数据库死锁

MySQL主要有两种锁:表级、行级。

表级锁:开销小,加锁快;不会出现死锁;锁定粒度最大,并发度最低。
行级锁:开销大,加锁慢;会出现死锁;锁定粒度最小,并发度也最高。

死锁:是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象。

若无外力作用,它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁。
表级锁不会产生死锁。

测试关注点(初步确定死锁):

show open tables where in_use>=1;  # 查询当前是否锁表
如果表锁了,这个sql可以查询出来。但是这个sql查出来的表,不一定是被锁住的。因为用查询,如果耗费时间很长,也会查询出来。
show processlist;  # 查看执行时间最长的线程,找到对应sql,找到表。
kill process_id;  # 如果需要先紧急解决问题,可以先手动杀死死锁的连接。

性能测试分析与调优

压测及瓶颈分析

压测机影响性能测试结果的原因主要是:

JMeter单机负载能力有限,如果需要模拟的用户请求数超过其负载极限,也会导致TPS压不上去。

压测机资源的监控方法:

Windows测试机:自带“任务管理器”
Linux测试机:PerfMon组件

解决方案:

采用分布式执行的方法来提高负载量,达到系统性能测试要求的TPS。

 

© 版权声明

相关文章

暂无评论

您必须登录才能参与评论!
立即登录
暂无评论...