CPU|龙蜥利器:系统运维工具 SysAK的云上应用性能诊断

CPU|龙蜥利器:系统运维工具 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 , 或者单次单次运行过过长 , 那么都都可能会影响到业务的性能 , 可以对中断进行打散绑定等操作观察效果 。

相关经验推荐