直播回顾：准确性提升到 5 秒级，ssar 独创的 load5s 指标有多硬核？| 龙蜥技术

​简介： 你还在为分析机器负载高而苦恼？这款 ssar 工具独创 load5s 指标精准定位超硬核。

编者按：本文整理自龙蜥SIG技术周会，作者闻茂泉，阿里云计算平台事业部SRE运维专家，是龙蜥社区跟踪诊断SIG核心成员。本文带你了解 ssar 的基本功能和使用、初步学习用 ssar 解决单机 OS 问题的诊断。直播视频回放已上线至龙蜥社区官网：首页-支持-视频，欢迎观看。

一、系统性能分析工具 ssar 功能定位

说起性能分析就不得不提到《性能之巅》这本书，它是业界里程碑式的经典书籍。在书中第 4 章观测工具部分，Brendan 告诉我们观测工具主要包括：计数器(Counters)、跟踪(Tracing)、采样(Profiling)和监控(Monitoring)几大类。

​

依据数据获取方式和数据实时性两个维度，可以将性能观测工具做个分类：

1）左上角 A 区是直接读取计数器实时数据的一些系统命令，top、ps 这些命令我们都很常用，它们读取的是 /proc/ 这个目录的信息，这里面的数据是内核帮我们记账出来的。

2）左下角 B 区也是基于计数器的 ，但它是记录历史信息的工具，比如说最常用的就是sar工具，下文我们统称这类工具为系统性能监控工具。在阿里内部也有 tsar 工具，国外还有开源软件 atop。系统性能监控工具一方面可以回溯历史数据，同时也提供实时模式数据。

3）右上角 C 区跟踪采样工具，内核的 tracepoint、kprobe 等就是跟踪类工具，perf 工具主要是采样类工具，下文我们统称这两类工具为跟踪采样工具。目前这些工具都是只获取实时的数据。如果不结合其他工具，单纯使用它们来追查历史数据，它们是无法提供的。

4）右下角 D 区，我们认为可以通过 B 区和 C 区的工具协同使用达到目标。C 区工具只负责获取内核关键数据，B 区工具只负责数据采集和数据获取，二者之间使用标准数据接口。

我们在性能分析工程实践中重点聚焦在左下 B 区和右上 C 区蓝框 2 个象限的建设上。今天我们主要探讨的就是 B 区的系统性能监控工具建设情况。以后会再给大家介绍 C 区的工具建设情况。

​

在对系统性能监控和跟踪采样工具的具体理解上，我们认同如下 3 个理念：

1）内核计数器(Counters)信息获取代价低，无额外开销。相比较而言，跟踪采样工具或多或少都有一些运行开销，如 kprobe 的使用还可能会引起一些稳定性风险。因此，我们倾向于最大化挖掘计数器信息的价值。比如要获知机器直接内存回收的信息时，内核计数器已经提供了更低代价获取的直接内存回收和异步内存回收的指标，就完全没必要使用 ftrace 监控直接内存回收的情况了。另一方面，对于内核计数器不能涵盖的细颗粒度内核数据，还必须要依赖内核跟踪采样工具获取。比如当 IOPS 较高时，我们想了解具体的每一个 IO 读写的具体文件信息，内核计数器中完全没有相关信息。只有让跟踪采样工具专注于自己的核心任务，才更有条件打磨出更加稳定和可靠的精品工具。

2）现有的系统性能监控工具，除单机监控工具外，还有很多白屏化的监控平台。白屏化监控平台一般都是将数据采集到中心数据库，然后再集中展示。白平化监控平台采集更详细的计数器信息时，不可避免的都会遇到存储成本的问题，不宜将过多数据采集到白屏化监控平台。但同时对于一些高频使用的常规指标，如 CPU、内存和网络使用率情况，使用白屏化监控平台展示，确实可以大大提升可观测性。所以高频常规指标使用白屏化监控平台的同时，仍然需要一个数据指标更加丰富的单机系统性能监控工具配合使用。在一些关键时刻，还必须依赖这些低频数据来分析和定位问题。

