共计 7336 个字符，预计需要花费 19 分钟才能阅读完成。
性能剖析始终是性能施行我的项目中的一个难点。对于只做性能测试不做性能剖析的团队来说，总是不能把问题十分显性地展现进去，不能给其余团队十分明确的疏导。对于这种类型的测试施行，只能把问题抛出来，让其余相干团队去查。沟通老本很高。
而一个成熟的性能团队应该是要把问题点剖析进去，给其余团队或责任人十分明确的瓶颈点，以放慢问题的解决进度。
从残缺的剖析思路上思考。有两个要点：分段和分层。
如上图所示，分段就是要把 1-6 以及在 server1/2、DB 上耗费的工夫都统计进去。分层就是要把上图中各种不同色彩的层都剖析到。
能够应用的办法在不同的我的项目中各不一样，取决于利用的架构。
性能剖析的深度要到什么水平为宜呢？次要是看组织的构造和我的项目中波及到的人的职责定义。要把握的深度就是让各团队没有技术上的 Gap。这一点十分重要。
从理论的操作层面来说，因为性能次要是在大压力下是否能放弃住工夫的可接受性。所以次要把握如下几点：
1. 从响应工夫到具体的代码；
2. 从响应工夫到具体的 SQL；
3. 从响应工夫到具体的配置
有了这几个层面的剖析，基本上就能够确定一个问题的瓶颈点了。
在数据了解上，有两个阶段：
1. 晓得计数器的含意：
这个阶段看似简略，但能记得住那么多 performance counter 的人并不多，这个记不住倒是没有太大关系，遇到就查，多遇几次天然就记住了；
比方，对于上图来说，要了解的计数器就是 await 和 svctm，await 高是必定存在问题。如果要判断问题是重大不重大还要看另一个计数器就是 avgqu-sz，它是队列长度。svctm 是均匀每次 io 的工夫（单位：ms）。
再来看看 CPU 的计数器。
CPU 的计数器在 top 中有 8 个，在 mpstat 中多两个。在下面的计数器中，通常的说法是，us CPU 是用户态的，如果这部分高，通常是利用代码耗费的；sy CPU 是零碎态的，如果这部分高，通常是 os 层的配置有问题。
这种说法在大部分状况下是正当的，然而不论是 us CPU 还是 sy CPU，高和低都只是问题的体现。剖析到此并不是性能剖析的完结，上面要找到的就是为什么这么高？这一步是十分要害的。个别状况下，剖析门路是：
所以下一步就很清晰了，就是找哪个过程、线程耗费的 CPU 高，进而查到代码。
2. 晓得计数器的值之间的关系：
这个阶段大部分人都须要好几年的工夫能力齐全把握惯例的计数值，之所以说只能把握惯例的计数值是因为有一些数值的联动关系不是那么容易碰失去。
比如说 CPU 模式对 TPS 和 RT 的影响，大部分人都是拿到硬件的时候都是 Full performance mode 了，并不关怀还有没有其余的模式；比如说网络计数值导致的 TPS 有法则或无规律的抖动。
这些场景都要求做性能剖析的在看到某个计数值的时候能有间接的反馈，然而这一点十分难。因为数值的高下对大部分人来说就是一个谜，常常有人问这样的问题，这个值是高还是低，应该说只有不是一起工作的人都说不上来某个值是高还是低（当然对一些十分清晰的场景是比拟容易判断的），正当还是不合理。
如上图所示：procs 的 b 列很高，这个值的含意是等 io 的过程数，它在上图中和 CPU wa 列是对应的。同时，也和 IO 的 bi、bo 列是对应的，从这几个值关联来看下步是要看哪个过程耗费的 IO 多了。
能通过数据了解的这一档次，才算是到了中级性能剖析工程师的能力。
4.1 压力工具的曲线
做性能剖析，看曲线是最直接了当的。压力工具能够给咱们的明确的信息就是这个零碎是不是有问题的，这也是压力工具本身曲线能够明确显示的惟一的信息。请看上面几张图：
TPS 图：
响应工夫图：
递增线程图：
怎么了解这几张图呢？
先看张线程图。能够晓得多个业务都有设置并发递增线程。这个图能给的信息就是这个且只有这个。
联合 TPS 图能够晓得，在第三个梯度的时候，TPS 到了峰值。在第四个梯度的时候，TPS 曾经开始降落了。
再联合响应工夫图，在第三个梯度的时候，响应工夫是显著地抬了头。前面响应工夫在继续减少，每个梯度都有减少。
这时候有两件动作可做：
1. 批改场景接着测试。
如何批改场景？把线程数升高。降到在梯度减少的过程中，响应工夫没有明显增加的趋势之后再来看 TPS 是什么趋势。对于一个零碎来说，响应工夫有减少、TPS 没有减少（或有降落）、线程数有减少，这几个判断就明确阐明了零碎是有瓶颈的，并且也仅能阐明这一点。
2. 在以后场景下，剖析瓶颈点，看工夫耗费在哪个环节上。
这两个动作取决于指标，如果 TPS 在第三个梯度上曾经达到了业务指标，那能够不做优化。所以第一个动作的前提是 TPS 指标已达到。
显然，第二个动作就是 TPS 指标还未达到。
当然有人提出 TPS 指标达到了，有瓶颈也是须要优化呀？在这一点上，就要看做决定的人怎么思考了，因为优化是要付出老本的。接下来再说另一种曲线。
4.2 系统监控曲线。
因为操作系统级的监控有十分多的监控曲线，这里拿一个内存的来举例子。
内存曲线图：
对 linux 操作系统来说，操作系统的内存会缓缓被调配掉，变成 caching memory。所以如果只看 available memory 的意义并不大，须要 -/+ buffer/cache 之后再看可用内存。这一点大家都分明。
那么下面是不是说内存没有问题呢？当然不是。因为内存不仅被用光了，而且还断了一段，前面又有了数据，接着又用光，又断了一段时间。红色的框中，是有问题的，因为这一段连数据都没有抓到，抓数据的过程应该是没了。
所以 available memory 的降落并不是要关注的重点，-/+ buffer/cache 之后的 available memory 才是要关注的重点。另外从上图中看到的断掉的工夫点也是要剖析的重点。
另外，上图中，蓝框内内存始终在很低的状态，前面却忽然升高了那么多。这里也是要剖析的重点。
JVM 图
对 JVM 曲线来说，也是要看趋势的，基础知识是 jvm gc 的逻辑。YGC 始终在做，heap 始终在减少，这个过程是不是失常的呢？对于没有做过 Full GC 的 JVM 来说，heap 是有减少的趋势是能够了解的，然而这个“了解”须要一个前提，就是业务有没有增量。
如果是有业务的增量，上图就是失常的；如果没有业务增量，上图就是不失常的，那什么样的才是没有业务增量的失常呢？看下图：
上图就显著是个十分失常的 JVM。
对于曲线的了解，首先要晓得的是数据的起源和含意。在性能剖析中，有很多曲线的趋势都不是能够间接指明问题的，只能通过收集全副的信息来做残缺的剖析能力判断问题存在点。
下面举了两个例子的角度别离是：压力工具生成的曲线和后端服务器相应的工具生成的曲线。就是为了阐明一点：曲线剖析是在关注所有的层面。
间断三天，早晨在执行一个业务场景继续几个小时之后，就开始间断报错。服务器连不上了。但在报错的一开始，并不是全副都报错，而是有局部是能够胜利的，然而过一段时间之后，所有业务都报错了。次日来看，发现过程不见了。
原本认为是过程解体退出了，那日志中应该留下来些证据。然而关上了日志查看了一下，没有任何异样信息。间断三天都呈现。就登录 zabbix 下来看了一下主机资源。
红框内的是呈现问题的时间段。看到这里仿佛明确了为什么并不是所有业务都失败。因为内存还有回升的这个阶段。然而为什么降到底之后又下来，再次降到底呢？先看一下拓扑图。
两个主机，四个过程，既然过程都没了，应该不是一块没的，要不然不会还有业务能够胜利。
翻了一下利用日志，的确没有什么和过程隐没相干的错误信息。
既然是过程没了，日志也没信息，那下一步是什么呢？就是看 dmesg 了。系统日志总有些信息吧。过程死了无非就那么几个中央能看到。
4. 利用日志；
5. 出 dump；
6. 系统日志。
在这里揭示一下，最好间接运行 dmesg 命令，而不是去看 /var/log/dmesg 文件。因为命令中会把其余 message 也放进去，会全一点。
查看了 dmesg 之后，发现如下信息：
从工夫上来算一下。零碎运行工夫 41.45 天，的确和第一个图上的 21：30 的工夫对应得上。从这里来看是 6341 过程被杀了。
再看第二个图：
再来算一下工夫。41.55 天，和第一个图上的 11：45 能对得上。
看来是 OOM Killer 被动把这两个过程给杀了。从上面的信息来看是这两个过程耗费 linux 主机的物理内存和虚拟内存太大，以致于把内存都给耗费光了，最初 OOM Killer 就站进去主持公道了：小子挺横呀，老子分给你了一亩三分地，不好好呆着，敢来抢地盘，干它！
于是就真的被 kill 了。
既然晓得了内存耗费得多，那这个场景就好复现了。接着用原场景测试。看下 Java 过程的内存，Java 的内存分成堆内堆外。因为是操作系统的 OOM Killer 干掉的，所以基本上能够排除堆内的内存导致的。因为堆是有限度的嘛。
既然这样，那就是堆外。打个 threaddump 看看。
怎么这么多线程？并且也看到了开发的包名。
把这个门路给了开发之后，让他们翻翻这一段的源码，看到相似如下内容：Threadthread=newThread();（当然还有调用的代码，就不一一列举了）开发这才晓得是为啥有这么多新创建的线程。于是拿回去改去了。
用户递增图：
TPS 图：
通过查看网络连接状态，看到有大量的 TIME_WAIT 呈现。
尝试剖析过程如下:
1. 为 TIME_WAIT 批改 TCP 参数
通过查看 sysctl.conf，看到所有的配置均为默认，于是尝试如下批改：
- net.ipv4.tcp_tw_recycle = 1
- net.ipv4.tcp_tw_reuse = 1
- net.ipv4.tcp_fin_timeout = 3
- net.ipv4.tcp_keepalive_time = 3
回归测试，问题仍旧。
2. 批改 Nginx 的 proxyignoreclient_abort
思考到当客户端被动断开时，服务器上也会呈现大量的 TIME_WAIT，所以关上 proxy_ignore_client_abort，让 Nginx 疏忽客户端被动中断时呈现的谬误。proxy_ignore_client_abort on; 批改后，重启 Nginx，问题仍旧。
3. 批改 tomcat 参数
查看 tomcat 的 server.xml 时，看到只设置了 maxthreads。思考到线程的调配和开释也会耗费资源。所以在这里退出如下参数：maxKeepAliveRequests=”256″minSpareThreads=”100″maxSpareThreads=”200″。
重启 tomcat，问题仍旧。
4. 换 Nginx 服务器
在分段测试的时候，看到通过 Nginx 就会呈现 TPS 上到 300 就会降落的状况，所以思考是 Nginx 机器的配置问题，于是换了在另一台机器上从新编译了 Nginx，所有的操作系统都是一样的配置。
通过新的 Nginx 做压力，问题仍旧，所以能够判断这个问题是和操作系统的配置无关，和 Nginx 自身的配置无关。
5. 停掉防火墙
和网络连接无关的内容，剩下的就只有防火墙了。于是执行了：Serviceiptables stop。在执行了之后，看到 TPS 立刻就下来了。并且能够减少得十分高。从而定位，TPS 的降落和防火墙无关。
6. 系统日志
进到 /var/log，查看 messages，看到大量的如下信息：
11.Nov 4 11:35:48 localhost kernel: __ratelimit: 108 callbacks suppressed
12.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.
13.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.
14.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.
15.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.
16.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.
17.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.
18.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.
19.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.
20.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.
21.Nov 4 11:35:48 localhost kernel: nf_conntrack: table full, dropping packet.
22.Nov 4 11:35:53 localhost kernel: __ratelimit: 592 callbacks suppressed
23.Nov 4 11:35:53 localhost kernel: nf_conntrack: table full, dropping packet.
24.Nov 4 11:35:53 localhost kernel: nf_conntrack: table full, dropping packet.
25.Nov 4 11:35:57 localhost kernel: nf_conntrack: table full, dropping packet.
26.Nov 4 11:35:57 localhost kernel: nf_conntrack: table full, dropping packet.
27.Nov 4 11:35:57 localhost kernel: nf_conntrack: table full, dropping packet.
28.Nov 4 11:35:57 localhost kernel: nf_conntrack: table full, dropping packet.
29.Nov 4 11:35:57 localhost kernel: nf_conntrack: table full, dropping packet.
30.Nov 4 11:35:57 localhost kernel: nf_conntrack: table full, dropping packet.
31.Nov 4 11:35:57 localhost kernel: nf_conntrack: table full, dropping packet.
32.Nov 4 11:35:57 localhost kernel: nf_conntrack: table full, dropping packet.
33.Nov 4 11:35:58 localhost kernel: __ratelimit: 281 callbacks suppressed
34.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.
35.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.
36.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.
37.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.
38.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.
39.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.
40.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.
41.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.
42.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.
43.Nov 4 11:35:58 localhost kernel: nf_conntrack: table full, dropping packet.
44.Nov 4 11:36:14 localhost kernel: __ratelimit: 7 callbacks suppressed
7. 参数批改
因为呈现大量的 nf_conntrack:table full,dropping packet。所以在 sysctl.conf 中退出了如下参数设置。
45.net.netfilter.nf_conntrack_max = 655350
46.net.netfilter.nf_conntrack_tcp_timeout_established = 1200
批改参数后，执行：Serviceiptables start. 能够看到，TPS 依然能够很高，从而解决问题。
解决问题后的 TPS 图：上图中有两次 TPS 降落的过程是因为又尝试了批改防火墙的参数配置，重启了两次防火墙。
综上，对于性能剖析来说，不仅是景象的解释，还有瓶颈的定位及问题的解决。这些工作所要求的基础知识较多，一个人力不能及的时候，就须要一个团队来做。要害是要把问题剖析得清晰透彻。(end)
由霍格沃兹测试学院校长思寒老师、高楼老师以及来自腾讯、阿里巴巴的 BAT 多位资深性能测试技术专家联袂打造。3 个月大咖带你把握性能测试实战三大外围技能：性能压测体系、性能监控体系、性能剖析体系。一步步实战进阶，挑战性能之巅！
