Linux怎么查看进程使用的物理核心 Linux下taskset命令用法详解

Linux怎么查看进程使用的物理核心 Linux下taskset命令用法详解

给进程绑定CPU核心，是优化性能、提升缓存局部性的常见操作。但实际操作中，有几个关键细节容易被忽略，导致“绑了好像又没绑”的尴尬局面。今天就来聊聊这些实操中的“坑”和正确姿势。

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

这里有个最常见的误区：把“允许在哪些核心上运行”和“此刻正在哪个核心上运行”搞混了。直接看 psr 列最准，不是看亲和性掩码——因为掩码只表示“允许跑在哪”，而 psr（processor）显示的是“此刻实际在哪个核上执行”。

最准方法是查看psr列：ps -o pid,psr,comm -p ，psr值即当前实际运行的CPU编号（从0开始），反映瞬时调度位置，而非亲和性掩码的允许范围。

用这行命令实时观察：

ps -o pid,psr,comm -p 

输出中 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），但列表写法更直观、不易数错位。对于大多数人来说，直接指定CPU编号比换算十六进制掩码要友好得多。

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

这个问题坑过不少人。默认情况下，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 位置都不可控。这才是生产环境里实现稳定性能隔离的靠谱做法。