结合“性能监视器” 排查、处理性能瓶颈致使应用吞吐率等指标上不去的问题

时间 2019-11-07

原文原文链接

双11备战前夕，总绕不过性能压测环节，TPS 一直上不去 / 不达标，除了代码上的问题外，服务器环境、配置、网络、磁盘、CPU 亦是致使性能瓶颈的重要一环，本文旨在分享最近项目性能压测过程当中的排查经验，文中的表单你能够做为排查手册保存，若有不对之处，还请在评论区分享、交流你的经验和观点：）html

原文地址（样式排版上更好点，另外文章的后续更新会及时体如今我的博客中） ：https://blog.zhuliang.ltd/2019/08/Performance/test-with-perfmon.htmllinux

经过本文，你能够了解和掌握：算法

了解常见的系统瓶颈的可能缘由。
经过性能探查器定位性能瓶颈。
几点关于性能优化的策略。
一份关于 windows 性能监视器的部分计数器翻译及对应的经验结论。

吞吐量和延时的关系

关于吞吐量/吞吐率、延时，你能够经过 Jmeter中的”聚合报告“和”用表格查看报告“来获取。数据库

Throughput 越大，Latency 越差：由于请求过多，系统繁忙致使响应速度下降。
Latency 的值越小说明能支持的 Throughput 越高：Latency 数值小说明系统处理速度快，天然即可以处理更多的请求。
Throughput "不用" 经过下降 latency 的方式来提升，排查性能问题的时候，勿在下降 Latency 值上消耗过多时间。

常见系统瓶颈：

类型转换：除了装箱拆箱外，还要着重看下 JSON 的一些转换类库，如 newtown，fastJson 等等，可能会引发 CPU 维持在高位。
异步操做：有些异步操做会很是影响性能，尤为是在网络较差的状况下，极可能阻塞业务。
- 如异步下的状态通知一般会影响性能。一般而言，异步操做会让”吞吐率“提高，但会牺牲延时（latency）。

定位性能瓶颈

定位的方式不必定是程序级别的，一开始能够先从操做系统的 CPU 使用率，内存使用率，系统 IO 和网络 IO，网络链接数着手分析。windows

CPU 使用率不高，可是 throughtput 和 latency 上不去： 说明程序没有忙于计算，可能问题在 I/O 上。
- 通常 CPU 和 IO 是反着来的： CPU 没问题，问题可能在 IO，反之亦然。
若是 CPU、IO、内存、网络带宽使用都不高，可是系统性能上不去： 说明程序有问题，多是为资源被锁，存在锁竞争关系，程序被阻塞；或者是在上下文切换等等。
关于 IO，要看 3 个方面：磁盘IO，网络IO 以及内存换页率。
程序级别的性能瓶颈定位：
- 分段注释代码 / 让一些函数空转 / 作一些硬编码的 Mock，而后再测试下 Throughput 和 latency，看是否有好转，若是有，说明函数是瓶颈，再进一步在这个函数体内注释代码，直到找到最耗性能的语句。
分析内存：须要用到的计数器：Memory 类别和 Physical Disk 类别的计数器，步骤以下：
1. 查看 Memory：Available Mbytes 指标：若是该指标的数据较小，系统可能出现了内存方面的问题，须要继续下面步骤进一步分析。
2. 注意 Memory：Pages/sec、Pages Read/sec 和 Page Faults/sec 的值：操做系统会利用磁盘较好的方式提升系统可用内存量或者提升内存的使用效率。这 3 个指标直接反映了 OS 进行磁盘交换的频度。
  - Pages/sec 值持续高于几百，可能内存有问题。Pages/sec 值大不必定就代表内存有问题，多是运行使用内存映射文件的应用致使。
  - Page Faults/sec 越高说明每秒发生页面次数越多，说明 OS 向内存读取的次数越多。此时须要查看 Pages Read/sec 的计数值，该值阈值是 5，超过 5，则能够判断存在内存方面的问题。
