CPU负载与硬件信息需区分：负载用uptime/top/vmstat查看运行压力，硬件信息用lscpu查物理规格；负载是就绪+运行进程数的平均值，非使用率；lscpu为推荐一站式命令，避免误读/proc/cpuinfo或dmesg等。
直接看结论：CPU负载和硬件信息是两件事，别混着查。负载反映当前运行压力（用 uptime、top、vmstat），硬件信息描述物理规格（用 lscpu、/proc/cpuinfo、dmesg）。查错对象，结果就准。
怎么看CPU实时负载（不是型号，不是核心数）
负载不是使用率，而是“等待运行的进程数 + 正在运行的进程数”的平均值，它比 %Cpu(s) 更早暴露瓶颈。
-
uptime输出末尾三个数字（1/5/15分钟平均负载），如果数值 > 逻辑CPU总数（nproc结果），说明队列已积压 -
top中第一行的load average:和uptime一致；按1键可展开各核负载，避免误判单核打满而整体尚可 -
vmstat 1看r列：持续 > CPU逻辑数（如8核机器长期 r ≥ 9），说明CPU资源确实不够用，不是IO或内存拖慢的假象 - 注意陷阱：
wa高时负载也高，但根因是磁盘慢，不是CPU弱；此时r可能不大，top里 %us/%sy 却很低
怎么快速确认CPU物理规格（型号/核心/线程/缓存）
lscpu 是唯一推荐的一站式命令，信息全、格式稳、不依赖root，比解析 /proc/cpuinfo 安全省力。
-
CPU(s):是逻辑CPU总数（含超线程），即nproc输出值 -
Core(s) per socket:×Socket(s):= 物理核心总数；若Thread(s) per core:为2，说明启用了超线程 -
Model name:是真实型号，比如Intel(R) Xeon(R) Gold 6248R，比/proc/cpuinfo里重复刷屏的字段更干净 - 别硬啃
/proc/cpuinfo：它每核一段，逻辑混乱；grep "model name" /proc/cpuinfo | uniq能凑合用，但遇到多代混插（如老CPU+新CPU）可能漏型号
哪些命令容易查偏或失效
几个常见误操作，看似有输出，实际答非所问：
-
cat /proc/cpuinfo | grep "cpu cores"：只显示每个物理CPU的核心数，不告诉你有几个物理CPU；physical id才是关键，但需配合uniq -c统计，步骤多易出错 -
mpstat -P ALL 1：能看每核使用率，但默认不显示负载值；新手常以为“%usr高=负载高”，其实负载高但%usr低（比如大量进程卡在锁或IO）很常见 -
dmesg | grep -i cpu：只输出内核启动时识别到的CPU信息，无法反映热插拔或虚拟机里动态分配的情况；云主机上基本没用 -
perf top：需要sudo，且采样本身会轻微扰动系统；它看的是“谁在用CPU”，不是“CPU有多忙”，定位热点进程可以，查负载不行
负载和硬件信息交叉验证的关键点
真正排查性能问题时，必须把两者对照看：
- 负载高 +
lscpu显示只有2核 → 确实要扩容；负载高 + 显示32核但top里仅1核跑满 → 很可能是单线程程序，不是CPU不够 -
vmstat的r值长期为0，但wa>30% → 检查磁盘，别去翻CPU型号 - 虚拟机里
lscpu的Socket(s)是1，Core(s) per socket是4，但宿主机其实是2路×16核 → 这种规格限制由hypervisor控制，/proc/cpuinfo里的physical id在VM里不可信
硬件信息是静态快照，负载是动态水位。拿型号当性能依据，就像拿汽车排量猜它此刻是不是堵在路上。