3）传统的黑屏系统性能监控工具，多年来一直相对比较固化，历数 2010 年、2015 年、2020 年指标内容变化不是特别大。举个例子，新版本内核的计数器中，网络扩展指标多达 400 多个，仅 TCP 扩展指标就有 116 个，但是实际上常规的系统性能监控在TCP网络指标这一块，也就使用了不超过 15 个指标，大部分指标价值并没有被挖掘出来。这些网络的内核计数器指标，在很多网络相关问题发生时，都很有实用价值。

基于这些理念，我们认为研发一款数据指标更全、迭代周期更短、性能更加稳定的系统性能监控工具，以应对日益复杂的系统性能问题是很必要的。

今天我们要介绍的阿里自研 ssar 工具，就是这样一款系统性能监控类工具，并且已经在知名的操作系统社区龙蜥开源。它几乎涵盖了传统系统性能监控 sar 工具的所有功能，同时扩展了更多的整机级别的指标，新增了进程级指标和特色的 load 指标、load 高问题的诊断是这个工具一个独特的功能。

开源软件 atop 也是这样一个类似功能的系统性能监控工具。公开渠道了解到友商也在大规模部署 atop 工具，这说明在业界其他互联网公司也感受到了拥有这样一个功能定位的监控工具的重要性。

二、系统性能分析工具 ssar 简介

系统性能监控工具 ssar 开源地址（见文末），其中 Reference_zh-CN.md 是更详细的中文帮助手册，package 目录中有 rpm 和 deb 包提供，其他操作系统可以自行编译打包。

​

ssar工具分为采集器、内层的通用查询器、外层的增强查询器和经典查询器几部分。

1）采集器 sresar：C 语言实现的一个常驻进程，将数据记录到本地磁盘，采集数据内容包括：(a) 按文件单位采集的整机数据、meminfo、stat、vmstat等； (b) 包含 24 个指标的进程级数据；(c) 独特的 load5s 指标和详细的 R 或 D 状态线程详情数据；

2）通用查询器 ssar 命令：c++ 语言实现，负责按文件名、某行、某列等通用规则对文件数据进行逻辑解析；

3）古典查询器tsar2：python 语言实现，对 ssar 命令进行封装，全面兼容 tsar 命令；

4）增强查询器ssar+：python 语言实现，对 ssar 命令进行封装，规划上是未来 ssar 工具的主要核心，适合于把较复杂的数据逻辑放在 python 语言实现层。

三、系统性能分析工具 ssar 支持快速开发迭代

传统 sar 工具只采集一些固定指标，使用 C 语言采集数据的同时进行指标解析。在这种模式下，不是极难扩展新指标，就是扩展新指标开发迭代周期特别长。

ssar工具完全颠覆了传统 sar工具的架构设计，在产品设计和程序架构上做了很多变化，可以让我们快速、低开发成本的增加新的计数器指标。

1）如果我们需要关注一个新的指标，而这个指标又没有被采集。对于传统的系统性能监控工具sar来说，修改发布迭代周期是非常长的，发布下来可能要数周到数月，中间要经过逐步的灰度发布过程。在学习内核知识或者解决生产问题的时候，新问题等不起这么久。但 ssar 工具以文件为采集单位，不需要修改代码，直接修改配置文件，重启 srerar 采集进程就可以采集到一个新的数据源文件。新增采集文件可在 sys.conf 文件中的 file 区域增加一行配置项，其中 sre_path 为数据源位置，cfile 为数据文件存储名，turn 为开启采集。

2）ssar 工具把一些通用处理逻辑都抽象到通用查询器 ssar 命令里，配置了文件采集后，只需一条 ssar 命令即可查询显示数据，完美实现分钟级周期的开发迭代。其中cfile指定存储文件名，line 指定第 3 行，column 指定第 5 到 15 行，metric 指定显示原值，alias指定指标名称。

3）ssar 会把更加复杂的数据逻辑放到外层 python 语言的查询器中实现。这个时候很容易通过在 python 语言中适应数据格式的变化。内核中有些指标的格式会随着内核版本的变化而变化,比如 TCP 的 TimeWaitOverflow 指标在 3.10、4.9 和 4.19 版中所处的列数就不同。此时通过 python 语言可以轻松获取 column 值，再传递给ssar通用查询器。即使面对未来的内核版本中的各种未知格式变化，我们也可以在python语言查询器中轻松应对自如。可随时调试和升级python查询器，如 cp tsar2  /tmp/test.py。不论是单机环境 debug，还是脚本批量下发，均可轻量级操作。

