性能问题汇总
Posted lynnetest
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了性能问题汇总相关的知识,希望对你有一定的参考价值。
1. 压测端硬件、网络或软件
问题1:域名压测导致大量请求流向外网,并出现流量清洗
现象:测试结果显示tps非常低,请求量压测端统计与服务端统计相差很大
解决思路:
确认压测域名是否走内网IP,ping + 压测域名获取到的ip地址与运维确认是否为内网ip,若不支持ping(腾讯云机器不支持ping)可尝试tracert。
确定未走内网可能需要运维协助,在入口机器(nginx)配置host将域名指定到某台或多台服务器上。
问题2:jmeter测试报告显示出现各种异常报错信息,如500、502、Non Http responsecode
现象:控制台错误请求量增加、测试报告显示相应错误提示、错误
解决思路:确定错误类型,根据错误类型寻找错误真实原因。
Non HTTP response code: java.net.ConnectException,java.net.ConnectException,一般是连接超时(查日志)。从几个方面排查,脚本问题、网络、服务器承受能力到了极限(监控系统资源),并发量超过系统处理能力会出现这种情况(可参考http://confluence.sui.work/pages/viewpage.action?pageId=13182064)
问题3:jmeter Jvm分配内存不足导致内存溢出
现象:控制台出现报错,出现OutOfMemoryError
解决思路:
Windows中对应的文件路径:Jmeter_Home/bin/jmeter.bat
set HEAP=-Xms512m -Xmx512m
set NEW=-XX:NewSize=128m -XX:MaxNewSize=128m
Linux下对应文件路径:Jmeter_Home/bin/jmeter
HEAP=-Xms512m -Xmx512m
NEW=-XX:NewSize=128m -XX:MaxNewSize=128m
通常就meter默认的HEAP -Xms512:初始化内存大小,-Xmx512m:最大堆内存。需要增加内存的时候需要注意
- 一般会将-Xms和-Xmx两个值配置为相同值,目的是为了能在java的GC完成后堆内存不需要重新分隔计算堆区大小而浪费资源
- -Xms和-Xmx两个值修改的值一般需要为512的整数倍
- -Xmx不要超过物理内存的50%,超出可能会导致jmeter变慢
- 当脚本执行过程中出现内存溢出outfmenmory错误,先尝试增加增加HEAP的-Xms和-Xmx
- JDK32位的电脑Xmx不能超过1500m,最大1378m.否则在启动Jmeter时会报错
- -XX:NewSize:新生代初始内存大小,该值一定要小于—Xms
- -XX:MaxNewSize:新生代可被分配的内存的最大上限,这个值应该小于-Xmx的值,因为新生代占内存来自整个堆内存通常设置为-Xmx的三分之一
- jvm在执行GC时,会停止工作。MaxnewSize的增大,可以降低GC频率
问题4: 端口被占用
现象:并发6000次/s,错误率高达66.89%
错误日志:Non HTTP response code:java.net.BindException,Non HTTP response message: Address already in use
原因:Jmeter windows压测环境:Windows Server 缺失MaxUserPort和TcpTimedWaitDelay;限制了tcpip最大连接数和响应时间
解决办法:注册表HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/ Services/TCPIP/Parameters;添加MaxUserPort和TcpTimedWaitDelay,分别设置值为65534、30,以增大可分配的tcp连接端口数、减小处于TIME_WAIT状态的连接的生存时间
2. 服务器硬件、网络
问题1:压测方式使用的是域名压测,走的外部网络,所以压测压力未能如预期一样对目标服务器施压,导致TPS非常低,服务器各种资源消耗也很小。
现象:使用单台压测机器分别进行了100、500、1000进程压测,500个线程的时候tps只有180-200,再增加压力Tps上不去。
解决思路:一开始以为服务器连接数有问题,修改Tomcat最大连接数无效果。最后统计压测端请求量与被测服务器接收请求量相差比较大
解决方式:网络入口配置host/dns的形式将指定域名的请求全部指向测试服务器(对应IP)
问题2:原有集群到达最大极限,TPS达到280左右就出现CPU适应过高的情况
现象:2台web和4台service在调整配置、代码优化出现瓶颈,使用单台压测机器分别进行了100、500、1000进程压测,500个线程的时候tps达到280位最高并发,90%响应时间最小而且CPU等资源正常,增加并发数到1000后tps降低、响应时间增加CPU使用率>70%
解决方法:增加集群机器
3. 中间件
问题1:Nginx入策略配置不平均,后端4台服务器负载不均衡,导致压测时其中一台cpu使用率远远高于其他3台
解决:优化Nginx轮训策略,默认使用的轮训算法修改成安权重分配
问题2:Nginx入口未开启长连接,导致TPS上不去
现象:增加并发数,tps、响应时间无太大增长,服务器资源消耗都在正常范围内,TPC连接数中出现大量time-wait,tomcat已开启长连接配置,可以确定是入口长连接配置没生效
- keepalive_timeout 20s; #一个keepalive 连接被闲置以后还能保持多久打开状态
- keepalive_requests 1000; #一个客户端可以通过一个keepalive连接的请求次数。
问题3:Tomcat连接处瓶颈,导致高并发时出现接口超时
现象:500线程组并发的时候,服务端日志出现大量超时提示,排查Tomcat线程数配置的时候发现maxThreads(线程池中最大活跃线程数)为100。
解决:修改maxThreads、accept-count为500后错误解决
- maxThreads:最大请求进程数,默认设置为200,该值设置应该考虑实际情况,当
请求进程数达到最大值时,一般会出现错误提示:SEVERE: All threads (150) are currently busy, waiting. Increase maxThreads (150) or check the servlet status
- accept:可接队列长度,与maxThreads对应,当达到maxThreads后进入等待队列。而等待队列数达到最大值后,再有新请求后就会出现refuse connection(拒绝请求)
问题4:. 502 Bad Gateway和504 Gateway Time-out
问题定位:tomcat的参数配置问题
解决办法:调整tomcat配置文件server.xml的配置:主要是最大线程数、最大建立连接数和最长连接时间。
问题扩展:Nginx或腾讯云LB代理模式下后端tomcat服务器出现问题引起的。首先,检查Nginx/腾讯LB或者tomcat的配置参数;其次,检查tomcat应用服务器的内存、CPU和代码BUG导致的。服务端栗子:方法内部RPC 调用,并发大,方法可用率下降,同时调用次数也会急剧上升。系统外部服务的接入层,对接逻辑容器时,应该添加缓冲队列,最好异步。
问题5:未开启长连接
- keepAliveTimeout=300000 <!--没有请求保持长连接的时间ms -->
- maxKeepAliveRequests=50000 <!--长连接能保持的请求数 -->
问题6:dubbo参数优化
现象:随着压测并发线程数递增,tps未能如预期中同步正向增长,达到峰值出现一定的下降。在调整了Tomcat配置参数后进一步优化其他中间件配置
dobbo:protocol-服务提供者协议配置:
- name :协议名称
- port :dubbo协议默认端口为20880,如果配置为-1或没配置port,则会分配一个没被占用的端口
本次调优主要关注一下内容:
- heartbeat :心跳间隔,对于长连接当物理层断开(如拔网线,TCP的FIN消息未能及时发送,对方收不到断开事件此时就需要心跳检查连接是否断开)
- dispatcher :协议的消息派发方式,用于指定线程模型,比如:dubbo协议的all, direct, message, execution, connection等
- threadpool : 默认fixed,线程池类型,可选:fixed/cached
- threads : 服务线程池大小,默认值为100
dubbo:reference-服务消费者引用服务配置:
本次性能优化主要关注内容
- connections :对每个提供者的最大连接数,rmi、http、hessian等短连接协议表示限制连接数,dubbo等长连接协表示建立的长连接个数
- timeout :服务方法调用超时时间(毫秒),缺省使用<dubbo:consumer>的timeout。
问题7:JVM优化
现象:TPS每隔段时间就降为0
问题定位:(1)监控tcp的连接数,等待数;(netstat -an |grep 6222 | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}‘)(2)查看服务端FULL GC的次数(过多,FULL GC会导致所有线程)
解决办法:JVM调优+ tomcat参数调优
1、取消飞行记录模式,去除参数(-XX:+UnlockCommercialFeatures -XX:+FlightRecorder)
2、jdk1.8 下取消了-XX:PermSize=500m-XX:MaxPermSize=500m
3、垃圾回收机制改成G1模式(堆内存被划分为固定大小的多个区域,存活的对象从一块区域转移到另一块区域,这样可以进行垃圾回收的同时不停止其他应用程序线程)
JVM的常用参数如下:
-Xms设置初始化堆的最大值
-Xmx 设置堆的最大值
PS:-Xms和-Xmx一般是相同的,可以减少Full GC的频率,最大可以到服务器总内存的80%
-Xmn 设置年轻代的大小(年老代=最大值-年轻代),一般为最大值的1/3左右。
问题8:java 启动脚本优化
4. 数据库、缓存等
问题1:DB 优化
(1)优化sql,尽可能少使用join、or 语句,select 出来的字段是必需的字段。
(2) 优化索引,让每条select 都走索引
(3) 设置连接池的最大连接数,设置为10000/14 = 700, (10000 为项目使用的mysql 最
大连接数,14 为机器数)
(4)尝试测试不同的连接池,选择性能最佳的,如图4 为数据库连接池性能测试,最
终确定选择hikari。
(5)不使用数据库事务,因为数据库操作代码都在消费者中,在代码中做幂等性。
查询一条语句性能测试(ms)
问题2:Redis优化
1、优化redis 存储数据结构
将db 中的数据load 保存为redis 的hash 结构(全表保存),根据业务优化redis 存储
结构,减少redis 查询次数(例如将phone 和券code 的领取状态单独存储)。
2、redis cpu为单核,进行分片处理
大量查询会成为严重短板,通过hash 值进行分片处理,因为项目不存在热点key 的问
题。优化过后redis 能够承受的量是之前的3 倍。
3、设置redis最大连接数
Redis 最大连接数设置为:3*10000/14 = 2100(这里乘以3 是因为微利项目有三台redis)
问题3:mq 优化
1、优化mq 消息
消息体一般为redis key,可以去redis 拿取数据,优化消息存储大小。按功能不同,拆
分多个队列,加快单逻辑处理速度,微利项目根据业务拆分为5 个队列。
2、加快消费者消费速度
增加消费者数量为20 个,根据下游(DB、业务方)TPS 多次测试得出,可以利用消费者数
量控制下游的负载。
增加消费者预读取数据数量为50 个,从而减少网络请求次数。
优化消费逻辑,完善幂等操作(解决消息重复消费问题),db 操作,业务查询操作。
问题4:Redis连接池瓶颈
优化后的配置:
redis.pool.maxTotal=5000
redis.pool.maxIdle=100
redis.pool.minIdle=50
关键参数说明:
maxTotal:资源池中最大连接池,默认值8
- 最大连接数的配置需要结合实际情况进行调整,而考虑的关键因素包括:
- 业务要求Redis达到的并发量
- 客户端执行命令时间
- Redis资源:如应用个数*maxTotal不能超过Redis的最大连接数
- 资源开销:控制空闲连接,尽量使连接池的频繁创建、释放造成不必要的开销
例如:
假如一个命令的平均耗时是1ms,一个连接的QPS(Redis每秒执行指令数)大约1000,而业务要求QPS(每秒执行请求数)是50000。
理论上资源池最大连接池设置应该为50000/1000=50个,但是实际设置上可以比理论值稍大。需要注意的是该值不是越大越好,一是连接太多需要占用客户端和服务端更多资源另一个是Redis假如出现阻塞资源池再大也没作用。
maxIdle:资源池允许最大空闲的连接数,默认值8
minIdle:资源池确保最少空闲的连接数,默认值0
- maxIdle:实际上才是业务需要的最大连接数,该值不能过大(不能大于maxTotal)或过小(过小会导致新增Redis连接开销),而minIdle是为了控制空闲资源监测
备注:以上均参考自https://yq.aliyun.com/articles/236383
问题5:DataSource参数优化
spring.datasource.initialSize=10
spring.datasource.minIdle=10
spring.datasource.maxActive=200
spring.datasource.maxWait=60000
- initialSize,连接初始值,连接池启动时创建的连接数量的初始值
- maxActive,连接池的最大值,同一时间可以从池分配的最多连接数量,0时无限制
- maxIdle,最大空闲值.当经过一个高峰时间后,连接池可以慢慢将已经用不到的连接慢慢释放一部分,一直减少到maxIdle为止,0时无限制
- minIdle,最小空闲值.当空闲的连接数少于阀值时,连接池就会预申请去一些连接,以免洪峰来时来不及申请
问题6:领券接口gainTPS 2W/s达到瓶颈
问题现象:6台tomcat服务器+3台redis-cache+2台redis-MQ的TPS仅有2W/s,和理论值6k(单台tomcat的最大值)有差距。
问题定位:(1)增加一台redis-cache,TPS没有改观,初步断定redis-cache存在瓶颈。(2)代码分析:发现gain接口里面有大量的increment操作;热点key避免产生瓶颈落在不同的redis上,但increment时所有的机器都来竞争操作这个key,造成瓶颈。(3)查看redis的监控,发现4台redis-cache中有1台的CPU达到100%,其他3台都在80~90%,形成木桶效应。
解决办法:increment主要是为了实时统计领券量,并显示在看板上方便监控数据。非核心业务,可以去掉increment操作,改成通过elk日志统计。
问题7:热点key达到瓶颈
典型的瓶颈问题:并发量大时,操作同一个key(热点key),hash的方式可能会落在同一台redis服务器,达到单台redis服务器的瓶颈。
存在问题的场景:理财市场登录预热(除夕红包活动开始前把所有开户信息加载到缓存中)
解决办法:对热点key进行加工和计算。理想的情况下,集群中有N个缓存节点,那么加工后的key也应该有N个。
问题8:Jms消费慢
问题现象:压测gain接口,jms消息有堆积
优化点:1、redis用的公共组件,有加锁;2、gain接口会产生两台msg消息,分别丢进两条队列(一条入库,一条调腾讯接口),同步改成异步;(3)一个线程取消息多个线程消费-》改成多个线程取消息多个线程消费
问题9:spdata分发有延时
问题现象:云上的数据向IDC推送数据用到了JMS消息,并发量大,容易延时(已知问题)。
影响范围:理财仅响应运营系统发奖,卡牛和微粒影响了云上的兑换,导致用户体验不好。
解决办法:spdata分发的方案不变,再增加方案:领取时前端已加密串形式保存QQ用户信息,给兑换奖券时用。
问题10:日志优化(通过日志分析不出来)
1、异步写日志文件
2、减少日志打印,例如正常请求仅打印入参和出参
3、kafka+ELK
问题11:spdatad多业务方数据源问题,导致预演并发量时,卡牛和微粒的数据未下发,不能兑换奖券(线上问题)
问题原因:for循环按业务下推数据,每次先推动理财的;如果理财有下推数据,最后会clear掉dataSource,导致其他业务查询为空;如果理财未下推数据,不会调用clear,正常推送其他业务;
代码如下:
解决办法:dataSource从上文传下来,避免执行clear时,dataSource被清空
规避方法:增加多业务的性能测试场景(跨公司的压测资源和环境受限);
问题12. 业务繁忙(线上问题)
问题原因:
(1)网络原因,例如:静态资源文件未放运营商CDN服务器、网络慢或异常;
(2)receive_api未获取QQ:openid(小概率事件),服务端重新请求腾讯接口获取QQ用户openid,生成数字验签错误;
(3)腾讯云问题,联合腾讯压测初步解决。
以上是关于性能问题汇总的主要内容,如果未能解决你的问题,请参考以下文章