Linux无直接命令查系统总线带宽占用，因内核不暴露硬件级吞吐百分比；可用perf或pcm-memory.x实测内存控制器读写速率（MB/s或GB/s），但非占用率且受CPU型号、NUMA等影响。
Linux没有直接命令能查“系统总线带宽占用”
所谓“系统总线带宽占用”，通常被误认为是内存总线或PCIe总线的实时利用率，但Linux内核不暴露这类硬件级吞吐百分比。/proc/meminfo、free、vmstat、sar -n DEV等全都不提供总线级字节传输率——它们只反映逻辑层资源（如内存页、网络包、磁盘IO），而非物理链路的实际带宽消耗。
用perf测DDR内存控制器实际读写吞吐（需root + Intel/AMD支持）
这是目前最接近“总线带宽占用”的实测方式，但本质是采样内存控制器性能计数器，不是百分比，而是绝对速率（MB/s或GB/s）。结果受CPU型号、uncore频率、NUMA节点分布影响极大。
-
sudo perf list | grep -i "imc\|mem_load_retired"：先确认是否支持，Intel平台常见事件如uncore_imc_00/event=0x04,umask=0x0f/（读）、event=0x05（写）；AMD平台可能为mem_load_retired.l3_miss等 -
sudo perf stat -e "uncore_imc_00/event=0x04,umask=0x0f/,uncore_imc_00/event=0x05,umask=0x0f/" -I 1000 -a sleep 5：每秒输出一次读/写字节数，除以1024²得MB/s - 多socket系统需手动指定
uncore_imc_01等，-a默认只统计socket 0 - 常见失败原因：
Permission denied（BIOS禁用了uncore计数器）、Event not supported（老CPU或ARM平台）、Skylake与Ice Lake事件编码不同不能混用
用pcm-memory.x看摘要级内存带宽（Intel专用，不支持AMD）
pcm-memory.x比perf更易用，但只适用于Intel CPU，且依赖主板BIOS开放uncore访问权限。它不显示“占用率”，而是直接给出当前MEM READ和MEM WRITE的GB/s值，顶部还标注理论最大带宽。
- 编译运行：
git clone https://github.com/opcm/pcm && cd pcm && make && sudo ./pcm-memory.x 1 - 关键字段：
MEM READ和MEM WRITE列即实时带宽，单位GB/s；Max Memory Bandwidth是dmidecode算出的理论上限 - 限制明显：笔记本常因BIOS锁定无法读取；输出不含per-channel拆分；Sapphire Rapids等新平台需拉取最新PCM源码编译
- 注意：数值稳定在理论值60%以下，不等于“带宽被占满”，可能是应用访存模式差（如随机访问）、NUMA跨节点导致有效带宽下降
别把ethtool或/proc/net/dev当“总线带宽”
sudo ethtool eth0显示的是网卡协商速率（如10000Mb/s），cat /proc/net/dev里RX_bytes/TX_bytes是协议栈收发字节数——两者都和PCIe总线或内存总线无关。试图用它们推算“系统总线占用”会得出完全错误的结论。
- PCIe带宽需单独测：用
lspci -vv查link width/speed，再用perf采样uncore_pcie事件（仅部分Intel平台支持） - 内存通道利用率无法直接获取：
dmidecode -t memory只能告诉你插了几条内存、标称频率，但运行时是否双通道激活、是否降频，得靠sudo lshw -class memory结合主板手册交叉验证 - 真正瓶颈往往不在总线本身：即使
pcm-memory.x显示READ只有8GB/s，也可能是CPU缓存未命中率高、TLB压力大，而非内存控制器跑不满
总线带宽不是单一数字，它依赖具体路径（内存→CPU、GPU→CPU、NIC→内存）、NUMA拓扑、固件策略。工具返回的“读写速率”只是某一时段某一路径的观测值，离“占用率”还差一个动态基线——而这个基线，Linux不提供，硬件厂商也不公开。