四、ssar 工具整机指标使用介绍

ssar 命令显示整机指标信息，其中 /s 结尾的是增量指标，表示当前时刻和上一个时刻的区间内平均每秒的增量数值。无 /s 结尾的是刻度指标，只表示当前时刻的瞬时值。

​

使用 help 选项可获取整机指标使用帮助信息。

​

各个选项参数的含义如上所示，选项参数有如下一些特点：

1）-f 选项指定显示数据的结束时间点，-b 选项指定显示数据的开始时间点，-r 选项指定显示数据的时间区间长度，三个选项只需指定 2 个即可。-f 选项默认值为当前时刻，-r 选项默认值为 300 分钟。

2）各个选项参数值大多可以支持输入小数，单位分别支持天、时、分、秒，如1.2d、5.5h、60m 和 1s。如无单位后缀，则默认单位后缀是m分钟，如 60 同 60m。

3）-H选项用于隐藏header信息，使输出结果更便于各种 shell 命令的解析，--api输出json格式数据，使输出结果更便于python脚本等高级语言解析。

4）小o选项用于指定输出数据列的字段信息，多列指标用逗号隔开。对于高频常用的多个字段输出，还提供字段组合选项，如--cpu、--mem。大O选项用于在既有字段组合输出基础上，追加输出指标信息。因此，大O选项可与--cpu  --mem等同时使用，而小o选项和大O选项及其他字段组合互斥。

ssar 对整机指标的采集是以文件为单位，通过 toml 格式的配置文件 /etc/ssar/sys.conf 配置及开关文件的采集：

1）src_path='/proc/stat' 表示采集数据源文件位置为/proc/stat；

2）cfile='stat'表示保存的数据文件后缀名为 stat；

3）turn 选项控制当前采集是否开启，设置为 true 开启采集；

4）gzip 选项控制采集文件是否采用 gzip 压缩格式存储，设置为 true 开启压缩；

​

ssar 支持两种数据提取方式，预定义方式和自定义方式。

ssar 预定义指标提取数据方式适合于使用 ssar 命令直接消费数据的场景。预定义指标可在 sys.conf 文件中灵活的配置，下面 2 个例子说明了如何配置预定义指标：

1）配置项 user 表示指标名为 user，数据文件后缀为 stat，取开头为 cpu 的行的第 2 列数据的差值，输出字段宽度 10 个字节。

2）配置项insegs表示指标名为 insegs，数据文件后缀为 snmp，取第 8 行的第 11 列数据的差值，输出字段宽度 10 个字节。

​

配置了预定义指标后，可以进一步配置 view 视图，聚合预定义指标到一个视图下。这就是 ssar --cpu 的命令里 --cpu 的来源。

​

ssar 也支持自定义指标方式提取数据指标，自定义指标提取数据方式适合于使用python语言封装的查询器使用。如下是一些自定义指标方式的使用示例：

1）取 meminfo 中 MemFree 值，字段名命名为 freessar -o 'metric=c|cfile=meminfo|line_begin=MemFree:|column=2|alias=free'

2）取 snmp 中第 8 行第 13 列值的差值ssar -o 'metric=d:cfile=snmp:line=8:column=13:alias=retranssegs'

3）显示 cpu0 到 cpu15 的 idle 的实时模式数据

ssar -o 'metric=d|cfile=stat|line=2-17|column=5|alias=idle_{line};' -f +100

自定义方式使用方法说明：

1）cfile 用来指定数据文件中的后缀名，需要同 sys.conf 配置文件中的 [file] 部分的 cfile 的值保持一致；

2）line 直接指定指标所在的行数，line 与 line_begin 不能同时指定；

3）line_begin 指定指标所在行的行首匹配关键字符串，需要保证在整个文件中独一无二；

4）column 指定指标在特定行所处的列数，列以空格为分隔符；

5）metric 用于指定按以上规则获取到值后是原值输出，还是取相邻时间的差值输出，值为c表示原值输出，为d表示取差值输出；