3. 根据 Physical Disk 计数器的值分析性能瓶颈：须要分析 Page Reads/sec 和 %Disk Time 及 Average Disk Queue Length 的分析。若是 Pages Read/sec 很低，同时 %Disk Time 和 Average Disk Queue Length 的值很高，则可能有磁盘瓶颈。可是，若是队列长度增长的同时 Pages Read/sec 并未下降，则是内存不足
分析处理器：
1. 排查 System：%Total Processor Time 计数器的数值：该值体现的是服务器 CPU 的总体利用率，对于多核系统而言，该值体现的是全部 CPU 的平均利用率。
  - 若是该值持续超过 90%，说明整个系统面临着处理器方面的瓶颈，须要增长处理器来提升性能。
  - P.S.：多核下，若是该数据不大，可是各个 CPU 的负载不均衡，也能够认为是 CPU 产生了瓶颈。
2. 排查每一个 CPU 的 Processor：%Processor Time 和 %User Time 和 %Privileged Time：
  - %Processor Time 很高时，通常 CPU 都阻塞着，可是反之并不亦然。
  - %User Time：非系统内核操做消耗的 CPU 时间（如调用系统自己资源--网络、IO等），若该值较大，能够考虑优化代码、优化算法；若是该服务器是数据库 Server，则该值较大的话多是数据库的”排序“或是”函数操做“消耗了过多的 CPU 时间，此时可考虑对 DB 进行优化。
  - %Privileged Time：系统内核操做消耗的 CPU 时间
3. 验证是否系统 CPU 瓶颈：
  - 查看 System：Processor Queue Length 计数器：若是该值大于 CPU 数量的总数 + 1 的时候，说明产生了处理器阻塞。
分析磁盘I/O：
1. 若是计算得出每一个磁盘的I/O 超过了磁盘自己的I/O能力，则能够确认磁盘是引发瓶颈的因素之一。
2. 与 Processor：%Privileged Time 联合分析：若是 Physical Disk：%Disk Time 较大，其余值比较适中，则硬盘多是瓶颈，若几个值都比较大，且持续超过 80%，则多是内存泄漏。
3. 分析 Disk sec/Transfer：通常来讲，该值小于 15ms 为最佳，15~30ms 为良好，30~60ms 为可接受，超过 60ms 则须要考虑更换硬盘或者更换 raid 方式了。
分析进程：
- 查看 Process：%Processor Time的值：每一个进程的该值反映的是进程消耗 CPU 的时间。
- 查看 Process：%Page Failures/sec 和 Memory：%Page Failures/sec 的比值，过滤出是哪一个进程产生的最多的页错误，通常这个进程是须要大量内存的进程，或者是很是活跃的进程（即在压测状况下，就是你要压测的进程）
- Process：%Private Bytes：该计数器指进程所占有的私有数据（单位字节），即没法与其余进程共享的数据量，能够利用该值来判断应用是否存在内存泄漏。
  - 对于 IIS 进程，能够重点监控下 INetInfo进程的 Private Bytes，若是在压测过程当中，该值不断增长，或是在压测结束后，该值仍然处于一个高水平，则说明应用存在内存泄漏
分析网络：
- Network Interface：Bytes Total/sec 为发送和接收字节的速率，能够经过该计数器值来判断网络连接速度是不是瓶颈，具体操做方法是用该计数器的值和目前网络的带宽进行比较。
- 联合 Processor：%Privileged Time 进行分析：若是 Physical Disk：%Disk Time比较大，其余值比较适中，则硬盘多是瓶颈，若几个值都比较大，且持续超过 80%，则可能存在内存泄漏。

性能优化的几个策略

应用层面：
- 善用 CDN，缓存，冗余数据，SLB。
- 若是瓶颈在网络传输，那么须要对传输数据进行压缩（须要注意，压缩算法是很耗时的，只在瓶颈是网络传输的时候再考虑，你须要根据测试数据自行权衡。）。
- 并行处理的时候须要注意下宿主机是不是多核。若是宿主机是单核的，而程序代码是多进程、多线程的，那么对于高计算密集型的应用会拔苗助长，反而更慢。
优化代码：
- 减小循环层数、减小递归。
- 在循环体中少作声明变量、分配 / 释放内存的操做：把循环体内的表达式抽离到循环体外。
- 注意函数调用在栈上的开销。
- 合理使用 try-catch：不要用抛异常做为常规业务的失败流程（如进行业务报错）。
- 字符串处理需注意：减小没必要要的声明实例（.net core 出了一个 Span 类型，能够用来替代 Substring。）
- 不一样的语言和代码库，对于复杂度是不同的，这个须要注意：如应该用 List.Count==0 来代替List.Any() 来判断是否有数据。
  - 关于这点，你可使用计数器来判断、测试本身写的代码在”耗时、Cpu Cycle，0/1/2代 GC回收“等数据的差别，择优而定。
