linux中free和vmstat无法检测内存带宽瓶颈，需用perf或pcm-memory.x测量ddr读写速率；perf需按cpu代际指定uncore_imc事件，pcm-memory.x更直观但仅限intel；多通道/numa下须分socket/channel采样避免误判。
Linux 没有 free 或 vmstat 能查内存带宽
很多人一看到“内存瓶颈”就跑去看 free -h 或 vmstat 1，结果发现 MemAvailable 还剩 8GB、si/so 几乎为 0，就以为内存没问题——但程序照样卡顿、延迟飙升。这是因为：free 只告诉你“还剩多少空间”，vmstat 的 pgpgin/pgpgout 统计的是页换入换出次数，不是 DRAM 控制器上实际传输的字节数。哪怕内存充足，只要程序密集随机访问大数组（比如科学计算、数据库 buffer pool 扫描），就能打满内存控制器带宽，而这些工具完全无感。
用 perf 抓取真实 DDR 读写速率（Intel 平台）
perf 是最通用、无需额外编译的方案，但它依赖 CPU 硬件事件，不同代际 Intel CPU 的事件名差异很大，不能照搬网上旧教程。
- 先确认支持的内存事件：
sudo perf list | grep -i imc（Skylake 及以后常见uncore_imc_00/event=0x04,umask=0x0f/表示读，0x05表示写） - 单次采样（单位是 bytes，需手动换算）：
sudo perf stat -e uncore_imc_00/event=0x04,umask=0x0f/,uncore_imc_00/event=0x05,umask=0x0f/ -I 1000 -a sleep 5 - 输出里两列数字分别是每秒读/写字节数；除以
1024*1024得 MB/s，再除以1024得 GB/s - 注意：
-a才能监控所有 socket；若机器是双路，uncore_imc_00只覆盖第一个 CPU，漏掉另一半带宽
用 pcm-memory.x 快速看总带宽和上限
Intel PCM 工具对非内核开发者更友好，直接输出可读数值，但只支持 Intel，且新版 CPU（如 Sapphire Rapids）需从 GitHub 主分支拉最新源码编译，否则识别不到正确事件。
- 安装：从 https://www.php.cn/link/97e69b76f0956017e04ad3c9d74ce5e3 下载，
make编译，不建议用系统包管理器装的旧版 - 运行：
sudo ./pcm-memory.x 1（每秒刷新） - 关键字段：
MEM READ和MEM WRITE列是实时 GB/s；顶部Max Memory Bandwidth: XX.X GB/s是理论峰值（如双通道 DDR4-2666 约 42 GB/s） - 瓶颈判断：持续 >80% 峰值且伴随应用延迟上升，基本可断定是内存带宽瓶颈，不是 CPU 或 cache 问题
多通道/NUMA 场景下容易被忽略的采样偏差
内存带宽不是全局一个数。四通道内存下，每个 channel 独立计数；NUMA 架构中，跨节点访问会走 QPI/UPI 链路，既增加延迟，又隐性占用远端节点的内存带宽。但 perf 默认只采集 socket 0，pcm-memory.x 默认汇总所有 controller —— 如果你只盯着一个值看，可能误判。
- 查 NUMA topology：
numactl --hardware，确认有几个 nodes、各 node 对应哪些 memory channels - 查进程绑定：
numastat -p <pid></pid>，看它主要在哪个 node 分配内存 - 真要定位到 channel 级别，得用
perf分别指定uncore_imc_00、uncore_imc_01等实例，再手工加总，没脚本几乎没法日常用