6）alias 用于指定当前指标输出的标题名或 json 格式中的 key 值.

tsar工具是阿里集团的一款经典系统性能监控工具。基于ssar命令的整机自定义指标方式，使用python语言封装的 tsar2 命令几乎完全兼容tsar命令。

各个模块的指标集合：

tsar2 命令不但功能十分强大，而且开发成本极低：

1）tsar2开发周期只有不到2周时间；

2）tsar2命令兼容 tsar 功能部分的python代码实现只有600多行；

3）tsar2在兼容原有基础功能的基础上还新增了4组网络诊断指标，不考虑前期预研的时间，4组指标的代码实现时间只用了2个小时。4组网络诊断指标：tsar2  --tcpofo、tsar2  --retran、tsar2  --tcpdrop、tsar2  --tcperr。

基于 ssar 良好的扩展性和低扩展开发门槛，针对软中断分布不均这种业界常见问题，使用 python 语言实现了 3 组功能强大的诊断功能：

1）首先，tsar2 的 cputop 子命令可以将各个核软中断 CPU 使用率(sirq)最高的核排序出来。N1 表示排序最高的 CPU 信息，N2 表示排序次高的 CPU 信息。比如 11:35 这个时刻下 N1 的三个值表示 54 号核 CPU 的 sirq 软中断使用率为第 54 号核 CPU 资源的 21.84%。从图中显示的部分数据看 54 号核频繁出现软中断 sirq 使用较高的情况。

​

2）如果我们不确定找到 54 号核 CPU 是否准确，还可以通过 tsar2 命令的 cpu 视图中指定观察 cpu54 核的 sirq 的变化。

​

3）一旦确定软中断 CPU 使用率异常的 CPU 核号，可以通过 tsar2 的 irqtop 子命令查找引起问题的具体软中断信息。在 irqtop 子命令中指定 54 号 CPU，并排序出软中断次数最多的 irq 号是 155，对应的 irq 名称是 virtio3-input.1，并且看到 11:50:48 秒的软中断次数高达 1.9K。

irqtop子命令默认只支持实时模式。如需开启历史模式可去掉命令中-l选项，同时还需要修改配置文件 sys.conf，开启 interrupts 数据文件的采集。

如此强大的cputop和irqtop子命令同样也是在python语言中，通过400行代码轻松实现。这里也同样表明了在ssar架构下，开发新的系统性能监控功能的灵活优势。

五、ssar工具进程指标使用介绍

ssar 的 procs 子命令可以显示多进程信息，效果相当于可以显示任意历史时刻的 linux ps 命令的输出。

ssar 的 procs 子命令选项可参考ssar procs -h命令，选项参数有如下一些特点：

1）-f、-b和-r选项同样只需指定2个选项即可，-f选项默认值为当前时刻，-r选项默认值为5分钟。多进程子命令情况下，只会在开始和结束时刻分别取 2 个时刻数据进行对比。瞬时的刻度类指标只显示结束时刻值。

2）强大的字段排序功能支持多字段依次排序，先按第一个字段排序，相同值按第二个字段排序。排序字段前减号表示降序排序，排序字段前加号表示升序排序。每个字段都有系统内建排序规则，通常数据类指标按降序排序，如rss，属性指标按升序排序，如 pid。

3）所有进程排序后，-l选项可限制输出进程的行数。

4）两个特色的指标组合 --job 和 --sched，用于进程组和调度问题排查。

​

ssar 的 proc 子命令显示单进程纵向历史时刻信息。

1）-p选项为必选参数，用于指定需要显示的进程的 pid 信息。

2）-f选项指定结束时间点，-b选项指定开始时间点，-r选项指定时间跨度，三个选项只需指定2个即可。-f默认值为当前时刻，-r默认值为 300 分钟。

3）-H选项隐藏header信息更便于shell脚本解析，--api选项输出json格式数据更便于python脚本等高级语言解析。

4）小 o 选项用于指定输出数据列的字段，多列指标用逗号隔开。对于高频常用的多字段同时输出，还提供字段组合选项，如 --cpu、--mem。大 O 选项用于在既有字段组合输出基础上，追加输出字段指标。因此，大 O 选项可与 --cpu  --mem 等同时使用，而小 o 选项和大 O 选项及其他字段组合互斥。

