1. 案例背景

工具特性日益繁杂，在客户现场中，在情况不明的情况下，如何使用DevKit工具高效采集基本性能数据，满足基本的分析要求，可能会对第一次支撑客户的同事造成困扰。本案例以一次客户支撑的快速采集为例，对相应的流程，做一个简单示范。

2. 工具下载与安装

本案例需要依赖的工具包括系统性能分析工具和鲲鹏系统性能方法论分析工具，下载地址: https://www.hikunpeng.com/zh/developer/devkit/download?tab=commandLine，请选择最新版本下载，可参考用户指南部署。

3. 采集步骤

3.1 创建数据包目录

现场采集一般会多次调试参数，采集对比，采集数据需要清晰明确，方便对比，一般以时间+简单描述作为标题，例如：

10_03_08_20_no_btb    # 表示10月3日8时20分，关闭btb选项采集数据

如果有更多信息，可以在目录中建立readme文档，采集命令也可归档到文件中，后续所有采集均cd到数据包中采集，例如:

cd 10_03_08_20_no_btb

3.2 Ksys采集

鲲鹏系统性能方法论分析工具是数据较为全面的定位定界工具，采集数据比较全面，作为首选采集命令，ksys安装路径为KSYS_INSTALL_PATH，采集命令如下:

KSYS_INSTALL_PATH/ksys collect -p 采集进程号 -d 30 | tee ksys.txt

采集一般使用进程号采集，采集事件建议为30s，使用tee命令将显示内容备份到ksys.txt文本中。

采集完会在当前目录生成形如2025_11_18_14_32_27_report.json文件名称，使用ksys转换文件为统计表格，方便分析：

KSYS_INSTALL_PATH/ksys report -i 2025_11_18_14_32_27_report.json

3.3 微架构数据

对精细化的微架构数据进行采集，如性能分析工具的安装路径为TUNER_INSTALL_PATH（如果使用rpm包部署，可以直接使用devkit作为命令采集），采集命令为：

TUNER_INSTALL_PATH/devkit tuner top-down -p 进程号 -d 10s | tee topdown.txt

建议使用进程号采集，采集10s，并将内容保存到topdown.txt中。

3.4 访存数据采集

对访存数据采集也是使用性能分析工具，采集命令如下：

TUNER_INSTALL_PATH/devkit tuner top-down -c {n | n,m | n-m} -d 10s | tee memory.txt

对访存的采集采集对应的cpu列表，现场测试一般都是绑核运行，可用使用“-”表述cpu序列，如果出现间断，可以使用逗号分隔；建议采集10s稳定数据，并将内容保存到memory.txt中。

3.5 Numa数据采集

鲲鹏服务器采取numa架构，numa数据也是非常重要的性能数据，采集命令如下：

TUNER_INSTALL_PATH/devkit tuner numafast -p 进程号 -d 10s | tee numafast.txt

建议对进程号进行采集，采集10s，并将输出保存到numafast.txt文件中。

3.6 热点火焰图

热点火焰图采集可以帮助分析热点系统调用和热点函数，如果是C应用，建议客户使用DEBUG模式编译，可以更好分析函数热点，简单采集可以创建一个hospot目录，方便快速采集数据落盘，命令如下：

mkdir hotspot
cd hotspot
TUNER_INSTALL_PATH/devkit tuner hotspot -g -d 10 -p 进程号
cd ..

推荐对指定进程采集10s，注意需要添加-g选项生成火焰图，最后退出hotspot目录。

3.7 其他数据采集

采集系统的top命令情况：

top -b -n 1 | tee top.txt

采集进程情况：

ps -ef |grep 进程号|tee processs.txt

3.8 打包数据

最后，在客户同意的情况下，可以对数据打包并共享给同事分析。

4 分析示例

举例本次案例中的对系统性能的分析，可以参考分析思路。本次案例模型为，java应用，使用16进程并行处理任务，分析cpu上的瓶颈问题。

首先分析ksys数据：

从图表中看出：

1. 应用的CPU占用率较高，但是IPC只有1，当前机器为8路机器，属于偏低情况；
2. 从top-down情况上，主要是后端瓶颈问题造成，集中在访存问题上；
3. L2的miss情况比较高，L3的压力比较大。

使用top-down的分析结果查看：

从微架构图标中也能看到L3的瓶颈异常高，分析为本身j应用为内存密集型场景，机型的L3 cache较小，造成较高的L3缓存压力。

后续解决思路：

1. 寻求硬件团队帮助，使用uncore turbo能力，提升cache性能；
2. 寻求jvm团队帮助，从jvm角度，提升命中率优化方案。