直播回顾：准确性提升到 5 秒级，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 值，字段名命名为 free

ssar -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 同时升高。

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

系统性能监控工具 ssar 开源地址：

https://gitee.com/anolis/tracing-ssar.git

龙蜥社区视频回顾地址链接：

https://openanolis.cn/video/#440154235973681288

使用文档详细链接地址：

https://gitee.com/anolis/tracing-ssar/blob/master/Reference_zh-CN.md

敲重点啦

本次直播视频回放已上线至龙蜥社区官网（首页-支持-视频），直播 PPT 获取方式：关注龙蜥社区公众号，后台回复【龙蜥课件】或【龙蜥视频回放】即可。

龙蜥社区官网截图

—— 完 ——

加入龙蜥社群

加入微信群：添加社区助理-龙蜥社区小龙（微信：openanolis_assis），备注【龙蜥】与你同在；加入钉钉群：扫描下方钉钉群二维码。欢迎开发者/用户加入龙蜥社区（OpenAnolis）交流，共同推进龙蜥社区的发展，一起打造一个活跃的、健康的开源操作系统生态！

关于龙蜥社区

龙蜥社区（OpenAnolis）是由企事业单位、高等院校、科研单位、非营利性组织、个人等在自愿、平等、开源、协作的基础上组成的非盈利性开源社区。龙蜥社区成立于 2020 年 9 月，旨在构建一个开源、中立、开放的 Linux 上游发行版社区及创新平台。

龙蜥社区成立的短期目标是开发龙蜥操作系统(Anolis OS)作为 CentOS 停服后的应对方案，构建一个兼容国际 Linux 主流厂商的社区发行版。中长期目标是探索打造一个面向未来的操作系统，建立统一的开源操作系统生态，孵化创新开源项目，繁荣开源生态。

目前，龙蜥OS 8.4已发布，支持 X86_64 、Arm64、LoongArch 架构，完善适配飞腾、海光、兆芯、鲲鹏、龙芯等芯片，并提供全栈国密支持。

欢迎下载：

https://openanolis.cn/download

加入我们，一起打造面向未来的开源操作系统！

https://openanolis.cn