5）左尖括号 < 表示7点02分sleep.sh进程还没启动，右尖括号 > 表示7点22分进程已结束。此功能可以协助判断一个特定进程的开始和结束时间范围。

下面通过一个简单的例子，来说明下如何通过 ssar 进程级指标诊断线程数打满问题。Linux 内核有个参数 kernel.pid_max = 131072，这个参数会设置机器的总线程数上限。

1）一台机器在非工作时段发生了异常进程创建大量线程将线程数打爆的情况。凌晨3点整，整机线程数飙升到了131.1K，且持续时间极短，3点1分已经恢复。

2）传统条件下，这种场景的发生根本来不及等待人工登录上去抓取现场信息。如今有了ssar工具对历史信息的自动采集，我们可以等到工作时间，使用ssar的多进程子命令轻松获取进程级原因。NLWP(Number of light weight process)表示一个进程的线程数，使用-k选项数按 nlwp 字段排序可以发现是 pid 为 1045 的 Java 进程引起线程数打满。

3）不放心的同学，还可以使用 awk 将这个问题时刻2021-03-30T03:00:00的所有线程数相加，和为 131024，印证了确实等同于当时机器总线程数plit值131.1K。

六、ssar工具load指标使用介绍

传统的系统性能监控工具中的 load1 指标尽管比 load5 和 load15 指标更精准，仍然不能满足排查问题时对时间范围的精准度的要求。ssar 在国内外全行业独创了 load5s 指标，该指标可以让我们将 load 的准确性提升到 5 秒级的精度。load5s 指标的准确性绝不仅体现在采集频率上，简单说 load5s 指标就是 R+D 的线程数，也是内核数据结构中的全局变量 active 值。为了准确理解 linux load 和 load5s 指标，执行如下实验操作：

​

找一台实验机器，先编译一个可以模拟 D 状态线程的程序 uninterruptible。然后用 stress 命令启动 100 个进程执行 30 秒后退出。大约再等 20 秒左右再批量循环启动 1000 个 uninterruptible 进程。执行结束后，效果如下图所示。

​

1）绿色时间区域，5 分 52 秒时 load5s 和 load1 都处于一个低水位，毫无疑问说明当时机器负载压力很低。

2）第一个红色时间区域，伴随着stress命令开始执行，load5s 和 load1 都同时升高，6分07秒时刻，load5s 值已经达到78，load1 开始升高到 6.27，但是这个 load1 的值远远不能体现出当前机器上并发运行的线程的状况。随着时间的推移，6分32秒这个时刻，load1的值缓慢升到了39.22。

3）第一个蓝色时间区域，伴随着stress命令进程退出，load5s已经迅速跌回到一个低水位，6分37秒这个时刻的 load5s 值也同时迅速降低到了很低的值0，机器的R+D状态线程已经几乎没有了，系统完全没有任何压力。但此时load1还保持在36.08的高值。明显可以看出传统的 load1 指标在系统负载压力消失后，还一定的滞后性。

在后面2个红色区域和2个蓝色区域，也可以观察到同样的现象。共同的规律是红色区域开始时刻，代表R+D状态线程数的load5s值明显很高，但相同时刻的load1却还较低。蓝色区域开始时刻，代表R+D状态线程数的load5s值已经为0，但相同时刻load1却还较高。

上面这个实验充分说明 load5s 才是更能准确反映系统负载压力的指标，而单纯用 load1 值判断机器的负载是不准确的。所以我们需要用 load5s 指标替代 load1 指标来精准判断机器负载发生的时间范围。这里强调一下，load5s指标完全在用户态通过工程化的方法巧妙获取，没有对内核模块的任何依赖。

除 load5s 指标外，上面的解决方案中，还提供了一组指标用于全面的评估系统负载情况。其中 load5s 是 R+D 状态的线程数之和，runq是当时的R状态线程数，threads是所有状态线程数总和，因此 threads 值是 load5s 值的天花板，threads 最大值受内核参数设置限制。

