性能瓶颈分析思路

性能分析是一个大课题，不同的架构、不同的应用场景、不同的程序语言分析的方法各有差异，抽象一下大致分为二类：

自底向上：通过监控硬件及操作系统性能指标（CPU、内存、磁盘、网络等硬件资源的性能指标）来分析性能问题（配置、程序等的问题）。因为用户请求最终是由计算机硬件设备来完成的，做事的是 CPU。

自顶向下：通过生成负载来观察被测试的系统性能，比如响应时间、吞吐量；然后从请求起点由外及里一层一层的分析，从而找到性能问题所在。

不管是自底向上还是自顶向下，关键点就是生成负载、监控性能指标。上面我们说了两种方法，大家会问哪一种方法更好呢？哪种方法更简单一点呢？我想说的是方法无所谓好坏，只是一个思路。

对于没有经验的性能测试工作者，提倡自底向上；对于经验丰富的性能测试工作者，先用自顶向下的方式解决掉明显性能问题，再接合自底向上的方式分析更深层次的问题。

性能分析流程

从性能测试工程师的角度来讲解一下通常的性能分析过程（操作系统以Linux为例）。

序号	步骤名称	说明
1.0	检查RT	模拟用户发起负载后，采用自顶向下的方式首先分析RT（响应时间）。 1.如果RT小，TPS大，说明性能良好。 2.如果RT小，TPS小，检查负载机资源占用情况，确定是否要加大负载。 3.如果RT大，TPS小，检查负载机的资源消耗，确保不是负载机的性能原因导致的RT变大。
1.1	检查TPS	1.TPS大时RT小，说明性能良好 2.TPS小时RT大，检查负载机的资源消耗，确保不是负载机的性能原因导致的RT变大。
2.0	检查负载机资源消耗耗	1.检查CPU使用率，CPU负载（LoadAverage）确认是用户CPU占用高还是系统CPU占用高？确认测试脚本没有性能问题，不会造成结果统计的不准确 2.检查内存使用情况，确认并发内存泄露风险，不会造成结果统计的不准确。 3.检查网络占用带宽。大家可以做个小实验，一台并发100用户，一台运行一个用户，比较两者的响应时间是否在同一个数量级，从而评估负载机对性能的影响。
2.1	判下负载机是否有性能问题	排除负载机的性能问题，确保测试结果可参考。
3.0	检查Web 服务器的资源消耗	1.检查CPU使用率，确认用户CPU与系统CPU占用情况 1.1系统CPU占用多，检查系统调用情况，找出是哪个进程或线程，确认调用是否正常？比如滥写日志，导致系统CPU利用率高。 1.2用户CPU高，找出进程或线程，定位到程序，确认是否调用正常？一般来说Web服务程序不涉及到运算的，CPU利用率高要确认是否是其它资源等待导致的CPU利用率高。 1.2.1比如IO等待会带来CPU利用率高，CPU由于等待IO，而频繁的进行上下文切换。 1.2.2比如事务过程较长，需要锁定的资源较多，而请求也较多时，CPU需要不停的中断、上下文切换去处理获取到资源的请求。 2.检查内存使用情况，找出占内存多的进程或线程 3.检查磁盘使用情况，找出IO量大的进程或线程 4.检查占用的带宽 5.分析Web页面响应的时间组成
3.1	确认是否 Web服务器瓶颈	从3.0监控指标判断是否是Web服务器硬件性能瓶颈。
3.2	检查中间件配置	1.检查中间件线程池活动连接数，确认是否是此配置问题。 2.检查Heap配置，确认gc的影响。
3.3	是否是中间件限制	1.监控线程池活动连接数，确认线程池够用。 2.监控线程状态，如果长期是Blocked状态，可能是响应慢，有可能会导致死锁，Dump线程栈找到疑问程序。 3.监控JVM，关注GC，评估Heap空间是否够用。
4.0	检查APP 服务器资源消耗	分析方法同3.0。
4.1	确认是否 App服务器瓶颈	从3.0监控指标判断是否是App服务器硬件性能瓶颈
4.2	检查中间件配置	1.检查中间件线程池。 2.检查数据库连接池。 3.检查Heap配置。
4.3	是否是中间件限制	1.监控线程池，确认线程池够用。 2.监控线程状态，如果长期是Blocked状态，代表响应慢，有可能会导致死锁。 3.监控与数据库的连接数，确认数据库连接池是否够用。 4.监控JVM，关注GC，评估Heap空间是否够用。可以借助JVisualVM、 Jprofiler来分析，也可以使用Jdk自带的监控命令。
5.0	数据库服务器资源消耗分析	1.CPU消耗，CPU负载。 2.内存消耗。 3.IO繁忙程度。 4.数据库监控 4.1慢查询。 4.2对DB不熟悉的读者可以找DBA帮忙监控分析。
5.1	是否是DB 性能问题	由5.0的监控结果来判断是否是DB性能问题。

