Linux查看进程核心使用，taskset命令详解

本文深入解析了在Linux系统中精准查看和控制进程CPU核心使用情况的关键方法，强调最可靠的实时监控手段是通过`ps -o pid,psr,comm -p`命令直接读取`psr`列（当前实际运行的物理CPU编号），而非依赖易误导的`taskset -p`显示的亲和性掩码；同时系统梳理了`taskset`命令的正确用法、常见误操作陷阱（如选项顺序错误、多线程绑定失效原因），并指出单靠`taskset`无法实现真正稳定隔离——需结合`-a`参数处理多线程、或升级至`systemd CPUAffinity`、`cpuset cgroup`等持久化机制，帮你避开“看似绑定了却仍在跳核”的实践坑，真正掌控性能关键的CPU调度细节。

怎么查进程当前在哪个物理 CPU 核心上运行

直接看 psr 列最准，不是看亲和性掩码——因为掩码只表示“允许跑在哪”，而 psr（processor）显示的是“此刻实际在哪个核上执行”。

用这行命令实时观察：

ps -o pid,psr,comm -p <pid>

输出中 psr 值就是当前调度到的 CPU 编号（从 0 开始）。如果值来回跳变，说明进程还在多个核之间迁移；如果稳定不变，才说明绑定已起作用或负载极低。

• psr 是瞬时快照，建议多执行几次或用 watch -n 0.5 'ps -o pid,psr,comm -p ' 持续盯住
• 别只信 taskset -p 输出的十六进制掩码（比如 0xff），它可能只是“全开放”，不代表正在跑在哪
• 多线程程序中，ps -o pid,psr,comm -p 只显示主线程（TID == PID）的 psr；要看所有线程，得用 ps -T -p 配合 psr 列

taskset -c 和 taskset -p 的区别与误用点

taskset -c 是“设置 CPU 列表”，taskset -p 是“操作已有进程”——这两个选项必须组合使用才有意义，单独用 taskset -c 不带命令会报错。

常见错误写法：

• taskset -c 1,3 -p 1234 ❌：把 -p 当成 -c 的子参数，实际是两个独立选项，顺序错导致 1234 被当成命令名
• taskset -c 0,2 ./app --arg ✅：正确，-c 后紧跟 CPU 列表，再跟完整命令
• taskset -pc 0,2 1234 ✅：等价于 taskset -p -c 0,2 1234，修改已运行进程

注意：taskset -p 0x5 1234 和 taskset -pc 0,2 1234 效果一致（0x5 = 0101₂ → CPU 0 和 CPU 2），但列表写法更直观、不易数错位。

多线程程序为什么绑了主线程却没效果

默认情况下，taskset 只作用于主线程（TID == PID），子线程创建后继承的是系统默认亲和性（通常是全核开放），不会自动套用主线程的绑定。

• 启动时加 -a：如 taskset -ac 1,3 python workload.py，让所有线程一并受限
• 运行中改需显式指定所有 TID：先 ps -T -p 列出线程，再对每个 TID 执行 taskset -p -c 1,3
• 若线程由第三方库（如 OpenMP、NumPy）内部创建，-a 也不一定全覆盖，此时得在代码里用 pthread_setaffinity_np() 控制

不加 -a 的典型现象：top 里看到主线程固定在 CPU 1，但其他线程仍在满核乱跳，整体缓存局部性没改善。

绑定后进程还在不同核心间跳，是不是失败了

不一定失败。只要亲和性掩码含多个 CPU（如 -c 2,3），内核就会在其中做负载均衡——这是正常行为，不是 bug。

想真正“钉死单核”，必须确保掩码只含一位：

• taskset -c 2 ./app ✅：只允许 CPU 2
• taskset 0x4 ./app ✅：0x4 = 100₂，也是只对应 CPU 2
• taskset -c 2,3 ./app ❌：这不是“钉死”，是“限池”，内核有权在 2 和 3 之间切换

真正要隔离服务，不能只靠 taskset 临时设置：得配合 systemd 的 CPUAffinity= 持久化配置，或用 cpuset cgroup 独占物理核——否则重启、重调度、内存 NUMA 位置都不可控。

好了，本文到此结束，带大家了解了《Linux查看进程核心使用，taskset命令详解》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！