大家应该都见过这道经典场景：新买的云服务器，16核配置拉满，高高兴兴把程序部署上去，top一敲，愣住了——进程列表里明晃晃挂着接近100%的占用，再按个1看每个核心，只有0号核在拼命工作，剩下15个核集体摸鱼。第一反应基本是"服务器是不是被商家偷偷阉割了？"或者"Linux的内核调度是不是出bug了"。
在我处理过的所有这类咨询里，至少有一半最终发现是程序本身就只写了一个线程，另一半则是启动参数、容器配额、虚拟化配置的问题。真正属于"服务器硬件坏了"的，一个都没遇见过。但"没见过"不等于"不存在"——问题在于你怎么用最短的时间，把这个结论一步步验证出来。别一上来就改内核参数、关节能模式、调CPU调度器，结果忙活半天，发现是个单线程的for循环。
这篇就把我从"看到一核满载"到"定位到具体根因"的完整排查套路写出来。你照着走一遍，基本能给自己一个明确交代。
1. 先别急着怀疑服务器，用这三个命令把"单核"看透
1.1 top按1：确认到底是"单核满载"还是"整体百分比虚高"
很多人看到top第一行%Cpu(s): 100% us就慌了，但这个数字是"所有核心平均占用率"。在一台16核的机器上，即使一个进程把其中一个核打满，平均值也只显示6.25%；反过来，如果%Cpu(s)显示100%，那说明是把全部核心都用完了，根本不存在"只用一核"的问题。
在top界面里按数字键1，顶部会展开成 CPU0、CPU1、CPU2 这样的逐核列表。只有当你看到其中一列停在100%，其余全部徘徊在0%，这才是真正意义上的"只用了一个核"。
按下1之后，你还能顺带确认一个信息：机器物理上到底有多少个核。如果机器本身就只有1核，那一切讨论都到此为止——纯属"买错了配置"，而不是"核心不工作"。这种情况在云服务器上其实不少见，控制台页面清清楚楚写着1核2G，非要跑一个16线程的任务，那肯定只有一个核在工作，别怪系统。
htop是更直观的选择，顶部的色带条会实时显示每个核心的占用，而且能直接看到每个线程的CPU占用，对后续排查特别友好。我的个人习惯是：先用top按1确认核数，再开htop看线程分布。
1.2 ps -eLf 查线程数：程序是"一个人"还是"一队人"
"程序占了一个核"这个描述其实很模糊——进程占了一个核，和"进程内部只有一个线程在跑"是两回事。先用下面这条命令数一下目标进程到底开了多少个线程：
ps -eLf | grep 你的程序名重点看 LWP 这一列，数出有多少个不同行。再用ps -T -p PID | wc -l或top -H -p PID也能看到线程级别的占用情况。判断逻辑如下：
- 线程数等于1或很少：说明程序本身就没有并行设计，问题在程序侧，跳转到第2节。
- 线程数很多，但只有一个线程CPU占用高：要么是被绑核，要么是大量线程在等同一把锁，跳转到第3节或第5节。
- 线程数很多，每个线程都有一定占用，但整体算下来只有100%左右：更像超线程数量不够或者cgroup配额给得紧，跳转到第4节。
1.3 mpstat和pidstat：把逐核、逐线程的账本摊开
如果top的刷新是一屏一屏的，mpstat -P ALL 1就是一秒一秒的账本。这个命令每秒打印一次每个核心的占用率，你对"哪些核在动、动到什么程度"会有一个非常清晰的连续观察。注意mpstat属于sysstat包，没安装的话先装一下：
# Debian/Ubuntu apt install sysstat # CentOS/RHEL yum install sysstatpidstat -t -p PID 1则能把进程内每个线程的CPU占用单独摊开，这一招在判断锁竞争的时候特别有用。举个例子：程序开了32个线程，但只有TID 1456这个线程稳定地占用100%，其他线程几乎全是0%，基本可以断定程序逻辑或运行环境里有"单点瓶颈"，要么是串行化代码，要么是锁。
| 排查目的 | 命令 | 怎么读 |
|---|---|---|
| 确认物理核数与逐核占用 | top后按1 /htop | 核列表里只有1列100%，才算单核满载 |
| 数线程数 | ps -eLf | LWP列有多少行 |
| 逐线程CPU分布 | pidstat -t -p PID 1 | 哪个TID在吃CPU |
| 逐核实时占用 | mpstat -P ALL 1 | 每秒各核占用 |
这个初检做下来，你应该能回答两个问题：物理核数够不够；进程里有没有多个线程。接下来分情况处理。
2. 程序本身就是单线程设计：一核满载其实是"正确答案"
2.1 单线程的世界观
先接受一个事实：如果一个程序从上到下就一条执行流水线，哪怕你给它一百个核，它也只能一个核一个核地跑。这不是服务器问题，也不是操作系统问题，更不是所谓的"CPU智能核心调度"能解决的——Linux内核的CFS调度器非常聪明，但它再聪明，也不会把一个串行for循环拆成多份分给不同核心执行。调度器只能调度"程序暴露出来的可并行单元"，也就是线程或进程。程序没有线程，它就只能在一个核上排队。
这类程序很常见：一个扫描脚本、一段数据处理逻辑、一个串行执行大量任务的命令行程序。写的时候没有任何并行设计，跑起来自然就是一核满载、多核摸鱼。这种情况下程序行为完全正常，属于"应该接受的结果"，而不是故障。
搞清楚这个问题有一个土办法：直接把程序跑起来，看它启动后有没有创建多个线程。一个从启动到结束都没分过身的程序，你给它加核心也没用。
2.2 你以为的多线程，实际被语言运行时锁住的单线程
比"纯单线程"更容易让人误解的，是用多线程语言写出来的"假并行"。最典型的是这两个：
- Python：即使你用
threading开了一堆线程，只要做的是CPU密集计算，实际仍然只有一个核心在工作。原因是 CPython 解释器有全局解释器锁（GIL），同一时刻只允许一个线程执行Python字节码。多线程在Python里更适合处理I/O等待，比如并发请求外部接口；CPU密集型任务想占满多核，得用multiprocessing起多个进程，或者把热点逻辑写成 C 扩展并释放GIL。 - Node.js：JavaScript 代码本身跑在单线程事件循环上。大量并发请求看着很厉害，那是靠异步I/O让出CPU实现的，一旦遇到CPU密集的逻辑（比如JSON.parse超大数据、图像处理），照样只有一个核在烧。想用多核，要用
worker_threads或者pm2 cluster模式起多个进程。
其它语言也有类似现象：Ruby 的 GVL、PHP 传统的单进程模型等。遇到这类情况，正确解法不是去改内核参数，而是改写程序，让它用上真正的并行模型。
这里给一个非常直观的验证方法：在代码里主动创建8个线程，每个线程做一个死循环计算，看top里是1个核满载还是8个核满载。如果仍然只有1个核，说明你的语言运行时存在全局锁；如果8个核都动了，说明并行模型本身没问题，瓶颈在你的业务逻辑里。
2.3 配置不当导致"明明是多进程却只用一核"的服务
还有一类常见的"一核满载"来自中间件的默认配置或错误配置。举两个我反复见到的例子：
- Nginx：
worker_processes如果写成1，那么整个Nginx就只有一个工作进程，所有请求都在这一个进程里处理，再多核也白搭。正确做法是设成auto，或者按物理核数填。这个配置真的非常容易被改错，尤其是从网上复制配置片段的时候。 - Gunicorn：
workers不配置时默认只有1个worker进程，无论你服务器是几核，跑起来的Python WSGI应用都单核。类似的还有 uWSGI、Celery 的并发参数，以及各种Java应用的线程池默认值。
排查这类问题，去翻一下程序的官方文档里的"并发"或"worker"配置，看看默认值是多少。很多时候答案就藏在一行配置里，改完重启即好。
3. CPU亲和性检查：程序被 taskset 或 systemd 悄悄绑在了单核上
3.1 两条命令判断亲和性
如果程序确实开了多线程，但还是只有一个核在跑，就需要怀疑是不是"被系统或启动脚本限制了运行范围"。Linux 上控制进程只跑在哪些核心上的机制叫 CPU 亲和性（CPU affinity），最常用的工具是taskset。
查看某个进程的亲和性：
taskset -cp PID输出格式一般是pid 12345's current affinity list: 0-15或者3。前者表示这个进程可以在0到15号所有核心上运行，后者表示它被限制在3号核上。看到的是一个数字而不是一个区间，那基本就破案了。
用taskset -apc PID还能看到进程内所有线程的亲和性列表。注意有些程序主线程和子线程的亲和性不一致，只查主线程容易被骗。
3.2 谁在背后绑核：systemd、启动脚本、云平台
检查到亲和性是单个核之后，下一步是顺藤摸瓜找设置它的地方。常见的"偷绑"来源按概率排序：
- systemd service：在服务配置里写了
CPUAffinity=0，表示只允许在0号核上跑。用systemctl cat 服务名看一眼，有CPUAffinity就删掉，然后systemctl daemon-reload再重启服务。 - 启动脚本里用了 taskset 或 numactl：有些团队为了"防止多进程抢占性能"，会在启动命令前加
taskset -c 0，例如taskset -c 0 ./server。改起来很简单，但要先问一句：当年为什么加？如果是NUMA优化场景，盲改可能适得其反。 - 程序自己调用
sched_setaffinity或pthread_setaffinity_np：这种写在代码里的绑核，在外部用taskset改是不生效的，因为程序启动后又会把自己绑回去，只能改代码重新编译。 - 云平台/容器编排层的agent：部分老旧的私有云模板或个别托管中间件的agent，会以"性能优化"名义把进程绑到指定核。这种需要去搜一下相关agent的配置项。
3.3 解除绑核的正确姿势与代价
临时解除某进程的亲和性限制：
taskset -apc 0-15 PID注意-a参数很关键。taskset默认只修改主线程，如果不加-a，子线程依然被限制在原来的核上，你会看到"改了好像又没改"的诡异现象。
关于"代价"要泼一盆冷水：绑核这件事在特定场景下是有价值的。高频交易、实时音视频处理，绑核能减少线程迁移带来的cache miss和调度延迟；NUMA体系下把进程固定在一个节点上，内存访问更近，反而更快。所以不要一看到taskset就喊"垃圾配置"，先搞清楚当年的意图，确认它不是导致问题的原因再动手。
4. 容器与虚拟化环境的"隐形单核"：配额、cgroup 和 vCPU
4.1 Docker的--cpus参数到底改了Linux的什么
很多人在云服务器上部署，下意识以为"我的ECS有8核，容器里自然也能用8核"。但这个结论太乐观：如果你用docker run --cpus=1启动了容器，即使物理机有32核，容器内的程序最多也只能使用1个核心的CPU时间。
注意--cpus的语义是"CPU配额"，不是绑核。它通过 cgroup 的 CFS 配额实现，也就是一段时间内给这个容器分配多少个CPU周期。一个非常贴切的类比是：全公司只有一个工位，程序虽然可以在不同工位之间移动，但任何时刻只有一个工位有人干活——表现出来就是top里某列100%，换核跑但总数不变。
检查容器内自己的配额，先看对应文件：
# cgroup v2（新版系统） cat /sys/fs/cgroup/cpu.max # cgroup v1（旧版系统） cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us cat /sys/fs/cgroup/cpu/cpu.cfs_period_uscgroup v2 的输出是两列，第一列 quota、第二列 period。100000 100000表示1核，200000 100000表示2核，max 100000表示不限制。cgroup v1 里，quota 和 period 相等时也是1核，quota 为-1表示不限制。Kubernetes 里对应的配置是resources.limits.cpu: "1"，含义一样。排查的时候别只盯 Dockerfile，仔细看 Deployment 的 yaml，很多"程序只用一个核"的诡异现象，最后都发现是复核了一遍 Kubernetes 资源配额。
4.2 虚拟机只有1个vCPU，系统也只能看到1个核
如果你的"服务器"实际是台虚拟机（无论 OpenStack、VMware 还是 KVM），那么虚拟机的CPU个数由虚拟化平台分配。在VMware里，给虚拟机配了多少个vCPU，操作系统就只看得到多少个核。一台32核的宿主机，如果虚拟机只配了1个vCPU，那它内部lscpu看到的就只有1核。
确认命令：
lscpu | grep "^CPU(s)" nproc看到CPU(s): 1，那就是虚拟机本身只有1个核，和程序无关。检查方向：去云平台控制台看实例规格，或者找虚拟化管理员确认vCPU数量。云服务器场景里，ECS实例规格页写着"2核4G"就是2 vCPU，写着"8核16G"就是8 vCPU，一般不会虚标。但私有云环境就难说，我排查过一个开放云平台，模板建出来的机器统一只有1 vCPU，业务方先查自己代码查了三天，最后发现是平台模板配置错了。
4.3 关于超线程与"核数虚标"
另外要注意"核"的定义。lscpu输出里有几行：
Socket(s)：物理CPU插槽数Core(s) per socket：每个插槽里的物理核数Thread(s) per core：每个物理核上的超线程数CPU(s)：逻辑CPU总数，一般等于 Socket × Core × Thread
超线程打开后，CPU(s)显示的数量是物理核的两倍。比如物理8核16线程的机器，lscpu会显示CPU(s): 16。对绝大多数应用来说，这16个逻辑核都能被调度，但从性能角度说，1个物理核的2个超线程共享执行单元，跑满一条超线程时，另一条能分到的算力有限。这也是"看着有16核，程序只能跑出8核性能"的常见原因——不是故障，是物理结构决定了。
5. 程序有很多线程却还是"一核跑满"：锁竞争与软中断单核瓶颈
5.1 怎么确认锁竞争
排除了单线程、绑核、配额，还剩下最后一个高频原因：程序开了很多线程，但线程之间为了争抢同一个共享资源排起了"单人大队"，整体表现就是只有一个线程在真正执行，其余线程全在等锁。
锁竞争在top里很难直接看出来，要借助更细的工具：
pidstat -t -p PID 1：观察各个线程的%CPU分布。如果99%的CPU集中在一个线程上，其他线程几乎为0，而且它们不是被放在单独的核上工作，而是阻塞在锁等待上，锁竞争的可能性就很大。perf top -p PID：看热点函数。热点如果是pthread_mutex_lock、futex相关函数，基本可以实锤锁竞争。- 用
strace -p PID短暂抓一下系统调用，如果大量时间花在futex(2)等待上，说明线程们都在同一把锁上排队。
5.2 经典"大锁"现场
锁竞争的场景千千万，但常见的就那么几类：
- 共享日志锁：程序把所有线程的日志都往同一个文件里写，日志库内部有一把全局锁，写日志的量一大，所有线程都在等这把锁，计算部分反而被拖住。表现为CPU集中，甚至还会出现单核
sys占用高。 - 连接池过热：线程池里的线程都要用同一个数据库连接池取连接，池子默认最大连接数过小，线程们取不到连接就全部阻塞。表面上看是"只有一个核在动"，实际是"只有一个线程在干活，其余全在排队"。
- 引用计数/垃圾回收：某些带全局状态的语言运行时，在线程增删对象时会短暂地锁住全局状态；对象一多，这个"短暂"就变成长时间等待。比如老的 Python 版本里大量创建临时对象时，GIL 的释放和重新获取会非常频繁，CPU 上下文切换开销激增。
这类问题的解法不在系统侧，而在程序侧：降低锁粒度、用无锁数据结构、分片日志、扩大连接池、在热点路径上用读写锁替代互斥锁。实在不行就多进程，让每个进程拥有独立的锁域。
5.3 网卡中断全砸在一个核上
还有一个经常被误判为"程序只用单核"的特殊场景：网络中断收包全在一个核上处理。如果你的业务是大量收包的网络服务，即使程序本身多线程，网卡中断和软中断（softirq）集中在一个CPU上处理，这一个核会被打满，其他核闲得没事。
检查方法：
cat /proc/interrupts看网卡中断号那一行，每个CPU列的数字如果严重不平衡——比如CPU0有上千万次，其他CPU几乎为0——就说明中断没有做负载均衡。
解决方案也很成熟：开启 Receive Packet Steering（RPS），把收包队列分散到多个核心：
echo ffff > /sys/class/net/eth0/queues/rx-0/rps_cpus这里的ffff是位掩码，表示允许中断使用前16个核心。更彻底的方案是用多队列网卡配合irqbalance，让每个网卡队列绑定到不同CPU。这类方案网上资料很多，关键是先认出症状：单核si（softirq）占用异常高，其他核空闲。
5.4 NUMA拓扑让任务"恋家"
最后提一下 NUMA（非统一内存访问架构）。多路服务器的物理内存并不是均匀地挂在所有CPU旁边，而是每个CPU有一块本地内存。内核为了让任务少走"长途"，会尽量把任务和它使用的内存安排在同一节点上，这是 Linux 的自动NUMA平衡策略。
表现是什么呢？一台双路服务器，每个CPU有8个核，程序的内存主要分配在节点0上，那么调度器会倾向于让这个程序的所有线程都在节点0的8个核上跑。业务方用top按了1，看到的是"节点1的核全闲，节点0的核全忙"，容易误以为"其他核心不工作"。这其实不是故障，但确实损失了节点1的算力。
要评估这种场景：
numactl --hardware看节点分布和内存分布。如果确定要跨节点利用算力，可以用numactl --interleave=all改变内存分配策略；也可以手动设置taskset把部分线程放到节点1，但代价是远端内存访问变慢，要测试确认是赚是赔。
6. 我处理这类问题时的固定排查顺序与两条实战心得
6.1 一张排查决策表
把前面所有内容收敛成一张决策表。处理"程序只用一个核"的问题时，我固定按这个顺序走：
| 步骤 | 检查项 | 命令/文件 | 判定标准 |
|---|---|---|---|
| 1 | 物理核数到底多少 | lscpu/nproc | 少于预期，去查实例规格或vCPU配置 |
| 2 | 进程开了多少线程 | ps -eLf/top -H | 线程数约等于1，程序设计问题 |
| 3 | 是否被绑核 | taskset -cp PID | 亲和性列表是单一数字，绑核嫌疑大 |
| 4 | 是否有CPU配额限制 | cat /sys/fs/cgroup/cpu.max | quota等于period就是1核 |
| 5 | 线程是否在等锁 | pidstat -t/perf top | 热点在锁函数，锁竞争实锤 |
| 6 | 中断是否全在CPU0 | cat /proc/interrupts | 某中断号的CPU0列远超其他CPU |
| 7 | 是不是NUMA局部性 | numactl --hardware | 节点间内存不均衡 |
这套顺序从"最基础"到"最精细"排列，目的是用最快速度排除常见原因。我见过有人一上来就开perf分析锁竞争，折腾半天，结果发现服务启动脚本里就写了个taskset -c 0。
6.2 两条实战心得
心得一：服务器上只看top不深究，是最大的坑。top第一行的%Cpu(s)是平均值，非常具有迷惑性。一个进程打满1个核，在8核机器上是12.5%，在16核机器上是6.25%。光看这个数字，你根本判断不了"是只用一核还是用得不够满"。一定要按1看逐核分布，再用pidstat看线程级别，这是把问题边界划清楚的前提。另外，排查的时候记得先ssh连上去，别只盯着监控面板的分时曲线，命令行给的信息永远是第一手的。
心得二：遇到这类问题，先想清楚"这个程序在CPU密集场景下有没有并行的可能"。纯串行的计算任务，改一万遍内核参数也不会用上多核；而中间件、框架类的程序，往往是一行配置就能解决。我最近就碰到一套生产环境的Nginx被改成worker_processes 1，团队排查了两天业务慢的问题，最后发现是这个配置在作祟——改成auto之后立竿见影。改完记得做好变更留痕：谁改的、为什么改、验证结果如何。很多莫名其妙的性能问题，翻翻历史配置就能看到当初某个人无心写下的那一行。