linux主机瓶颈阀值分析

CPU定位分析

模块

类型

度量方法

衡量标准

CPU

使用

情况

通过vmstat 统计1-id 的计数
通过top统计1-id的计数

注意>=50% 告警>=70% 严重>=90%

CPU

满载

vmstat 的r计数 > CPU逻辑颗数
top, "load average" > CPU逻辑颗数

运行的队列大于cpu逻辑颗数时，证明已经有一定的负载了，不过这个计数也不绝对，需进一步分析其他的资源情况来断定是否

CPU已经满负荷运作

我们可以用的命令有vmstat， top ,sar，dstat， mpstat, ps 等命令来进行统计分析。

vmstat 字段含义说明：

类别	项目	含义	说明
Procs（进程）	r	等待执行的任务数	展示了正在执行和等待cpu资源的任务个数。当这个值超过了cpu个数，就会出现cpu瓶颈。
Procs（进程）	B	等待IO的进程数量
Memory(内存)	swpd	正在使用虚拟的内存大小，单位k
	free	空闲内存大小
	buff	已用的buff大小，对块设备的读写进行缓冲
	cache	已用的cache大小，文件系统的cache
Swap	si	每秒从交换区写入内存的大小（单位：kb/s）
Swap	so	每秒从内存写到交换区的大小
IO	bi	每秒读取的块数（读磁盘）	现在的Linux版本块的大小为1024bytes
IO	bo	每秒写入的块数（写磁盘）
system	in	每秒中断数，包括时钟中断	这两个值越大，会看到由内核消耗的cpu时间会越多
system	cs	每秒上下文切换数	这两个值越大，会看到由内核消耗的cpu时间会越多
CPU（以百分比表示）	Us	用户进程执行消耗cpu时间(user time)	us的值比较高时，说明用户进程消耗的cpu时间多，但是如果长期超过50%的使用，那么我们就该考虑优化程序算法或其他措施了
	Sy	系统进程消耗cpu时间(system time)	sys的值过高时，说明系统内核消耗的cpu资源多，这个不是良性的表现，我们应该检查原因。
	Id	空闲时间(包括IO等待时间)
	wa	等待IO时间	Wa过高时，说明io等待比较严重，这可能是由于磁盘大量随机访问造成的，也有可能是磁盘的带宽出现瓶颈。

内存定位分析

模块	类型	度量方法	衡量标准
内存	使用情况	free命令查看使用情况 vmstat命令查看使用情况	注意>=50% 告警>=70% 严重>=80%
内存	满载	vmstat 的 si/so 比例辅助 swapd和free利用 sar –W 查看次缺页数查看内核日志有无 OOM 机制 kill进程 dmesg \| grep killed	OOM机制

我们可以用的命令有 vmstat，sar，dstat， free, top , ps 等命令来进行统计分析。

free 字段含义说明：

参数	释义
total	内存总数，物理内存总数
used	已经使用的内存数
free	空闲的内存数
shared	多个进程共享的内存总额
buffers/cache	缓存内存数
available	可用内存数
Swap	交换分区，虚拟内存

网络定位分析

