Linux 系统 CPU 信息查看：从入门到实战
这一章，我们来聊聊怎么看透你的 CPU。
你想想看，服务器卡了，你第一个想去哪看？肯定是 CPU 嘛。但很多人上来就敲个 top，然后盯着那个百分比发呆。这哪够啊？
我今天就带你走一遍，从硬件参数到实时负载，把 CPU 的老底翻个底朝天。内容不多，但都是我这几年摸爬滚打攒下来的经验。
/proc/cpuinfo：系统的「认证书」
这个虚拟文件，是 CPU 的户口本。里面的字段很全，但关键信息就那么几个。
我一般用 cat /proc/cpuinfo 或者 grep 过滤。来看实操：
# 查看物理 CPU 颗数
grep "physical id" /proc/cpuinfo | sort -u | wc -l
# 查看每颗 CPU 的核数
grep "cpu cores" /proc/cpuinfo | uniq
# 查看逻辑 CPU 总数（线程数）
grep -c "processor" /proc/cpuinfo核心字段解读：
| 字段 | 含义 | 实战意义 |
|---|---|---|
| physical id | 物理 CPU 插槽编号 | 区分真实的物理 CPU 个数 |
| cpu cores | 每个物理 CPU 的内核数 | 物理核 = socket × cores |
| processor | 逻辑 CPU 编号 | 超线程开启后，数量 = 物理核 × 2 |
| model name | CPU 型号与主频 | 判断芯片代际，基准频率多在此 |
| flags | CPU 特性标记 | 查看是否支持虚拟化、AES 等 |
一点经验：我曾遇到过一台服务器，买的是 32 核，但 /proc/cpuinfo 只显示 16 个 processor。查了半天，发现是 BIOS 里超线程被关了。你想想看，花了两份钱，只拿到一半的性能。所以新机器到手，先用这招验一下。
lscpu：更人性化的概览
说实话，lscpu 是我个人最常用的工具。它把 /proc/cpuinfo 里的散装信息，整理成了一目了然的表格。不用再去 grep 来 grep 去了。
$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 158
Model name: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
Stepping: 9
CPU MHz: 800.000
CPU max MHz: 3800.0000
CPU min MHz: 800.0000
BogoMIPS: 5616.00
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 6144K
NUMA node0 CPU(s): 0-7这里的信息比 /proc/cpuinfo 更集中。我重点关注这么几项：
- CPU(s)：逻辑 CPU 总数，判断系统并发能力。
- Core(s) per socket + Socket(s)：算出物理核数，理解硬件真实算力。
- CPU max/min MHz：动态调频范围。如果服务器长期跑在 min，说明要么没负载，要么散热有问题。
- NUMA node：这个后面讲内存时会细说，多路服务器关键看这个。
- Cache：L1/L2/L3 各级缓存。有些应用对缓存大小特别敏感。
实战对比：
| 场景 | 推荐工具 | 理由 |
|---|---|---|
| 快速了解硬件配置 | lscpu | 信息集中，一看就懂 |
| 排查超线程异常 | /proc/cpuinfo | 能精确比对 processor 与 core id 关系 |
| 检查特性支持（如虚拟化） | /proc/cpuinfo | flags 字段包含所有 CPU 特性 |
top：动态的「晴雨表」
静态信息看完了，现在来看看实时的。
top 大家都会用，但很多人只盯着 %CPU 那一列。其实顶部那几行，信息量更大。
top - 14:23:45 up 12 days, 3:02, 2 users, load average: 0.15, 0.20, 0.18
Tasks: 203 total, 1 running, 202 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.3 us, 0.7 sy, 0.0 ni, 96.7 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 15983.3 total, 4812.1 free, 4932.5 used, 6238.7 buff/cache
MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 10196.0 avail Mem这部分我习惯快速扫一眼 load average 和 %Cpu(s) 行。
- load average：1分钟、5分钟、15分钟的平均负载。数值超过 CPU 核数时，说明队列在排队了。比如 8 核机器，load 超过 8 就意味着有进程在等 CPU。
- us (user)：用户态 CPU 时间，应用程序跑出来的。
- sy (system)：内核态 CPU 时间，系统调用多了这个会上涨。
- id (idle)：空闲时间。一直很高说明 CPU 没吃饱。
- wa (iowait)：CPU 等 I/O 完成的时间。这个值高了，问题大概率出在磁盘或网络，不是 CPU 本身。
避坑指南：我曾经遇到一台数据库服务器，wa 飙到 30%，但 CPU 空闲还有 60%。团队里有人说是 CPU 瓶颈，加 CPU 就能解决。我进去一看，wa 明显是 I/O 在拖后腿。后来换了一块 SSD，wa 直接降到 2%。你想想看，方向错了，花再多钱也白搭。
进阶：htop 与进程级排查
如果你觉得 top 的交互方式太原始，试试 htop。它支持鼠标操作，颜色分区，还能看树状进程关系。
# 安装 htop（多数系统需要）
sudo apt install htop # Debian/Ubuntu
sudo yum install htop # CentOS/RHEL在 top 或 htop 里，按 P 键可以按 CPU 使用率排序。找到那个吃 CPU 的进程后，用 strace 或 perf 进一步分析它在干什么。
不过那已经超出本章范围了。咱们今天先做到「看得懂」，后面再讲「查得准」。
实战小贴士：综合应用的场景
我习惯的排查流程是这样的：
- 先
lscpu：确认硬件配置，看核数、频率、是否开启超线程。 - 再看
top：看负载和 CPU 分布，尤其是 user/system/iowait 的比例。 - 如果发现异常：回
/proc/cpuinfo核对 flags，或者用grep扫特定进程的 CPU 亲和性。
一个小技巧：多路服务器经常有 NUMA 问题。用 numactl --hardware 可以看内存节点分布。我曾见过一个 Java 应用，因为绑死在错误的 NUMA 节点上，性能垮了 30%。解绑后立刻恢复正常。嗯，这里要注意，不是所有程序都默认感知 NUMA 的。
好了，CPU 信息查看这块，核心就是这几个命令。搞清楚它们看什么、怎么看，后面调优才有依据。