Linux CPU核心规划需匹配业务负载特征：计算密集型重单核性能，I/O密集型可适度启用超线程，混合型按活跃线程+20%冗余估算；须用mpstat、vmstat、perf等工具量化瓶颈，避免盲目堆核；虚拟化/云环境需关注物理核映射与NUMA亲和性；生产环境预留15%～25%弹性空间。
Linux系统CPU核心数规划不能只看“越多越好”，关键在于匹配业务负载特征、应用并发模型和资源争用情况。盲目堆核可能导致上下文切换开销上升、缓存效率下降，甚至性能倒退。
识别真实负载类型：计算密集型 vs I/O密集型
同一台服务器跑Web服务和视频转码，对CPU的需求逻辑完全不同：
- 计算密集型（如科学计算、编译、AI推理）：优先追求单核性能与核心总数平衡，通常建议物理核心数 ≥ 并发线程数 × 0.8～1.2，避免超线程带来的缓存竞争；
- I/O密集型（如数据库连接池、HTTP API网关）：更依赖高并发处理能力，可适度启用超线程（HT），但需验证——某些场景下开启HT反而因内存带宽或L3缓存争用导致延迟升高；
- 混合型负载（如Java微服务+后台定时任务）：建议按峰值时段的平均活跃线程数 + 20%冗余估算，再结合
pidstat -t -p <PID> 1观察实际线程调度分布。
用工具量化当前瓶颈，而非凭经验拍板
直接看top或htop的CPU使用率容易误判。真正需要关注的是：
-
mpstat -P ALL 1：检查各核心是否严重不均——若个别核心持续95%+而其他低于30%，说明存在锁竞争或单线程瓶颈，加核无效； -
vmstat 1中的cs（context switch）值：持续高于10k/s且伴随高us或sy，大概率是线程/进程过多引发调度压力，此时应优化应用并发模型，而非增加CPU； -
perf stat -e cycles,instructions,cache-misses,task-clock -p <PID>：定位单个进程是否存在指令级效率问题（如IPC偏低、缓存未命中率＞5%），这类问题加核无法缓解。
考虑虚拟化与容器环境的资源映射关系
在KVM或Docker中，CPU配额不是简单除法：
- KVM虚机设置
vcpus=4不等于获得4个物理核——若宿主机启用了CPU pinning且绑定了不连续核心，NUMA跨节点访问会拖慢内存延迟； - Docker使用
--cpus=2.5时，cfs_quota机制按时间片分配，但实际调度仍受宿主机整体负载影响；建议配合--cpuset-cpus="0-3"显式绑定物理核，并通过numactl --cpunodebind=0 --membind=0控制内存亲和性； - 云平台（如AWS EC2、阿里云ECS）的vCPU是超线程逻辑核，需查阅实例规格文档确认底层物理核数，避免在高主频单核场景误配多核实例。
留出合理弹性空间，但拒绝过度预留
生产环境CPU容量不是静态值，需动态校准：
- 日常监控保留15%～25%空闲CPU容量，用于应对突发流量、内核中断、日志刷盘等不可控开销；
- 批量任务（如ETL、报表生成）应与在线服务错峰运行，可通过
cron+taskset限定其仅使用指定核心，避免干扰SLA； - 每季度用
stress-ng --cpu <N> --timeout 60s做轻量压测，观察load average与响应延迟变化拐点，反向验证当前核心配置是否仍适用。
