Linux无法通过top、iostat、sar等工具观测指令集执行吞吐，因其仅统计系统级资源使用；真正可测IPC（instructions per cycle）的唯一工具是perf，它通过硬件PMU采集instructions和cycles等原生事件并计算比值。
Linux 不提供“指令集执行吞吐”这一指标的直接观测能力——CPU 指令执行速率（如 IPC、每周期指令数）不是靠 iostat 或 vmstat 这类工具能查的，它属于微架构层面行为，必须通过硬件性能计数器（PMU）采集。
为什么不能用 top / iostat / sar 看指令吞吐
这些工具统计的是系统级资源使用（CPU 时间片、IO 请求、内存页），不接触 CPU 流水线或发射/退休单元。它们输出的 %cpu 是调度器视角的占用率，和实际指令退休速率（instructions retired per cycle）完全不是一回事。
-
top显示的是进程在调度周期内获得的 CPU 时间比例，无法反映超标量执行、乱序调度、分支预测失败等对指令吞吐的影响 -
iostat -x关注块设备层数据流动，和 CPU 指令流无任何交集 -
sar -u统计的是内核定时器采样点上的运行态/空闲态时间占比，精度粒度在毫秒级，远低于单条指令纳秒级执行周期
真正能看指令级吞吐的只有 perf
perf 是 Linux 唯一能对接 CPU 硬件 PMU 的用户态工具，它能读取 instructions、cycles、branches 等原生事件，进而算出 IPC（instructions per cycle）——这才是衡量“指令执行吞吐”的核心指标。
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 基础命令：
perf stat -e instructions,cycles,branches -a sleep 1，输出类似：2,412,398,123 instructions # 1.23 insn per cycle1,961,002,456 cycles - 想看某进程：
perf stat -e instructions,cycles -p $(pgrep -f "your_cmd")，注意需 root 或/proc/sys/kernel/perf_event_paranoid≤ 2 - IPC 3 在现代 x86-64 上已属高负载，接近硬件极限
- 别只盯着
instructions总数——它受代码路径长度影响极大；关键看instructions / cycles比值是否稳定、是否随负载线性增长
perf stat 输出里哪些字段代表真实指令吞吐
真正有用的只有三个原始计数器及其比值：
-
instructions：CPU 实际退休（retired）的指令数，是吞吐的分子 -
cycles：CPU 核心实际运行的周期数，是吞吐的分母 -
insn per cycle（IPC）：自动计算得出，才是可比的吞吐密度指标 - 避免用
task-clock或context-switches推算——它们和指令执行无确定映射关系 - 若看到
stalled-cycles-frontend或stalled-cycles-backend占比高，说明吞吐瓶颈不在指令带宽，而在取指或执行单元阻塞
真正卡住人的地方，往往不是找不到 perf 命令，而是把 top 的 %CPU 当成 IPC、把 perf record 的火焰图当成吞吐数值、或者在虚拟机里没开 perf_event_paranoid 导致所有计数器返回 0。