模块	类型	度量方法	衡量标准
网络	使用情况	ifstat 的收发计数大于网卡上限 iftop RX/TX带宽超过网卡上限 nicstat的 util 基本满负荷
网络	满载	ifconfig dropped 有计数 netstat –s "segments retransmited"有计数	统计的丢包有计数证明已经满了
网络	错误	ifconfig, "errors" netstat -i, "RX-ERR"/"TX-ERR"	错误有计数

衡量系统网络的使用情况，我们可以使用的命令有ifstat,iftop,netstat以及查看net的速率，通过查看发现收发包的吞吐速率达到网卡的最大上限，网络数据报文有因为这类原因而引发的丢包

阻塞等都证明当前网络可能存在瓶颈。在进行性能测试时为了减小网络的影响，一般我们都是在局域网中进行测试执行。

nicstat命令详解

磁盘IO定位分析

模块	类型	度量方法	衡量标准
IO	使用情况	iostat –xz , "%util" iotop 的利用率很高	注意>=40% 告警>=60% 严重>=80%
IO	满载	iostat -xnz 1, "avgqu-sz" >1 iostat await > 70	IO 已经有满载嫌疑
IO	错误	dmesg 查看io 错误 smartctl /dev/sda	有信息

衡量系统IO的使用情况，我们可以使用的命令有sar, iostat,iotop等命令进行系统级的IO监控分析。当发现IO的利用率大于40%时候，就需要注意了，当使用率大于60%则处于告警阶段，大于80%IO就会出现阻塞了。

iostat -x命令详解

选项	说明
rrqm/s	每秒对该设备的读请求被合并次数，文件系统会对读取同块(block)的请求进行合并
wrqm/s	每秒对该设备的写请求被合并次数
r/s	每秒完成的读次数
w/s	每秒完成的写次数
rkB/s	每秒读数据量(kB为单位)
wkB/s	每秒写数据量(kB为单位)
avgrq-sz	平均每次IO操作的数据量(扇区数为单位)
avgqu-sz	平均等待处理的IO请求队列长度
await	平均每次IO请求等待时间(包括等待时间和处理时间，毫秒为单位)
svctm	平均每次IO请求的处理时间(毫秒为单位)
%util	采用周期内用于IO操作的时间比率，即IO队列非空的时间比率

tomcat 性能监控和分析

连接器（Connector）的参数配置

HTTP/1.1：默认值，使用的协议与Tomcat版本有关
org.apache.coyote.http11.Http11Protocol：BIO
org.apache.coyote.http11.Http11NioProtocol：NIO
org.apache.coyote.http11.Http11Nio2Protocol：NIO2
org.apache.coyote.http11.Http11AprProtocol：APR

Attribute	描述
maxConnections	服务器在任何给定时间接受和处理的最大连接数。当达到这个数字时，服务器将接受一个进一步的连接，但不会处理。这个附加连接将被阻塞，直到正在处理的连接数降到maxConnections以下，服务器再次开始接受并重新处理新的连接。
acceptCount	所有可能的请求处理线程正在使用时，传入连接请求的最大队列长度。当队列满时收到的任何请求都将被拒绝。默认值为100。
connectionTimeout	连接器在接受连接后等待的请求URI行的毫秒数。使用值-1表示无（即无穷大）超时。默认值为60000（即60秒），但请注意Tomcat附带的标准server.xml将其设置为20000（即20秒）。除非disableUploadTimeout设置为false，否则读取请求主体（如果有的话）也将使用此超时。
keepAliveTimeout	连接器在关闭连接之前等待另一个HTTP请求的毫秒数。默认值是使用为connectionTimeout属性设置的值。使用值-1表示无（即无穷大）超时。
maxKeepAliveRequests	在服务器关闭连接之前可以进行流水线处理的最大HTTP请求数。将此属性设置为1将禁用HTTP / 1.0保持活动状态，以及HTTP / 1.1保持活动状态和流水线状态。将其设置为-1将允许无限量的流水线或保持活动的HTTP请求。如果未指定，则此属性设置为100。
executor	对Executor元素中的名称的引用。如果设置了此属性，并且命名的执行程序存在，则连接器将使用执行程序，并且所有其他线程属性将被忽略。请注意，如果未为连接器指定共享执行程序，则连接器将使用专用的内部执行程序来提供线程池。