性能瓶颈情况总结

一般瓶颈分以下五种情况：

1. 硬件上的性能瓶颈
一般指的是CPU，内存，磁盘I/O方面的问题，分为服务器硬件瓶颈，网络瓶颈（对局域网可以不考虑），服务器操作系统瓶颈（参数配置），中间件瓶颈（参数配置，数据库，web服务器等），应用瓶颈（sql语句，数据库设计，业务逻辑，算法等）。
(1) 磁盘I/O：磁盘的读写速度远慢于内存的读写速度，系统运行时如果需要等待磁盘I/O的完成，将导致整个系统的性能下降；
(2) CPU性能：应用对CPU的占用时间不同，应用时间对CPU的抢占也将导致系统性能受到影响；
(3) 网络状态：网络本身存在不确定性，其读写速度可能比磁盘I/O还要慢，所以网络状态也可能成为系统性能的一个瓶颈；
(4) 异常的处理：Java对异常的捕获和处理是一项非常消耗资源的操作；
(5) 数据库的读写：当应用可能进行海量数据的读写时，数据库操作将带来想不到的时间消耗，可能影响整个系统的响应；
(6) 锁竞争：在高并发的程序中，对锁的竞争必将产生很大的上下文切换开销，对系统造成的性能影响也是不可小觑的；
(7) 负载承受能力：一个应用可能同时会接收到上百万的访问请求，这时应用将面临巨大的响应压力，可能导致服务器宕机；
(8) 内存大小：有时候内存过小可能导致一些操作无法完成，导致系统崩溃，这时也可能为了解决内存不足问题采用分布加载资源到内存中，这又导致了磁盘I/O问题。

2. 应用软件上的性能瓶颈
一般指的是应用服务器，web服务器等应用软件，还包括数据库系统；
例：中间件weblogic平台上配置的JDBC连接池的参数设置不合理，造成的瓶颈。

3. 应用程序上的性能瓶颈
一般指的是开发人员新开发出来的应用程序；
例：程序架构规划不合理，程序本身设计有问题（串行处理，请求的处理线程不够）造成系统在大量用户访问时性能低下而造成的瓶颈。

4. 操作系统上的性能瓶颈
一般指的是windows，UNIX，Linux等操作系统；
例：在进行性能测试，出现物理内存不足时，虚拟内存设置也不合理，虚拟内存的交换效率就会大大降低，从而导致行为的响应时间大大增加，这时认为操作系统上出现性能瓶颈。

5. 网络设备上的性能瓶颈
一般指的是防火墙，动态负载均衡器，交换机等设备；
例：在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经达到极限时，动态负载均衡器将后续的交易请求发送到其他负载轻的应用服务器上，在测试时发现，动态负载均衡器没有起到相应的作用，这时可以认为网络瓶颈。

性能瓶颈的具体表现：

性能瓶颈出现频次	具体表现
高	TPS波动较大
高	高并发下大量报错
中	集群类系统，各服务节点负载不均衡
中	并发数不断增加，TPS上不去，CPU耗用不高
低	压测过程中TPS不断下降，CPU使用率不断降低

1. TPS波动较大
原因分析：出现TPS波动较大问题的原因一般有网络波动、其他服务资源竞争以及垃圾回收问题这三种。
性能测试环境一般都是在内网或者压测机和服务在同一网段，可通过监控网络的出入流量来排查；
其他服务资源竞争也可能造成这一问题，可以通过Top命令或服务梳理方式来排查在压测时是否有其他服务运行导致资源竞争；
垃圾回收问题相对来说是最常见的导致TPS波动的一种原因，可以通过GC监控命令来排查，命令如下：

#实时打印到屏幕
 jstat  -gc  PID  300  10
 jstat  -gcutil  PID  300 10
 #GC信息输出到文件
 jstat  -gc  PID  1000  120  >> /path/gc.txt
 jstat  -gcutil  PID  1000  120  >> /path/gc.txt

调优方案：
网络波动问题，可以让运维同事协助解决（比如切换网段或选择内网压测），或者等到网络较为稳定时候进行压测验证；
资源竞争问题：通过命令监控和服务梳理，找出压测时正在运行的其他服务，通过沟通协调停止该服务（或者换个没资源竞争的服务节点重新压测也可以）；
垃圾回收问题：通过GC文件分析，如果发现有频繁的FGC，可以通过修改JVM的堆内存参数Xmx，然后再次压测验证（Xmx最大值不要超过服务节点内存的50%！）

2. 高并发下大量报错
原因解析：出现该类问题，常见的原因有短连接导致的端口被完全占用以及线程池最大线程数配置较小及超时时间较短导致。
短连接问题：修改服务节点的tcp_tw_reuse参数为1，释放TIME_WAIT socket用于新的连接。
线程池问题：修改服务节点中容器的server.xml文件中的配置参数，主要修改如下几个参数：

 #最大线程数，即服务端可以同时响应处理的最大请求数
 maxThreads = "200"
 #Tomcat的最大连接线程数，即超过设定的阈值，Tomcat会关闭不再需要的socket线程
 maxSpareThreads = "200"
 #所有可用线程耗尽时，可放在请求等待队列中的请求数据，超过该阈值的请求将不予处理，返回Connection refused错误
 acceptCount = "200"
 #等待超时的阈值，单位为毫秒，设置为0时表示永不超时
 connectionTimeout = "20000"

3. 并发数不断增加，TPS上不去，CPU使用率较低
原因分析：SQL没有创建索引/SQL语句筛选条件不明确，代码中设有同步锁，高并发时出现锁等待
SQL问题：没有索引就创建索引，SQL语句筛选条件不明确就优化SQL和业务逻辑
同步锁问题：是否去掉同步锁

4. 集群类系统，各服务节点负载不均衡
原因分析：出现这类问题的原因一般是SLB服务设置了会话保持，会导致请求只分发到其中一个节点。
调优方案：如果确认是如上原因，可通过修改SLB服务（F5/HA/Nginx）的会话保持参数为None，然后再次压测验证；

5. 压测过程中TPS不断下降，CPU使用率不断降低
原因分析：一般来说，出现这种问题的原因是因为线程block导致，当然不排除其他可能；
调优方案：如果是线程阻塞问题，修改线程策略，然后重新验证即可；

常见性能瓶颈

• 吞吐量到上限时系统负载未到阈值：一般是被测服务分配的系统资源过少导致的。测试过程中如果发现此类情况，可以从ulimit、系统开启的线程数、分配的内存等维度定位问题原因
• CPU的us和sy不高，但wa很高：如果被测服务是磁盘IO密集型型服务，wa高属于正常现象。但如果不是此类服务，最可能导致wa高的原因有两个，一是服务对磁盘读写的业务逻辑有问题，读写频率过高，写入数据量过大，如不合理的数据载入策略、log过多等，都有可能导致这种问题。二是服务器内存不足，服务在swap分区不停的换入换出。
• 同一请求的响应时间忽大忽小：在正常吞吐量下发生此问题，可能的原因有两方面，一是服务对资源的加锁逻辑有问题，导致处理某些请求过程中花了大量的时间等待资源解锁；二是Linux本身分配给服务的资源有限，某些请求需要等待其他请求释放资源后才能继续执行。
• 内存持续上涨：在吞吐量固定的前提下，如果内存持续上涨，那么很有可能是被测服务存在明显的内存泄漏，需要使用valgrind等内存检查工具进行定位。

参考博客：https://www.cnblogs.com/imyalost/p/10850811.html