《性能测试问题排查及调优的常规思路》由会员分享，可在线阅读，更多相关《性能测试问题排查及调优的常规思路（4页珍藏版）》请在装配图网上搜索。
1、性能测试问题排查及调优的常规思路常见的性能测试中出现的问题都是千奇百怪，但其实在调优和找问题的方面都是有章法和 套路可寻的。性能问题常见表现一般服务器在出现问题时的表现会出现以下几种情况：1. 服务器崩溃：每秒事务数出现大幅波动，且前台或后台出现大量报错2. 服务器对压力不敏感：压力不停增加，但服务器处理速度无显著变化，系统处理能 力稳定在一个较低的水平但不崩溃性能问题服务器硬件指标常见表现当出现性能问题时，服务器常见的表现会出现以下几种： 应用服务器CPU居高不下：如果非计算类服务，一般是由于系统存在错误逻辑导致线 程锁或有低级错误（例如日志写入用了 system.out）导致，如果是计算类
2、服务 应用服务器内存使用持续走高，一般是由于服务器产生大量实例积压导致，常见于大 量session/线程大量堆积（一个session 一般占用10-20M左右的jvm内存），但是为 什么会导致session/线程堆积的问题要具体分析。 应用服务器磁盘交换率居高不下，顾名思义，大量的文件写操作在进行，如果业务逻 辑没有频繁读写文件，则需排查，首先排查日志写入 应用服务器网络流量居高不下，常见报文一般是2K-20K左右，可根据并发数计算大 致流量，若实际流量和计算明显不符，则需要排查到底是哪些连接在消耗流量，常见 是一些图片、js等资源文件没有设置本地缓存。 数据库服务器cpu居高不下，一般常见于
3、大量全表扫描，大量物理读，sql执行效率 低下等情况，要配合top10 sql进一步查询 数据库服务器缓冲区命中率持续偏低，偏低一般是小于 95%，常见于数据库配置有问 题，联系 DBA 进行进一步解决。数据库服务器网络流量居高不下，要结合考虑业务及应用逻辑分析为什么会有大量数 据持续的在数据库和应用服务器之间流动，并根据实际情况看是否能简化部分互交逻 辑，减少带宽消耗。性能问题排查一般过程：按照问题发生的概率和投入产出比来说，一般情况下，会按照下图逻辑进行性能问题排摸和调优。在解决SQL和应用配置问题后，基本已经解决了 90%左右的性能问题了。 Top 10 SQL缓冲区命中率-用户互兗过爭
4、很丈内容繁琐*进程池世源背理*连接池设宜业务逻辑冗余数押心地化忖放无效/兀命盍引*表空间怕息* JVM/GCS略 活动连接徽数据库与 sql 排查注意点排查数据库和sql语句的问题。常通过获取top 10 sql来定位最耗资源的sql语句，并 分析sql语句来确认性能问题。数据库常见的性能问题表现为数据库服务器CPU过高。以 oracle 为例，列举一些常见问题：1）数据表/字段没有索引或sql查询时，某条件不在索引上：这个问题在新系统的测试环 境上最为常见，常常是开发新建了表或字段，忘了加索引。加上索引即可修复。2）表锁、行锁，这个是应用和数据库的共同问题，常见于几种情况（包含但不限于）：a
5、）最常见：Select for update之后没有及时commit掉。b）对某一张大表进行大量或全量update的时候没有分批进行，而是一次性update并 commit，并且对该表的读取方式未使用脏读模式。c）自增订单号没有使用sequence，而是通过数据库内某字段做控制。在大并发的情 况下，对一条记录进行频繁的 update3）数据表有索引，sql查询的时候，索引未生效，一般索引未生效有以下原因（包含但不 限于），需要逐一排查：a）使用不等于!= 或运算符b）使用 like 的时候百分号/下划线等通配符在前，例如 %_c）数据发生很大变动之后，表没进行分析，可通过表分析或强制索引解决d
6、）单独引用复合索引里的部分索引列，会不走索引或导致索引效果下降e) 字符型字段为数字时在where条件里不添加引号，隐式数据转换导致索引失效f) 在where条件中对索引列进行函数运算，如trim(),如需对字段进行函数处理，则要 建立函数索引.g) 对索引列使用not in ,not exist运算符h) 日期时间类字段做索引，在查询的时候等号两边数据类型不一致，导致隐式数据转 换导致索引失效，例如datatime查timestamp或者字符串查timestamp。很多大公 司的编码规范中都完全抵制使用日期时间类字段作为索引。i) 使用了 is null导致索引(尤其是复合索引)失效，建议字
7、段不要为NULL,用0、 特殊值或空字符串来代替j) 跨表空间查询导致索引失效，建议对单个表空间进行查询后，用 union 联合查询4) sql未经优化，例如使用多层嵌套查询，group by中使用了 having等问题5) 缓冲区命中率低于90%，一般来说，缓冲区命中率应该要高于90%，最好在95%以上6) 表数据过大，未进行分表或分表空间。尤其是对于一些交易记录表，历史交易记录 表、日志表等数据表应用服务器参数排查注意点出现任何性能问题之后，除数据库外，最应该排查的内容应当是对应用服务器的配置 参数排查，一般排查以下问题： java内存/堆栈：未设置最大内存会导致服务器当大量并发发生时，无
8、休止的使用 内存和虚拟内存导致服务器资源耗尽。缺省值一般无限制或128m-256m 进程池/连接数：未设置最大连接数会导致当大量并发发生时，无休止的产生新连 接/线程去处理请求，最终导致服务器资源耗尽。最大连接数设置过小，也会导致 大量外链无法接入系统，返回连接超时。另外连接超时时间也不能配置的过大。 java内存GC：过于频繁的GC会对服务器的cpu产生持续性压力，并且会影响内 存数据的可靠性，gc间隔时间过长也会导致GC时cpu使用率产生井喷时增长。 因此如果需要调整gc策略，需要找到平衡点 日志配置：建议将日志按照天输出进行配置，并且重定向到指定磁盘或目录，并 定期清理，避免由于日志输出
9、导致磁盘满的情况。 日志级别：系统运行时，建议日志级别调低，尽量只打印error级别的日志。 系统核心参数：一般常见于ulimit -a相关参数和sysctl.conf相关参数，用于控制系 统级别的资源使用极限，经常容易忘记配置的是ulimit中的open files(-n)参数， linux的系统默认是1024，实际作为服务器使用时远远不够的。另外ulimit参数分 系统级别和用户级别，都需要设置正确 数据库连接池：这里单独拿出来是因为经常会遇到一种情况，即应用连接池很 大，而数据库连接池却只有5-10甚至更小，当产生大量耗时的数据库查询时，请 求的处理链就会阻塞在数据库查询上导致服务器资源
10、耗尽，应用崩溃，而数据库 层面却没有任何异常产生。应用服务器代码排查注意点如果数据库和应用配置都没有问题，那就需要排查应用本身的代码问题了。一般来 说，如果能在项目开发代码编写的时候就考虑性能问题，会让代码的总体性能和质量都得 到比较大的提升。从性能测试角度，一般建议注意以下问题：如果是自己开发（含二次开发）的线程池，要考虑内存溢出，异常或者代码导致连接未释放多线程的问题。 系统构架设计时，要小心并行转串行的逻辑模块会成为最主要的瓶颈。 对于一些数据库读写极其频繁的应用，可以考虑使用数据库长连接的方式。 尽可能的减少递归的使用，好的递归能提高效率，但写的不好的递归会极大消耗服 务器资源。 字符
11、串拼接时，避免使用+号而是使用 StingBuilder 尽量减少正则表达式的使用对于连接，流等对象，有open就要有close，例如磁盘10,网络10,数据库连接 等。在处理异常时，如果能用选择判断，尽量不要使用try catch除非不得已，否则不要在循环中使用try catch，应该把其放在最外层（个人深刻体 会） 如果可以，循环内尽量不要创建对象引用 除非必要，程序运行中尽量避免使用反射，反射机制真的效率很差避免一次性载入过大的数据/文件到内存，以免撑爆jvm，建议使用缓冲区读取的方式 如果要使用嵌套循环，建议在使用前多做业务逻辑分析和确认，避免由于逻辑错误 产生冗余循环 前端尽量对非敏感数据、不经常变化的数据、页面资源、脚本文件等采用客户端缓 存，减少服务器和客户端的互交数据量和互交过程。 java写日志的时候，禁止使用system.out,必须使用框架提供的日志写入类常见性能测试监控工具枚举分析性能测试工具枚举分析.xlsx
性能测试问题排查及调优的常规思路
