第 6 讲 · KSYS 实战：用数据定位瓶颈，而不是靠猜

掌握 KSYS 的完整工作流，理解"先验环境、再采集、后对比"三步为什么不能省；学会把采集指标映射到具体优化方向。

为什么需要 KSYS

计时器能告诉你"慢"，不能告诉你"为什么慢"------是计算密集、访存瓶颈、NUMA 跨节点，还是指令缓存 miss？这些答案要靠工具给出。

安装 KSYS

KSYS 以独立压缩包交付，不是 RPM：

bash 复制代码

# 下载对应的包（aarch64 或 x86_64）
tar -xzf ksys-x.x.x-Linux-aarch64.tar.gz
cd ksys-x.x.x-Linux-aarch64

# 直接运行，查看帮助
./ksys -h

顶层命令只有 -h 和 -v：

text 复制代码

usage: ksys [-h] [-v] {collect,report,diff,stability-check} ...

四个子命令构成完整闭环：collect 采集 → report 出报告 → diff 对比 → stability-check 验环境。

第一步：先验环境，别急着采集

这一步最容易被跳过，也最容易让后面全白做。 如果机器上还有别的负载在跑，采集到的数据会抖动，基于它做的优化决策就是错的。KSYS 提供了 stability-check：

bash 复制代码

./ksys stability-check -d 30 -i 1 -o /home/test/

参数说明：

参数	含义	取值
`-d/--duration`	采集时长（秒）	最小 10，最大 120，默认 30
`-i/--interval`	采样间隔（秒）	最小 1，默认 1，不能大于 duration/10
`-o/--output`	结果存放目录	默认当前目录

注意 -d 的取值范围与 collect 不同：collect -d 最小 1 秒、可持续采集；stability-check -d 被限制在 10--120 秒。

输出是一张变异系数（CV）表格，覆盖 CPUUtilization、CPUStat、CPULoad、MemInfo、SwapMem、IO、Network：

text 复制代码

[INFO] Data saved successfully at /home/test/2026_01_29_11_20_03_stability.log

判读标准 ：CV 大于 0.15 视为有一定波动 ，值越大波动越大。如果超标，先停掉无关服务、确认没有其他任务，再重测------环境不稳，后面所有数据都不可信。

第二步：采集

collect 的完整参数：

bash 复制代码

./ksys collect [-h] [-o OUTPUT] [--verbose] [-d <sec>] [-i <sec>] \
               [-p PID] [-c CONFIG] [-G CGROUP] [-l {0,1,2,3}]

