介绍：本文从大量的性能诊断实践出发，介绍SysAK在性能诊断方面的方法论和相关工具。文/张毅：系统运维SIG核心成员，SysAK项目负责人；毛文安：系统运维SIG负责人。系统运维既需要业务稳定运行，又需要最大限度地利用资源。因此，对应用程序性能的评估也是重要的一环。作为系统运维的利器，这方面自然少不了SysAK。然而，应用性能的诊断有时比稳定性问题更难，非专业人士甚至会觉得无从下手。本文从大量的性能诊断实践出发，介绍SysAK在性能诊断方面的方法论和相关工具。SysAK应用性能诊断方法简而言之，SysAK应用性能诊断的基本思路是自上而下和相关扩展。从上到下依次为应用->操作系统->硬件，相关扩展包括同级应用、系统影响、网络拓扑。这听起来很简单，但实施起来却是一项大工程。1、应用画像首先要做的是应用画像。对应用的性能进行诊断，首先要对其进行剖析，包括其业务吞吐量、系统资源占用等，然后根据画像中占比较大的性能瓶颈一一进行。特别分析。具体来说，它包括有关并发应用程序数、正在运行和正在休眠的统计信息。并发数简单，统计业务任务数即可，主要作为后期资源使用的参考。1.1.运行统计是对系统基础资源的使用情况进行分类统计。应用运行时的基本资源占用有4种：cpu可以通过cpu占用知道应用本身的吞吐量是否高，进一步可以通过user/sys的cpu比例知道业务运行时，更多的是业务本身或者内核资源的使用。所以这里至少应该包括运行时间以及user和sys各自的比例。如果sys占比高，需要继续分析对应的内核资源是否有异常，反之则更需要分析硬件资源是否存在瓶颈。内存使用内存使用情况来判断内存的申请和访问是否是制约业务性能的因素。因此，这里至少应该包括内存分配总量、频率、缺页次数、跨NUMA节点访问次数和大小统计。文件通过文件访问判断文件IO是否是制约业务性能的因素。这里至少要统计文件读写频率、pagecache命中率、平均IO延迟等。网络根据报文流量判断网络是否是制约业务性能的因素，至少要包括流量统计和对端链路的网络拓扑结构。1.2.睡眠统计如果睡眠时间在应用程序运行周期中所占比例很大，那么很可能是影响业务性能的关键因素。这时候就要分析睡眠的细节了。至少应该包括三类行为数据统计，包括具体行为的次数和持续时间：Activesleep：如果这类数据占太多，说明是应用本身的行为。用户关键资源竞争：如果这些数据的比例过高，则需要优化应用程序。内核资源等待：如果此类数据占比过高，需要具体分析系统内核资源瓶颈。有了应用画像之后，我们就对应用运行过程中的基本情况有了一个了解。如果发现瓶颈不在业务本身，则需要继续分析相应的系统资源或硬件瓶颈。2.系统内核资源系统内核资源制约着应用程序的性能，可分为三类：2.1．干扰服务器操作系统的运行。应用运行的干扰源可能有很多，但干扰并不一定会导致业务受损。影响，所以至少需要包括这些干扰源的频率和运行时间，来评估是否是关键因素。至少需要包括以下干扰源的统计：设备硬件中断如果业务运行时某类中断频率过高或集中在某个CPU上，或者单次操作时间过长，可能会影响业务的性能，可以观察中断绑定等操作的效果。系统定时中断如果系统定时器过多，也可能造成业务唤醒延迟。通常可以分析业务流程是否使用了大量的高精度定时器。软中断可能是网络流量是否突然增加等。内核线程等高优先级应用2.2。瓶颈系统中存在多种类型的内核资源。不同的应用程序模型对内核资源的依赖性不同。不能完全覆盖所有瓶颈，但至少要包括几种常见的内核资源统计：运行队列的长度可以表示是否并发业务进程/线程过多，或者核心绑定是否不合理等。fs/block层延迟对于不同的文件系统或设备，IO调度算法可能会有不同的瓶颈，通常需要进行分段统计延迟来判断内存分配延迟受内存水位和碎片的影响，内存分配延迟有时可能非常大。Pagefault持续时间和频率内存页面错误导致内存请求、重新映射、tlbflush等，开销非常大。如果频繁进入pagefault过程，可以考虑优化申请策略，比如预分配内存池，使用大页等。keypath内核锁的竞争锁是一种必然的机制。内核态锁的竞争通常会导致sys态下cpu的增加，需要结合上下文来分析。2.3.策略上面说的内核资源并不能完全覆盖，但是还有一个方法可以观察一些数据，因为不同的内核策略可能会有比较大的性能差异，所以可以通过比较不同的系统来尝试找出。配置差异。通常的系统配置合集如下：内核启动参数内核配置接口sysctl/procfs/sysfs内核模块差异cgroup配置3.虚拟化在硬件方面，目前大部分业务都部署在云端，所以在深入之前硬件层、虚拟化层或主机端也是绕不开的必要因素。对于host端的性能分析，对于系统内核资源约束，可以复用上述方法，但是对于业务画像，可以做很多工作。与应用服务相比，虚拟化层的逻辑不会无限变化。渠道了解了云厂商提供的虚拟化方案，目前主流的是Linuxkvm方案。因此，可以针对kvm方案涉及的技术点进行专题分析。这里应该包含的统计信息包括：qemu线程被抢占的频率和时间，guesttrapping的频率和事件，qemu线程在宿主机上运行的时间。这些都是用来综合判断是不是因为虚拟化层造成的性能损失，或者是否有提升的潜力。4.硬件性能最后说到硬件层，通常是因为从应用层或者系统层没有更多的优化空间。其实有两种思路。一是看硬件使用率，看应用能不能反向调整，减少对硬件的依赖或分散硬件使用的热点。另一种是在应用程序无法调整时评估硬件的性能。是否真的到了瓶颈。对于前者，可以扩展一套方法论，比如AhmedYasin的TMAM，在sysAK中没有过多扩展，但还有必要的工作要做。除了cache、tlbmiss、cpi等数据采集外，更关键的是如何将这些数据与应用进程的运行状态结合起来进行分析。比如同一个CPU上有很多cache或者bandwidth的竞争，是因为现在的业务程序设计还是其他进程在竞争？通过corebinding、rdt等技术进行协同优化。5.交互应用环境还没有完成，还缺一块拼图。现在大多数应用都不是单机的，交互式应用也会对性能产生影响。所以在应用画像中，我们提到了网络连接的拓扑结构就是为了这个。我们可以在与当前应用程序交互的对象上复制上述所有性能诊断方法。最后总结一下，用一张大图来总结一下。图片中涉及的工具会在后续的实战章节中出现，敬请期待。原文链接本文为阿里云原创内容，未经许可不得转载。
