性能测试问题排查及调优的常规思路

性能测试问题排查及调优的常规思路

常见的性能测试中出现的问题都是千奇百怪，但其实在调优和找问题的方面都是有章法和套路可寻的。

性能问题常见表现

一般服务器在出现问题时的表现会出现以下几种情况：

1.服务器崩溃：每秒事务数出现大幅波动，且前台或后台出现大量报错

2.服务器对压力不敏感：压力不停增加，但服务器处理速度无显著变化，系统处理能

力稳定在一个较低的水平但不崩溃

性能问题服务器硬件指标常见表现

当出现性能问题时，服务器常见的表现会出现以下几种：

●应用服务器CPU居高不下：如果非计算类服务，一般是由于系统存在错误逻辑导致线

程锁或有低级错误（例如日志写入用了system.out）导致，如果是计算类服务

●应用服务器内存使用持续走高，一般是由于服务器产生大量实例积压导致，常见于大

量session/线程大量堆积（一个session一般占用10-20M左右的jvm内存），但是为什么会导致session/线程堆积的问题要具体分析。

●应用服务器磁盘交换率居高不下，顾名思义，大量的文件写操作在进行，如果业务逻

辑没有频繁读写文件，则需排查，首先排查日志写入

●应用服务器网络流量居高不下，常见报文一般是2K-20K左右，可根据并发数计算大

致流量，若实际流量和计算明显不符，则需要排查到底是哪些连接在消耗流量，常见是一些图片、js等资源文件没有设置本地缓存。

●数据库服务器cpu居高不下，一般常见于大量全表扫描，大量物理读，sql执行效率

低下等情况，要配合top10 sql进一步查询

●数据库服务器缓冲区命中率持续偏低，偏低一般是小于95%，常见于数据库配置有问

题，联系DBA进行进一步解决。

数据库服务器网络流量居高不下，要结合考虑业务及应用逻辑分析为什么会有大量数据持续的在数据库和应用服务器之间流动，并根据实际情况看是否能简化部分互交逻辑，减少带宽消耗。

性能问题排查一般过程：

按照问题发生的概率和投入产出比来说，一般情况下，会按照下图逻辑进行性能问题排摸和调优。在解决SQL和应用配置问题后，基本已经解决了90%左右的性能问题了。

数据库与sql排查注意点

排查数据库和sql语句的问题。常通过获取top 10 sql来定位最耗资源的sql语句，并分析sql语句来确认性能问题。数据库常见的性能问题表现为数据库服务器CPU过高。以oracle为例，列举一些常见问题：

1)数据表/字段没有索引或sql查询时，某条件不在索引上：这个问题在新系统的测试环

境上最为常见，常常是开发新建了表或字段，忘了加索引。加上索引即可修复。

2)表锁、行锁，这个是应用和数据库的共同问题，常见于几种情况（包含但不限于）：

a)最常见：Select for update 之后没有及时 commit掉。

b)对某一张大表进行大量或全量update的时候没有分批进行，而是一次性update并

commit，并且对该表的读取方式未使用脏读模式。

c)自增订单号没有使用sequence，而是通过数据库内某字段做控制。在大并发的情

况下，对一条记录进行频繁的update

3)数据表有索引，sql查询的时候，索引未生效，一般索引未生效有以下原因（包含但不

限于），需要逐一排查：

a)使用不等于!= 或<>运算符

b)使用like的时候百分号/下划线等通配符在前，例如 "%_"

c)数据发生很大变动之后，表没进行分析，可通过表分析或强制索引解决

d)单独引用复合索引里的部分索引列，会不走索引或导致索引效果下降

e)字符型字段为数字时在where条件里不添加引号，隐式数据转换导致索引失效

f)在where条件中对索引列进行函数运算，如trim(),如需对字段进行函数处理，则要

建立函数索引.

g)对索引列使用 not in ,not exist 运算符

h)日期时间类字段做索引，在查询的时候等号两边数据类型不一致，导致隐式数据转

换导致索引失效，例如datatime 查timestamp 或者字符串查timestamp。很多大公司的编码规范中都完全抵制使用日期时间类字段作为索引。

i)使用了is null导致索引（尤其是复合索引）失效，建议字段不要为NULL，用0、

特殊值或空字符串来代替

j)跨表空间查询导致索引失效，建议对单个表空间进行查询后，用union联合查询

4)sql未经优化，例如使用多层嵌套查询，group by中使用了having等问题

5)缓冲区命中率低于90%，一般来说，缓冲区命中率应该要高于90%，最好在95%以上

6)表数据过大，未进行分表或分表空间。尤其是对于一些交易记录表，历史交易记录

表、日志表等数据表

应用服务器参数排查注意点

出现任何性能问题之后，除数据库外，最应该排查的内容应当是对应用服务器的配置参数排查，一般排查以下问题：

●java内存/堆栈：未设置最大内存会导致服务器当大量并发发生时，无休止的使用

内存和虚拟内存导致服务器资源耗尽。缺省值一般无限制或128m-256m

●进程池/连接数：未设置最大连接数会导致当大量并发发生时，无休止的产生新连

接/线程去处理请求，最终导致服务器资源耗尽。最大连接数设置过小，也会导致大量外链无法接入系统，返回连接超时。另外连接超时时间也不能配置的过大。

●java内存GC：过于频繁的GC会对服务器的cpu产生持续性压力，并且会影响内

存数据的可靠性，gc间隔时间过长也会导致GC时cpu使用率产生井喷时增长。

因此如果需要调整gc策略，需要找到平衡点

●日志配置：建议将日志按照天输出进行配置，并且重定向到指定磁盘或目录，并

定期清理，避免由于日志输出导致磁盘满的情况。

●日志级别：系统运行时，建议日志级别调低，尽量只打印error级别的日志。

●系统核心参数：一般常见于ulimit -a相关参数和sysctl.conf相关参数，用于控制系

统级别的资源使用极限，经常容易忘记配置的是ulimit中的 open files(-n)参数，

linux的系统默认是1024，实际作为服务器使用时远远不够的。另外ulimit参数分系统级别和用户级别，都需要设置正确

●数据库连接池：这里单独拿出来是因为经常会遇到一种情况，即应用连接池很

大，而数据库连接池却只有5-10甚至更小，当产生大量耗时的数据库查询时，请求的处理链就会阻塞在数据库查询上导致服务器资源耗尽，应用崩溃，而数据库

层面却没有任何异常产生。