cat /proc/cpuinfo | grep "physical id" | sort -u | wc -l 统计去重后的 physical id 数量，即物理CPU颗数；但虚拟化环境或旧内核下可能失效，推荐用 lscpu | grep "CPU socket(s):" 获取准确值。
用 cat /proc/cpuinfo | grep "physical id" | sort -u | wc -l 查物理CPU个数
这个命令本质是统计去重后的 physical id 值数量。每个物理插槽（socket）对应一个 physical id，所以结果就是物理CPU颗数。
常见错误：漏掉 sort -u，直接 wc -l 会把所有行都算进去，得到的是逻辑CPU数而非物理颗数。
注意点：
-
physical id字段在某些虚拟化环境（如 VMware、KVM）中可能恒为 0，此时该命令返回 1，不代表真只有一颗物理 CPU —— 需结合lscpu的CPU socket(s):行交叉验证 - 部分 ARM 服务器或旧内核可能不暴露
physical id，这时该命令输出为空或报错，应切换到lscpu
用 lscpu | grep "CPU socket(s):" 和 "Core(s) per socket:" 直接读取关键字段
lscpu 是最稳的方案，它从内核缓存和 sysfs 统一聚合数据，不依赖 /proc/cpuinfo 的文本解析逻辑，兼容性好、语义清晰。
输出示例：
CPU socket(s): 2 Core(s) per socket: 12 Thread(s) per core: 2
这意味着：2 颗物理 CPU × 每颗 12 核 × 每核 2 线程 = 48 个逻辑 CPU。
关键提醒：
-
Core(s) per socket:是每颗物理 CPU 的**物理核心数**，不是超线程后的逻辑核心；它和/proc/cpuinfo中的cpu cores字段等价，但更可靠 - 如果
Thread(s) per core:是 2，且Core(s) per socket:×CPU socket(s):≠CPU(s):（总逻辑数），说明启用了超线程 - 在容器或轻量级虚拟机中，
lscpu显示的 socket 数可能被限制（如只暴露 1 个），需确认是否受 cgroups 或 CPU pinning 影响
为什么不用 nproc 或 getconf _NPROCESSORS_ONLN 查物理核数？
nproc 只返回当前进程可见的在线逻辑 CPU 数（即 CPU(s): 值），它不区分物理/逻辑、socket/cores，也不体现拓扑结构。
典型误用场景：
- 执行
nproc得到 48，就认为有 48 核物理 CPU —— 实际可能是 2×12×2，物理核心只有 24 个 - 在绑核（taskset）或 NUMA 调优时，仅靠
nproc无法知道 socket 分布，容易跨 NUMA 访存导致性能下降 -
getconf _NPROCESSORS_ONLN行为与nproc几乎一致，同样只反映在线逻辑数，无物理拓扑信息
查完之后容易忽略的三个细节
物理 CPU 数 ≠ 可用计算资源数。真正影响性能的是拓扑感知调度能力，而不仅是数字本身。
务必确认：
- 是否启用超线程：对比
lscpu中Core(s) per socket:×CPU socket(s):和CPU(s):是否相等；不等则存在 SMT，高负载下需评估是否关闭 - CPU 是否在线：有些 BIOS 会 disable 部分 socket，
lscpu的CPU(s):是“在线逻辑数”，而lscpu -a才显示全部（含 offline），避免误判硬件故障 - NUMA 节点分布：用
numactl --hardware查看每个 socket 对应的内存节点，单 socket 上跑跨 NUMA 进程会显著拖慢访存速度
