1、TPS波动较大
原因解析:出现TPS波动较大问题的原因一般有网络波动、其他服务资源竞争以及垃圾回收问题这三种。
·性能测试环境一般都是在内网或者压测机和服务在同一网段,可通过监控网络的出入流量来排查;
·其他服务资源竞争也可能造成这一问题,可以通过Top命令或服务梳理方式来排查在压测时是否有其他服务运行导致资源竞争;
·调优方案:网络波动问题,可以让运维同事协助解决(比如切换网段或选择内网压测),或者等到网络较为稳定时候进行压测验证;
·资源竞争问题:通过命令监控和服务梳理,找出压测时正在运行的其他服务,通过沟通协调停止该服务(或者换个没资源竞争的服务节点重新压测也可以);
·垃圾回收问题:通过GC文件分析,如果发现有频繁的FGC,可以通过修改JVM的堆内存参数Xmx,然后再次压测验证(Xmx最大值不要超过服务节点内存的50%!)
2、高并发下大量报错
原因解析:常见的原因有短连接导致的端口被完全占用以及线程池最大线程数配置较小及超时时间较短导致。
调优方案:
·短连接问题:修改服务节点的tcp_tw_reuse参数为1,释放TIME_WAIT scoket用于新的连接;
·线程池问题:修改服务节点中容器的server.xml文件中的配置参数。
3、集群类系统,各服务节点负载不均衡
原因解析:出现这类问题的原因一般是SLB服务设置了会话保持,会导致请求只分发到其中一个节点。
调优方案:可通过修改SLB服务(F5/HA/Nginx)的会话保持参数为None,然后再次压测验证;
4、并发数不断增加,TPS上不去,CPU使用率较低
原因解析:SQL没有创建索引/SQL语句筛选条件不明确、代码中设有同步锁,高并发时出现锁等待;
调优方案:
·SQL问题:没有索引就创建索引,SQL语句筛选条件不明确就优化SQL和业务逻辑;
·同步锁问题:是否去掉同步锁,有时候不仅仅是技术问题,还涉及到业务逻辑的各种判断,是否去掉同步锁,建议和开发产品同事沟通确认;
5、压测过程中TPS不断下降,CPU使用率不断降低
原因解析:出现这种问题的原因可能是因为线程block导致,当然不排除其他可能;
调优方案:如果是线程阻塞问题,修改线程策略,然后重新验证即可;