算法调优：
- 哈希算法并不高效，使用时候还需注意。
- 善用预处理和份量分次分批处理：像月报表之类的执行频率低，但每次执行都很耗资源的，你能够尝试预先天天/每周处理，不用等到每个月才执行。
多线程调优：
- 多线程的瓶颈主要在互斥和同步锁上，以及线程上下文切换的成本上：你应尽可能少用甚至不用锁，或者用乐观锁替代现有直接用 Lock 的锁。
内存分配：当内存出现碎片时，会至关耗时。
- 在编码的时候，意识上尽量少的进行内存的分配。
池化技术对于一些短做业来讲至关有效：如 HttpClientFactory 就是用了 http 池，能够用来减小对象建立、线程建立的开销。
网络调优：
- TCP 很耗资源，对系统开销很大：你能够搜索关键字：TCP Tuning 进行相关调优
- TCP 和 HTTP 要配置下 Keep-Alive，尤为是像 http 这样的短链接，这也能够在必定程度上防止 DDoS攻击。
- 对于 TCP 的 TIME_WAIT，这个状态默认会持续 4 分钟（持续 2 个 MSL--Max Segment Lifetime），TIME_WAIT 状态下的资源不能回收，有大量 TIME_WAIT 链接的状况通常是在 HTTP 服务器上。
  - 你能够在注册表中新建、设置 TCP 的 TcpTimedWaitDelay 和 MaxUserPort 项，来增长 TCP 链接释放时间和临时端口数。
- TCP 一旦发生丢包，TCP 的带宽使用率会受到影响（盲目减半），再丢包，再减半；何时不丢包了，就会逐步恢复。
CPU 调优：
- CPU0 很关键，它通常担任着调节功能（如内核和非内核操做，上下文切换等），若是 0 号 CPU 被用得过狠的话，别的 CPU 性能也会降低。
  - windows 下可在“任务管理器”中，右键“进程”选择“设置相关性”来设置该进程能够运行在哪些核上。
  - linux：使用 taskset 命令来设置（能够经过安装 schedutils 来安装这个命令）。

性能监视器

在服务器上最直观监视性能的方式就是直接使用系统自带的”性能监视器“。缓存

>perfmon #直接在 "运行" 中输入 perfmon 便可打开

若要进一步监控内存，可结合使用 RAMMap 和 VMMap 。

windows 下计数器说明：

类别	计数器名称	描述	结论
Memory	Available M bytes	当前空闲物理内存。	当这个数值变小时，说明 windows 开始频繁地调用磁盘页面文件，若是这个数值很小（如小于 5Mb，系统会将大部分时间消耗在操做页面文件上），通常要保留 10% 的可用内存，此值太小多是内存不足或者内存泄漏。
	Pages/sec	是 Pages Input/sec 和 Pages Output/sec 总和。	Pages/sec 推荐 0-20，若是服务器没有足够的内存处理其工做符合，此值数值将会一直很高，若是大于 80 ，表示有问题（太多的读写数据要访问磁盘，可考虑增长内存或优化读写数据的算法），该系列的值比较低，说明请求响应比较快，不然多是服务器内存短缺引发（也多是缓存太大，致使系统内存太少。）通常若是Pages/sec 持续高于几百，那么应该进一步研究页交换活动。有可能须要增长内存，以减小换页的需求。Pages/sec 的值很大不必定代表内存有问题，而多是运行使用内存映射文件的程序所致。计数器的比率高表示分页过多。
	Pages Read/sec	读取磁盘，以提取解决页错误所需页的次数。	其阈值为 5，该值越低越好（越低，说明响应时间越短）；该值大表示磁盘读，而非缓存读。若是 Page Reads/sec 持续保持为 5，表示可能内存不足。
	Page Faults/sec	该值表示页错误的个数：当处理器向内存指定位置请求一页（多是数据，也多是代码）出现错误时，这就构成了一个“页错误”。若是该页在内存的其余位置，该错误就被称为软错误（用 Transition Fault/sec衡量）；若是该页必须从硬盘上从新读取时，被称为硬错误。	许多处理器能够在有大量软错误的状况下继续操做，而硬错误会致使明显的拖延。当进程使用的数据所处的内存页不在内存中时，就会产生该值。若是某页已经在主内存中，或者它正被共享此页的其余进程使用，那么就不会从磁盘调入该页。
	Cache Bytes	分配在RAM中的驻留页面数。	默认状况下为 50% 的可用内存。
	Committed Bytes	指以字节表示的确认虚拟内存，是磁盘页面文件上保留空间的物理内存。	不超过物理内存的 75% 。
