Linux无标准内存带宽利用率指标,/proc/meminfo、free、vmstat仅反映内存用量与页面活动,无法测量DRAM实际读写速率;需用perf(依赖CPU型号查uncore事件)或Intel PCM的pcm-memory.x获取实时GB/s级带宽。
Linux 没有“内存带宽利用率”这个现成指标,/proc/meminfo、free、vmstat 都不提供它——它们只告诉你用了多少内存、换了多少页,而不是内存控制器上每秒实际传输了多少字节。
Intel 平台最通用的方式是用 perf 直接读取内存控制器(uncore)性能计数器。关键不是硬记命令,而是先确认当前 CPU 支持哪些事件:
perf list | grep -i memory 查看可用事件,重点关注类似 uncore_imc_00/event=0x04,umask=0x0f/(DDR 读)和 uncore_imc_00/event=0x05,umask=0x0f/(DDR 写)的条目event is not supported
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-a 并手动解析每个 uncore_imc_* 设备(比如 uncore_imc_01)Intel PCM 工具链里的 pcm-memory.x 是最接近“开箱即用”的方案,但它不是系统自带,也不兼容 AMD:
apt install intel-cmt-cat 不包含完整 PCMsudo ./pcm-memory.x 1 后,直接看 MEM READ 和 MEM WRITE 列,单位是 GB/s;顶部还会显示理论峰值(如 Max Memory Bandwidth: 51.2 GB/s)Failed to detect memory controller
pcm-memory.x 完全不体现很多人误以为 free -h 里 available 接近 0 就说明带宽被打满了,这是典型混淆:
free 的 used 是内核统计的“已分配页”,不含硬件层面的突发访存压力free 显示一切正常vmstat 的 si/so 是 swap I/O,bi/bo 是块设备 I/O,两者都和内存控制器吞吐无关perf 或 PCM 抓内存带宽不是单一数值:多通道下各 channel 独立计数,NUMA 架构中跨节点访问会引入额外延迟和隐性带宽争抢,而绝大多数工具默认只报告 socket 0 或聚合值,容易掩盖真实瓶颈点。