ssar 工具还会根据 load5s 和 CPU 核数之比的大小，来触发对 load 详情的采集，前边的 actr 是采集到的并发R状态线程数，actd 是采集到的并发 D 状态线程数，act 是 actr 和 actd 数之和。当我们需要了解load构成的详细因素时，可以借助load2p子命令进一步显示actr和actd的详情信息。

未触发 load 详情采集的采集时刻，act 值不存在，显示为短横线-。可以用-z选项过滤出 load5s 子命令输出结果中act存在值的时刻，即 ssar load5s -z。

然后再用 load2p 子命令显示更加详细的load详情信息，选项-c 指定需要显示的load详情的时刻值。load2p子命令一共可输出6个视图的信息，loadrd、stack、loadr、loadd、psr和stackinfo。

1）loadrd视图显示指定时刻所有R和D状态的线程信息，每个线程包括线程状态、线程ID、进程ID、CPU核号、线程调度优先级和命令名称。ssar 只采集 R 和 D 状态的线程信息。

​

2）stack视图显示抽样后的D状态调用栈，最多抽样100个。每个D状态线程调用栈包含线程ID、进程ID、进程名称、栈顶函数位置、栈顶函数名和完整的调用栈。

​

3）基于以上2个视图的信息，load2p子命令又聚合了4个视图信息，并且默认只显示这4个聚合视图 loadr、loadd、psr 和stackinfo。Loadr 视图按 pid 聚合 R 状态线程信息，适合诊断 loadR 高时的进程级因素。

4）loadd视图按pid聚合D状态线程信息，适合诊断loadD高时的进程级因素。

5）psr视图按CPU核号psr聚合，适合诊断绑核不均的情况。

6）stackinfo视图按调用栈聚合，对loadD高时，诊断D状态线程发生的原因特别有用。

七、ssar工具配置文件说明

ssar工具的主配置文件是/etc/ssar/ssar.conf，其中分为[main]、[load]和[proc]三部分。

​

1）[main]部分配置选项主要用于设置ssar工具整体的一些选项内容，[load]和[proc]分别对应load信息采集和进程信息采集部分的选项，整机信息的配置选项在前文介绍的/etc/ssar/sys.conf文件中独立设置。

2）duration_threshold选项设置最多保留168小时。inode_use_threshold、 disk_use_threshold和disk_available_threshold这3个选项任意一个条件不满足时，则停止数据采集，并且开始从时间最老的数据到最新的逐步删除数据，以试图使刚才不成立的条件成立，一直删除到只剩最新的一个小时数据目录为止。ssar工具的这种磁盘空间处理逻辑可以说不占用额外的磁盘空间。

3） load5s_flag、 proc_flag和sys_flag分别控制采集器三部分数据的采集，嵌入式系统中可以同时关闭load5s_flag和proc_flag后再配置sys.conf，从而做到只采集自己关注的数据源。

4） scatter_second选项用于在大规模集群中，使各个主机的采集时间分散化。

5） load5s_threshold设置load详情采集触发阈值，不同角色的服务器此阈值需要根据各自特点个性化设置。

八、ssar工具CPU使用率综合分析

Linux top命令中有2处%Cpu，一处是在头部，另外是在每个进程信息中。关于两者之间的关系，我们借助ssar工具的使用简单介绍一下。

为了准确理解linux CPU Usage指标，在一台4核机器上执行如下实验。A终端执行命令   stress -t 120 -c 3，执行时间为23时23分20秒，120秒后会结束。B终端同时执行top命令，如图所示。

理解 CPU Usage 指标：

1）在A终端上，等待stress执行结束2分钟后，执行tsar2命令。23时25分的user值为75.60，它的含义表示23时24分到23时25分这60秒内的平均user CPU使用为75.60%。这里看出tsar2的user值等同于top命令的us值75.2，区别就是tsar2的是60秒平均值，top的是运行时刻的之前3秒的平均值，但因为三个stress命令运行平稳，top的3秒平均值也基本代表60秒的均值。

2）在A终端上继续执行ssar命令，23时25分的user/s值为301.35。ssar的cpu值是取自/proc/stat，单位是内核tick数。x86_64系统每秒100个tick，即100HZ。4颗CPU总数就是每秒400个tick， 23:25时间的user值是301.35，它的含义表示23时24分到23时25分这60秒内的平均每秒user CPU使用量为301.35 tick数。