Process	%Processor Time	处理器消耗的处理器时间，若是专用于某种特定应用（如数据库服务器和应用服务器），则可用应用相关进程 %Process Time 进行衡量。	可接受的上限通常不超过 85% 。
	Page Faults/sec	将进程产生的页故障与系统产生的相比较，以判断该进程对系统页故障产生的影响。
	Working Set	表示进程正在使用的物理内存的量。（至因而具体进程仍是全部进程，须要看监控实例是具体的仍是全部的。）	系统在工做集中的内存页进行寻址的时候，不会引起 Page Fault。另外，若是服务器有足够的空闲内存，页就会留在工做集中，而当空闲内存少于一个特定的阈值时，页就会被清除出工做集中。
	Private Bytes	此进程所分配的没法与其余进程共享的当前字节数量。若是系统性能随着时间而下降，则此计数器能够是内存泄漏的最佳指示器。
Processor	%Processor Time	指处理器执行非闲置线程时间的百分比。此计数器能够做为处理器活动的主要指示器。（%Processor Time = 100% - Idle Process时间比例）	若是该值持续超过95%，代表瓶颈是 CPU，能够考虑增长或更换更快的处理器。正常状况下，保持在 80%±5% 比较好，太低说明 CPU 利用率不高，太高表示是瓶颈是 CPU。虽然该计数器高不必定是坏事，但若是其余处理器相关的计数器（如 Privileged Time 或者 Processor Queue Length）线性增长的话，高 CPU 使用率就值得调查了。
	%User Time	非内核操做耗费的CPU时间。通常来讲，若是系统中使用了大量的算法或者复杂的计算操做，该值就会比较大。
	%Privileged Time	这个计数器表示一个线程在特权模式下所使用的时间比例，当你的程序调用操做系统的方法（如文件操做，I/O 或者分配内存）时，这些操做系统的方法就是在特权模式下运行的。	若是数值持续大于 75% 就表示存在瓶颈。
	%DPC Time	CPU 消耗在网络处理上的时间。	该值越小越好。若是持续高 %DPC 时间，则可能存在 CPU 瓶颈或应用程序或硬件相关问题。
	%Interrupt Time	表示 CPU 接收、处理硬件中断所使用的时间比例。	阈值取决于处理器。通常，当该值 >15% 的时候说明可能存在硬件问题。这个值间接指出产生中断的硬件设备活动，好比网络变化。这个计数器显著增长的话表示硬件可能存在问题
	Interrupts/sec	中断率，表示每秒设备中断 CPU 的次数，能够产生中断的装置包括：系统定时器，鼠标，数据通信联网，网络卡以及其余外部设备等。中断操做在后台完成。	该值阈值取决于处理器，但越低越好，不宜超过 1000，若是该值显著增长而系统活动没有相应的增长，则代表存在硬件问题，须要检查引发中断的网络适配器、磁盘或其余硬件。
