共计 2752 个字符，预计需要花费 7 分钟才能阅读完成。
简介：本文从大量的性能诊断实际登程，来介绍 SysAK 在性能诊断上的方法论及相干工具。
文 / 张毅：零碎运维 SIG 核心成员、SysAK 我的项目负责人；毛文安：零碎运维 SIG 负责人。
零碎运维既要业务稳固的运行，又要最大化的利用资源，因而对于利用性能的评估也是重要的一环，作为零碎运维的利器，SysAK 天然少不了这方面的能力。但对于利用性能的诊断，有时比稳定性问题更难，非专业人员甚至有无从下手的感觉。本文从大量的性能诊断实际登程，来介绍 SysAK 在性能诊断上的方法论及相干工具。
SysAK 利用性能诊断办法
简而言之，SysAK 诊断利用性能的基本思路就是自顶向下并进行关联拓展。
自上向下即利用 ->OS-> 硬件，关联拓展则包含同级利用、零碎影响、以及网络拓扑。说起来简略，但施行起来却是一个大工程。
1、利用画像
首先做的就是利用画像，要对利用的性能进行诊断，首先要对其进行画像，包含其业务吞吐、系统资源应用等，而后再依据画像中占比比拟大的性能瓶颈进行逐个专项剖析。具体来说，包含利用的并发数、运行和睡眠的统计。并发数简略，统计业务工作数就行了，这个次要是为前面的资源应用作为参考。
1.1、运行统计
即对系统根底资源的利用进行分类统计，利用运行时根底资源占用就 4 类：
Cpu
通过 cpu 占用可知利用自身的吞吐是否高，并进一步通过 user/sys 的 cpu 占比可得悉业务运行时更多的是在业务本身还是在内核资源的应用上。所以此处至多要蕴含运行时长、以及 user、sys 的各自比例。如果 sys 占比高，须要持续剖析对应内核资源是否有异常情况，否则更多时候须要剖析硬件资源上是否有瓶颈。
内存
通过内存的应用状况来判断内存的申请与拜访是否是制约业务性能的因素。所以此处至多要蕴含内存调配总量、频率、缺页次数、跨 NUMA 节点拜访次数和大小等的统计。
文件
通过文件拜访的状况来判断文件 IO 是否是制约业务性能的因素。此处至多要蕴含文件读写频率、pagecache 命中率、均匀 IO 时延等的统计。
网络
通过报文流量来判断网络是否是制约业务性能的因素，此处至多要蕴含流量统计、对端链接的网络拓扑等。
1.2、睡眠统计
如果利用运行周期内，睡眠工夫占比很大，则很可能是影响业务性能的关键因素，此时就要剖析睡眠的详细情况了。至多要蕴含三类行为的数据统计，包含具体行为的次数和时长：
被动睡眠：这类数据如果占比过高，则阐明是利用本身行为。用户临界资源竞争：这些数据如果占比过高，则须要优化利用。内核资源期待：这类数据如果占比过高，则须要剖析具体的零碎内核资源瓶颈。在有了利用画像当前，咱们就对利用运行过程中的根本状况有了理解，如果发现瓶颈不在业务本身，那么就须要持续往下剖析对应的系统资源或者硬件瓶颈了。
2、零碎内核资源
零碎内核资源制约利用性能的中央又可分为三大类：
2.1、烦扰
一个服务器操作系统运行过程中，对利用运行的干扰源可能会很多，但烦扰不肯定会对业务造成影响，所以至多须要蕴含这些干扰源的频率和运行工夫，来评估是否是关键因素。
至多须要包含以下干扰源的统计：
设施硬件中断
如果在业务运行过程中，某一类中断频率过高或者集中到某个 cpu，或者单次单次运行过过长，那么都都可能会影响到业务的性能，能够对中断进行打散绑定等操作察看成果。
零碎定时中断
零碎定时器过多，也可能会对业务的唤醒造成提早，通常能够剖析业务过程是否有大量的应用高精度定时器。
软中断
可能是网络流量是否有突发减少等。
内核线程
其余高优先级利用
2.2、瓶颈
零碎内核资源品种繁多，利用模型不同，对内核资源的依赖也不同，所有瓶颈点无奈齐全笼罩，但至多须要蕴含几大类常见的内核资源的统计数据：
运行队列长度
这个能够表明是否业务过程 / 线程并发过多，或者是否绑核不合理等
fs/block 层时延
对于不同的文件系统或设施、IO 调度算法，可能会有不同的瓶颈点，通常须要进行分段统计时延来确定
内存调配延时
受内存水位、碎片的影响，内存调配的时延有时可能会很大
pagefault 时长与频率
内存缺页导致的内存申请、重映射、tlb flush 等对的开销是十分大的，如果频繁的进入到 pagefault 流程中，能够思考从利用策略上进行优化，比方预分配内存池、应用大页等。
要害门路 kernel 锁的竞争
锁是不可避免的机制，kernel 态锁竞争通常会导致 sys 态的 cpu 升高，须要联合上下文进行具体分析。
2.3、策略
上述提到内核资源无奈齐全笼罩，但能够有另外一种办法去能观测一些数据，因为不同的内核策略可能有比拟大的性能差别，所以能够尝试通过不同零碎间的比照，找出配置的差别点。通常的系统配置采集如下：
内核启动参数
内核配置接口 sysctl/procfs/sysfs
内核模块差别
cgroup 配置
3、虚拟化
当上述找不到瓶颈点时，或者咱们想持续开掘性能的剩余价值，通常就会到硬件这一侧，而目前业务部署在云上居多，所以在深刻硬件层前，虚拟化层或者说主机侧也是绕不开的必要因素。对主机侧的性能剖析，针对零碎内核资源制约能够复用上述的办法，但对业务画像能够少做不少事，绝对于利用业务，虚拟化这层的逻辑不会有限变动，咱们能够从各个渠道理解到云厂商提供的虚拟化计划，目前支流的是 Linux kvm 计划。因而能够针对性的对 kvm 这个计划所所及到的技术点做特地剖析。此处应该蕴含的统计包含：
qemu 线程的被抢占频率及工夫、guest 陷出频率及事件、qemu 线程在 host 上运行的工夫
通过这些来综合判断是否是因为虚拟化层带来的性能损失或者是否有改善的可能性。
4、硬件性能
最初，真正到了硬件层，到这里通常都是因为单纯从应用层或者零碎层无奈找到更多的优化空间了。其实又有两种思路，一种是看看硬件利用率的点，看是否反向调整利用，对硬件应用的热点缩小依赖或者扩散利用；另一种就是利用无奈调整了，评估硬件的性能是否真正已到瓶颈。对于前者，又能够延长出一套方法论来，比方 Ahmed Yasin 的 TMAM，在 sysAK 中不做过多延长，但依然有必要的工作要做，除 cache、tlb miss、cpi 这些数据采集外，更要害的是怎么将这些数据联合利用过程的运行状况进行剖析，比方同一 cpu 上的 cache 或带宽竞争多，是因为以后业务本身的程序设计，还是有其余过程存在争抢导致，对于争抢导致的能够通过绑核、rdt 等技术进行配合优化。
5、交互的应用环境
还没完，这里还少了一个拼图，当初绝大多数利用都不是单机的，交互的利用之间也会产生性能影响，因而在利用画像中，咱们曾提到过网络连接的拓扑，就是用于此。咱们能够将上述所有的性能诊断办法在和以后利用进行交互的对象上复制一遍。
总结
最初的最初，以一张大图来进行总结。
而图中波及的工具将会在后续的实战篇中呈现，敬请期待。
原文链接
本文为阿里云原创内容，未经容许不得转载。
