案例1.TPS原因上不去 原因：磁盘满了 分析：**磁盘的监控 ** iostat -xm 5 (以兆为单位 5秒刷新一次)
rs,ws每秒读写情况 Await等待的时间 Svctm磁盘服务时间百分比 %util磁盘总占用率 （sda盘%util超过了80%,那么sda盘到了瓶颈） 解决：加硬件 2.TPS原因上不去 原因：系统采用spring架构的数据源，没有使用连接池而导致频繁FGC，TPS上不去 发现过程：先查通过jvm内存信息查看可疑对象，Mysql有连接池啊，为啥会有29万的实例信息 分析方法：：jmap -histco 打印整个 jvm实例和所占据的空间对象的信息 jmap -heap pid 解决方法：去掉msgpack0.6版本框架，采用java原成序列化框架，修改后tps，gc正常 建议方案：1.统一规范DB连接池 2.减少大对象，临时对象使用 3.频繁FGC
4、错误使用框架提供API 现象 某系统本身业务逻辑处理能力很快(研发本机自测tps可以到达2w 多) ,但是接入到framework框架后,TPS最高只能到达300笔/S左右, 而且系统负载很低 问题排查 根据这种现象说明系统可能是堵在了某块方法上,根据这种情况一 般采用线程dump的方式来查看系统具体哪些线程出现异常情况,通 过线程dump发现〔TIMED_WAITING〕状态的业务线程占比很高 案例3. 原因：错误使用架构提供的API 发现过程：本机自测tps达到2w，但是接入framework架构后TPS只能达到300笔/s，系统负载很低 全链路压测：压A系统的时候1000TPS，调用了其他系统的API权限校验，权限校验系统的 只有300只有拖慢了A系统的TPS下降 分析方法：可能堵在某块方法上，采用线程dump的方式来查看具体哪些线程出现异常， 通过线程dump发现【TIME_WAITNG】状态的业务占比很高 解决方法： 建议方案：只对A系统进行压测 案例4. 原因：慢SQL问题 一、现象：系统耗时长，TPS上不去 定位及方法：通过TCPRSTAT/orzdba/pt-query-digest 监控到请求平均时间在200-300ms，开启慢查 配置10ms
二、现象：依旧很简单的一个接口，查询列表接口，发现10并发单交易场景下，数据库表4w铺底数据，每次查询2000条数据进行orderby显示，平均响应时间2秒以上，数据库的cpu使用率高达95%； 分析：抓到这条sql语句： select *from table1 t1 left join table2 t2 on t1.id = t2.id where 1=1 and ....order by t1. .. 添加索引后，测试，发现平均响应时间0.5秒，tps提升4倍多，但是数据库的CPU的使用率依旧是95%以上, 原因：分析sql语句后，本来一句很简单的sql语句，检查了有检查，发现原因在t1.id = t2.id 这个上面，两张表关联的字段的字段类型不一样，一个是bigint型，一个是varchar型，导致了cpu资源消耗； 1、网络带宽 在压力测试中，有时候要模拟大量的用户请求，如果单位时间内传递的数据包过大，超过了带宽的传输能力，那么就会造成网络资源竞争，间接导致服务端接收到的请求数达不到服务端的处理能力上限。 2、连接池 可用的连接数太少，造成请求等待。连接池一般分为服务器连接池（比如Tomcat）和数据库连接池（或者理解为最大允许连接数也行）。 （关于连接池的具体内容，可参考之前的博客：性能测试：连接池和线程） 3、垃圾回收机制 从常见的应用服务器来说，比如Tomcat，因为java的的堆栈内存是动态分配，具体的回收机制是基于算法，如果新生代的Eden和Survivor区频繁的进行Minor GC，老年代的full GC也回收较频繁，那么对TPS 也是有一定影响的，因为垃圾回收其本身就会占用一定的资源。 4、数据库配置 高并发情况下，如果请求数据需要写入数据库，且需要写入多个表的时候，如果数据库的最大连接数不够，或者写入数据的SQL没有索引没有绑定变量，抑或没有主从分离、读写分离等， 就会导致数据库事务处理过慢，影响到TPS。 5、通信连接机制 串行、并行、长连接、管道连接等，不同的连接情况，也间接的会对TPS造成影响。 （关于协议的连接，可参考之前的博客：HTTP协议进阶：连接管理） 6、硬件资源 包括CPU（配置、使用率等）、内存（占用率等）、磁盘（I/O、页交换等）。 7、压力机 比如jmeter，单机负载能力有限，如果需要模拟的用户请求数超过其负载极限，也会间接影响TPS（这个时候就需要进行分布式压测来解决其单机负载的问题）。 8、压测脚本 还是以jemter举个例子，之前工作中同事遇到的，进行阶梯式加压测试，最大的模拟请求数超过了设置的线程数，导致线程不足。 提到这个原因，想表达意思是：有时候测试脚本参数配置等原因，也会影响测试结果。 9、业务逻辑 业务解耦度较低，较为复杂，整个事务处理线被拉长导致的问题。 10、系统架构 比如是否有缓存服务，缓存服务器配置，缓存命中率、缓存穿透以及缓存过期等，都会影响到测试结果。 标签：缓存,数据库,系统,案例,TPS,线程,解析,连接池 From： https://www.cnblogs.com/chentianjun/p/18112379