Physical Disk	%Disk Time	指所选磁盘驱动器忙于读/写入请求所用的时间百分比。	正常值<10，此值过大表示耗费太多时间来访问磁盘，可考虑增长内存、更换更快的硬盘、优化读写数据的算法。若数值持续超过 80（此时处理器和网络并无饱和），则多是内存泄漏。
	Current Disk Queue Length	是在收集性能数据时磁盘上当前的请求数量。它还包括在收集时处于服务的请求。这是瞬态的快照，不是时间间隔的平均值。此计数器会反映暂时的高或低的队列长度，可是若是磁盘驱动器被迫持续运行，它有可能一直处于高的状态。	请求的延迟与此队列的长度减去磁盘的轴数成正比。为了提升性能，此差应该平均小于 2。
	Average Disk Queue Length	指读取和写入请求的平均数。该值不该超过磁盘数的 1.5~2倍。要提升性能，可增长磁盘。注意，一个Raid Disk 实际有多个磁盘。	正常值应小于 5，此值持续过大表示磁盘 IO 太慢，要更换更快的硬盘。建议结合 Pages /sec 一块儿分析，看是内存分页过多致使磁盘一直在读写仍是就是磁盘问题。
	Average Disk Read/Write Queue Length	指读取/写入请求（队列）的平均数。
	DiskRead(Writes)/sec	物理磁盘上每秒磁盘读、写的次数。	二者相加，应该小于磁盘设备最大容量。
	Average Disk sec/Read	指以秒计算的在磁盘上读取数据所需的平均时间。
	Average Disk sec/Write	指以秒计算的在磁盘上写入数据所需的平均时间。
Network Interface	Bytes Total/sec	为发送和接受字节的速率，包括帧字符在内。判断网络链接速度是不是瓶颈，能够用该计数器的值和目前网络的带宽比较。	建议不要超过带宽的 50% 。
System	%Total Processor Time	系统上全部处理器都忙于执行非空闲线程的平均时间的百分比，该值反映了用于有用做业上的时间的比率。对单处理器系统来讲，该值很容易理解；对多处理器来上，该值体现了全部处理器的平均繁忙程度。eg：若是全部处理器都繁忙，此值为 100%，若是有一半的处理器繁忙，另外一半处理器彻底空闲，此值为 50%。
	File Data Operation/sec	计算机对文件系统设备执行读取和写入操做的速率。本计数器的计数不包括文件控制文件。
	Processor Queue Length	处理器队列的线程数量，该计数器显示的是等待中的线程数量，不包括正在运行的线程数量。	在 CPU 利用率 80~90% 的系统中，该值应为 "*[1,3] 处理器数量**"：如在一台 8 核处理器，该值在 [8, 24] 区间范围内算正常；而在 CPU 利用率较低的系统上，该值应为 [0,1]，若持续大于 2，就有可能碰到了问题资源，须要进一步排查。
	Call/sec	指运行在计算机上的全部处理器调用操做系统服务例行程序的综合速率，这些例行程序执行全部在计算机上的如安排和同步活动等基本的程序，并提供对非图形设备、内存管理和名称空间管理的访问。	该值跟 Processor.Interrupts/sec 联合使用，若是 Processor.Interrupts/sec 大于 Call/sec，则说明系统中某一硬件产生了过多的终端。
	Context Switches/sec	进程切换率，指计算机上的全部处理器所有从一个线程切换到另外一个线程的综合速率。产生上下文的可能状况：当正在运行的线程自动放弃处理器时出现上下文切换；一个有更高优先级的线程取代一个正在运行的低优先级线程的时候会发生上下文切换；在用户模式和内核模式之间切换时产生上下文切换。	通常，该值小于 5000/秒/CPU 是不须要担忧的。若是Context 该值达到 15000/秒/CPU 的话就是一个制约因素了，须要看下是否代码致使（如过多的异步操做）。P.S.：上下文切换一样会发生在许多线程拥有相同优先级的状况，若是 CPU 使用率不高且 Context Swtich 很是低，那么可能线程被堵塞。
Web Service	Current Connections	当前链接数（针对到 IIS 实例）。	结合压测用户/线程数进行分析。
	Current Anonymous Users	当前匿名链接数。	结合压测用户/线程数进行分析。
	Current NonAnonymous Users	当前非匿名用户/匿名链接数。	结合压测用户/线程数进行分析。
	Get/Put/Post Requests/sec	使用Get/Put/Post 方式 HTTP 请求的速率。

参考性能优化

提升 IIS/P2P 并发数，请参见：(经过设置注册表提升 P2P/IIS 并发数)[https://blog.zhuliang.ltd/2019/09/Performance/tcpip-max-limit.html]

Processor queue length：https://social.msdn.microsoft.com/Forums/vstudio/en-US/356b87a3-e8b1-48ad-9355-e68ce3eef754/processor-queue-length?forum=vstest服务器

Interrupt Time 说明：https://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc718984(v=msdn.10)网络

性能计数器：http://www.appadmintools.com/documents/windows-performance-counters-explained/多线程