应使用perf等系统级工具交叉验证CPU绑定、缓存未命中率及NUMA内存访问模式，重点计算cache-misses/cache-references比值，超15%表明L2局部性差；结合pidstat、numastat、proxy_cache_status等确认优化效果。
排查多核 CPU 缓存命中率低下导致的 Nginx 性能下降，不能依赖 Nginx 自身日志或配置项——它没有暴露 L1/L2/L3 缓存行为的指标。必须借助操作系统级工具，从进程绑定稳定性、缓存未命中比例、NUMA 内存访问模式三方面交叉验证。
看 cache-misses 与 cache-references 的比值
这是最直接的量化依据。用 perf 对单个 worker 进程采样：
- 先获取 worker PID：
pgrep nginx | grep -v master - 对 PID 12345 采样 10 秒：
perf stat -e cycles,instructions,cache-references,cache-misses -p 12345 sleep 10 - 重点计算
cache-misses / cache-references百分比：超过 15% 表明 L2 缓存局部性差；优化后若降至 8%–10%，说明绑定有效 - 对比开启
worker_cpu_affinity前后的该比值，下降 15%–30% 是典型收益
查 worker 进程是否稳定驻留同一 CPU 核
频繁跨核调度会清空 L1/L2 缓存，直接拉低命中率：
- 运行
pidstat -t -p $(pgrep nginx) 1，观察各线程的 CPU 列：数值持续跳变（如在 0/3/7 间来回）说明未有效绑定 - 用
taskset -cp PID检查实际掩码，确认是否与worker_cpu_affinity配置一致 - 在 NUMA 系统中，加跑
numastat -p PID：若 foreign 内存页占比 >5%，说明存在跨节点访问，放大缓存失效
结合 proxy_cache_status 和共享内存状态交叉印证
CPU 缓存效率提升最终会反映在更高层缓存服务表现上：
- 启用
$upstream_cache_status日志变量，压测前后对比 HIT 率变化；小包高并发场景下 HIT 率明显上升，说明 keys_zone 元数据更稳定驻留于 L2 - 检查
proxy_cache_path中 keys_zone 的 slab 使用情况（通过nginx -T找路径，再用slab_stat工具），碎片率低、LRU 淘汰减少，佐证缓存索引访问局部性改善 - 确保
use_temp_path=off和open_file_cache已启用，否则磁盘 I/O 抖动会掩盖 CPU 缓存优化效果
排除常见误判干扰
很多“命中率低”的判断其实源于测量偏差：
- 不用
top或htop的 %CPU 平均值：它无法区分指令缓存（I-Cache）和数据缓存（D-Cache）行为 - 不单独看单次 perf 采样：需在稳定压测流量下连续采样 3–5 次，取 cache-misses 占比中位数
- 确认内核未启用激进的节能策略（如 intel_idle.max_cstate=1），这类设置会导致核心频繁进出 C-state，破坏缓存热态