3）我们可以查看tsar2的python源码，能够了解到tsar2的user值是ssar的user值占ssar所有CPU使用量之和的百分比。

​

4）在A终端上继续执行ssar procs子命令。23时25分的三个stress进程的pucpu值都为100.0。这里的每一个100.0的含义是这个进程在23时24分到23时25分这60秒内的进程的平均用户空间CPU使用率为100.0。计算过程是用进程的cpu时间片除以自然时长，再乘以100，即百分比的100。这个算法和top命令下半部分的进程级别的%CPU一致。

​

5）这里我们可以看到这样的数据关系301.25 ≈ 100 + 100 + 100 + 3.3，只不过整机user CPU值301.35是自然时间乘以了100HZ，进程级CPU是乘以了百分比的100。使用ssar --cpu和ssar procs --cpu两个命令，已经可以将整机总体的CPU使用情况和进程级别CPU使用情况的关联起来。

6）最后top命令中的us值和进程信息中的%CPU的关系也就自然建立起来了。一点不同就是top中是将整体CPU使用情况进一步计算了一次百分占比。

九、ssar工具内存回收案例

在 load 高的各种场景中，有一种R状态线程数并发多的load高是由于sys CPU使用率偏高引起的。ssar 全面的指标体系，从多个角度将这种场景发生过程进行了透彻的呈现。为了准确的说明问题，有必要回顾下内核内存回收的相关概念。如图所示，当整机free内存低于黄线low阈值时，内核的异步内存回收线程kswapd开始被唤醒，kswapd会在其他进程申请内存的同时回收内存。当整机free内存触达红线min阈值时，触发整机直接内存回收，所有来自用户空间的内存申请将被阻塞住，线程状态同时转换为D状态。此时只有来自内核空间的内存申请可以继续使用min值以下的free内存。后续当整机free内存逐步恢复到绿线high阈值以上后，kswapd线程停止内存回收工作。

​

下面以ssar的数据指标为依据，一步一步的展示了当整机内存紧张后是如何引起sys CPU高，并进而引发load高的完整过程：

1）用户空间java进程在20点43分到20点45分2分钟内大量申请24GB内存；

​

2）整机内存used在20点43分到20点45分2分钟内迅速增长了26GB，同时整机free内存迅速减少了14GB；

​

3）free内存在20点45分时只有3GB，低于low阈值，pgscan_kswapd/s值非0表明触发kswapd异步内存回收。

​

4）kswapd异步内存回收跟不上进程内存申请的速度，当free内存低至min阈值时，pgscan_direct/s值非0表明触发直接内存回收，用户空间内存申请进程开始D住。栈顶函数sleep_one_page和congestion_wait等都表明发生了直接内存回收。

5）20点44分到20点45分出现大量网络吞吐，每秒进出流量分别达到1.5G和1.0G。网络流量吞吐会伴有内核空间内存申请，继续消耗min阈值以下(橙色部分)free内存。

6）内核网络模块会申请order3阶内存，20点45分时刻buddyinfo中order3以上高阶内存消耗殆尽，剩余的3GB free内存处于碎片化状态。内核空间申请的内存是连续内存，虽然order2和order1有库存，但申请order3时是无法被分配的，内核只能处于忙等状态。

7）触发内核态忙等，同时会引发20点44分到20点45分的sys CPU升高，sys CPU平均每秒占总CPU资源的89.61%，挤占用户空间既有进程CPU资源，同期用户态CPU使用从原来的72.59%降低到7.73%。

​

8）触发直接内存回收时，会引发大量D状态线程，后续order3库存枯竭引发sys CPU高后，会继续引发大量R状态线程。load5s子命令看到的现象就是先出现load5s指标升高，再出现load5s和runq同时升高。

​

内存回收是生产环境较常见的一个情况。除以上场景外，生产中还会发生其他场景的内存回收,数据指标的表现上也有差异。还需要借助其他性能分析工具，结合内核代码进一步分析。

原文链接

本文为阿里云原创内容，未经允许不得转载。

​