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

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

原文地址（样式排版上更好点，另外文章的后续更新会及时体现在个人博客中） ：https://blog.zhuliang.ltd/2019/08/operations/test-with-perfmon.html

通过本文，你可以了解和掌握：

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

吞吐量 和 延时的关系

关于吞吐量/吞吐率、延时，你可以通过 Jmeter中的”聚合报告“和”用表格查看报告“来获取。

• Throughput 越大，Latency 越差：因为请求过多，系统繁忙导致响应速度降低。
• Latency 的值越小说明能支持的 Throughput 越高：Latency 数值小说明系统处理速度快，自然便可以处理更多的请求。
• Throughput "不用" 通过降低 latency 的方式来提高，排查性能问题的时候，勿在降低 Latency 值上消耗过多时间。

常见系统瓶颈：

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

定位性能瓶颈

定位的方式不一定是程序级别的，一开始可以先从操作系统的 CPU 使用率，内存使用率，系统 IO 和 网络 IO，网络连接数 着手分析。

• 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 下计数器说明：

参考

• 提高 IIS/P2P 并发数，请参见：(通过设置注册表提高 P2P/IIS 并发数)[https://blog.zhuliang.ltd/2019/09/operations/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/