参数	含义
`-o/--output`	JSON 文件存放目录，不指定则当前目录生成 `Y_M_D_H_M_S_report.json`
`-d/--duration`	采样时长（秒），最小 1 ；不指定则持续采集，`Ctrl+\` 或 `Ctrl+C` 停止
`-i/--interval`	采样间隔（秒），最小 1，默认 1；建议不超过总时长的 1/10
`-p/--pid`	采集指定进程，不指定则采集整个系统
`-c/--config`	YAML 配置文件，控制热点函数/SPE 模块
`-G/--cgroup`	监控指定 cgroup（仅支持 v1 和 v2）
`-l/--log-level`	`0`=DEBUG `1`=INFO `2`=WARNING `3`=ERROR，默认 1

互斥约束 ：-p、-G、以及工作负载参数三者只能同时给一个。

四种采集方式：

bash 复制代码

# ① 系统级：采集整机数据 30 秒
./ksys collect -d 30 -o /home/test/

# ② 应用级：直接运行可执行文件并采集（最后一个位置参数是程序路径）
./ksys collect -d 30 -o /home/test/ /home/test/demo/my_app

# ③ 进程级：采集指定 PID
./ksys collect -d 30 -o /home/test/ -p 2748713

# ④ cgroup 级
./ksys collect -d 30 -o /home/test/ -G my_test_cgroup

选择哪种取决于你的问题：想优化某个具体程序，用 ② 或 ③；想排查整机资源争抢，用 ①。

采集哪些指标

KSYS 会采集这些维度：Miss、访存统计、NUMA、微架构、Miss Latency、热点函数、CPU 使用率、网卡带宽、I/O、内存使用、Softirq、PCIe、PA2Ring、Ring2PA，以及指令类别分析（SVE、SME）和本地/跨 Die/跨芯片中断分析。

⚠️ 重要平台限制 ：PCIe、PA2Ring、Ring2PA、SVE、SME 这几类数据的采集，需要鲲鹏 920 新型号服务器；标准版鲲鹏 920 不支持。 如果你的机器是标准版，这几个维度会是空的------这不是工具故障。动手前先用 lscpu 或机器型号确认。

跨平台对比的坑

KSYS 在 x86 上也支持，但能采的指标不同：

平台	限制
鲲鹏 920 + openEuler 20.03/22.03/24.03	完整支持
Intel x86 (family 6, model 63) + CentOS 7.9	仅 TopDown L1；无 rx_sccl、无 Miss Latency
AMD x86 (family 25, model 17) + openEuler 22.03	无 TopDown、rx_sccl、Miss Latency、DDRC bandwidth

这意味着"x86 采集一份、ARM 采集一份再对比"的做法必须谨慎------能采的指标不同，对比结论可能不成立。要对比就只对比两边都有的指标。

第三步：对比------这一步才是优化动作

改完一个参数或一个编译选项后：

bash 复制代码

./ksys diff -i <优化前>.json <优化后>.json -o /home/test

参数	含义
`-i/--input`	必须两个 JSON 文件，空格分隔
`-o/--output`	结果目录，不指定则当前目录生成 `Y_M_D_H_M_S_diff.xlsx`

两个约束要记住：

约束一 ：第一个文件是 Before，第二个是 After 。-i A B 表示 A 是优化前、B 是优化后，别搞反。

约束二 ：不同类型的 JSON 不能互相对比（系统级 / 应用级 / 进程级不能混）。所以采集时要保持方式一致。

输出的 Excel 里有 System Info、CPU Metrics、OS Metrics、INSTRUCTION、Net_info，以及最重要的 Top diff 段：

Top diff 规则 ：最多列出 20 条，且只显示变化超过 50% 的指标。

注意反面：变化不超过 50% 的指标不会出现在 Top diff 里，小幅但重要的变化要自己去对应表格看。

完整工作流：一次真实的优化验证

把三步串起来：

bash 复制代码

# ── 0) 环境准备 ──
cd /home/test
mkdir -p ksys_out

# ── 1) 先验环境稳定性 ──
./ksys stability-check -d 30 -i 1 -o /home/test/ksys_out/
# 检查输出的 CV 表格，>0.15 的项先处理掉

# ── 2) 采集优化前基线 ──
./ksys collect -d 30 -o /home/test/ksys_out/ /home/test/demo/my_app
# 记下生成的 JSON 文件名，比如 2026_09_15_10_30_00_report.json

# ── 3) 实施优化（改代码 / 改编译选项 / 改系统参数）──
# ... 这里做实际改动 ...

# ── 4) 采集优化后 ──
./ksys collect -d 30 -o /home/test/ksys_out/ /home/test/demo/my_app_opt

# ── 5) 对比 ──
./ksys diff -i /home/test/ksys_out/2026_09_15_10_30_00_report.json \
              /home/test/ksys_out/2026_09_15_11_00_00_report.json \
           -o /home/test/ksys_out/

# ── 6) 出详细报告 ──
./ksys report -i /home/test/ksys_out/2026_09_15_11_00_00_report.json \
              -o /home/test/ksys_out/

report 的输出形如：

text 复制代码

Save statistics and time series data to an Excel file and a HTML file. Please wait.
The report has been saved to /home/test/ksys_out/2026_09_15_11_05_00_report.xlsx
The report has been saved to /home/test/ksys_out/2026_09_15_11_05_01.html

report 还有个实用参数 --parse，能把业务日志和应用指标对齐分析：

bash 复制代码

./ksys report -i /home/test/xxx_report.json --parse spark /home/test/

支持 mysql（errorlog/generallog/slowlog）、flink、redis、spark、kafka、openGauss，以及 general（CSV 格式的通用日志）。

把指标映射到优化方向

采到数据之后，怎么读：

观察到的现象	可能的根因	该去哪一讲找解法
热点集中在少数函数	算法或实现问题	第 9 讲（编译选项）或重构算法
Miss / Miss Latency 高	访存局部性差	第 7 讲（大页）、第 9 讲（结构体重排）
NUMA 跨节点访存占比高	线程与内存不在同节点	第 7 讲（绑核）
Softirq 占用大量 CPU	网络中断处理开销大	第 8 讲（中断绑核）
向量指令占比极低	代码没被向量化	第 9 讲（`-fopt-info` 查原因）
PCIe/缓存未命中异常	数据搬运或布局问题	第 7 讲、第 9 讲

配合亲和分析做静态检查

KSYS 是运行时工具，DevKit 的亲和分析 （devkit advisor）提供互补的静态视角。它有 11 个子命令，几个和性能直接相关：

bash 复制代码

# 构建亲和：分析 makefile/CMakeLists.txt，识别可替换为鲲鹏加速库的组件
devkit advisor affi-check -i /home/project -c make -o /home/out

# 缓存行对齐检查：检查结构体变量是否 128 字节对齐
devkit advisor cacheline -i /home/test_code/myproject -o /home/out/

# 向量化检查：找出可向量化的代码片段并给建议
devkit advisor vec-check -i /home/testcase/cplusproject \
    -f /home/test/bc_files -c 'make' -p gcc -o /opt/DevKit

cacheline 检查的是 128 字节对齐，不是常见的 64 字节------这与鲲鹏的缓存行/预取行为相关，结构体没对齐会带来额外访存开销。

vec-check 依赖 BC 文件，而 BC 文件由 bc-gen 生成，所以顺序是：

bash 复制代码

# 先生成 BC 文件
cd /home/test && cmake .
devkit advisor bc-gen -c make -o /home/test/bc_files

# 再做向量化检查
devkit advisor vec-check -i /home/test/src -f /home/test/bc_files \
    -c 'make' -p gcc -o /home/out

⚠️ 待实机确认：vec-check 对编译器版本有要求（GCC 7/8/9/10，或 clang 12/15/16），版本不匹配会失败。另外构建命令中用分号分隔多条命令并加引号 ，但不支持设置变量或 export 环境变量 ------"CFLAGS='-O0';make" 这种写法不行。

动手练习

用第 2 讲 bench_add 的标量版和 NEON 版各采集一次并 ksys diff，看 Top diff 里哪些指标变化超过 50%。
后台跑一个 CPU 密集任务（yes > /dev/null &）再执行 stability-check，直观感受 CV 值如何变化。
对第 3 讲的 numa_latency 分别在绑定和非绑定条件下采集，看 NUMA 相关指标的差异。

进阶与拓展

stability-check 与 advisor 的分工 ：stability-check 只回答"环境噪声允不允许出数"；devkit advisor 各子命令回答"代码里哪里值得改"（affi-check 查可换鲲鹏加速库的组件、cacheline 查 128 字节对齐、vec-check 查可向量化片段）。推荐顺序：advisor 定位改造点 → 改动 → KSYS collect/diff 验证收益。
采集开销控制 ：用 -p/-G 限定单进程或 cgroup，避免整机采集放大开销；-i 不超过 -d 的 1/10 才能保证每个指标有足够样本算 CV；对比实验前后两次 collect 的 -d/-i/采集方式必须一致，否则 diff 差异里混入了采样差异。
长周期干扰是 stability-check 的盲区：单次最长 120 秒，只能覆盖短窗口；定时任务、备份脚本这类分钟/小时级干扰，官方文档没有给现成方案，需多次采集取中位数排除 (uncertain)。
没有鲲鹏机器时的替代 ：KSYS 在 Intel x86（family 6, model 63 + CentOS 7.9）仅支持 TopDown L1，此时退回 perf stat/perf top 做粗定位，等上鲲鹏环境再用完整指标细查。

参考来源

鲲鹏 DevKit · KSYS 性能定界工具 --- 工具概述、平台兼容性表与采集项清单
鲲鹏 DevKit · KSYS collect --- 完整参数、互斥约束与官方命令示例
鲲鹏 DevKit · KSYS diff --- Before/After 语义与 Top diff 规则
鲲鹏 DevKit · KSYS stability-check --- 参数取值范围与 CV 判读标准
鲲鹏 DevKit · 亲和分析 --- 11 个子命令功能、cacheline 的 128 字节口径、vec-check 编译器版本要求