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 位置都不可控。这才是生产环境里实现稳定性能隔离的靠谱做法。
相关攻略
Linux系统编程：使用stat()函数精准获取文件inode编号的完整指南 在Linux系统编程中，获取文件的inode编号是一项基础且关键的操作。标准流程是调用stat()系统调用，填充struct stat数据结构，然后访问其st_ino成员。一个常见误区是字段名称：正确的字段是st_ino，
C++如何读取Linux内核生成的Device Tree二进制流【深度】 Linux用户态如何解析内核加载的dtb文件 Linux内核在启动过程中会加载并解析dtb（设备树二进制）文件，将其转换为内部数据结构（如struct device_node）。一个关键限制是：**用户态程序无法直接访问内核内
实战解析：如何用C++精准读取Linux系统的CPU负载信息 在性能监控和系统调优时，CPU使用率是一个绕不开的核心指标。很多开发者第一反应是去调用系统命令，但直接在程序中解析系统数据源，往往能获得更高效、更灵活的解决方案。今天，我们就来深入聊聊如何从 proc stat这个宝藏文件中，用C++提取
用C语言实现目录同步：一个基于readdir的实战示例 在C语言编程实践中，目录同步是文件系统操作中的一项关键任务，广泛应用于数据备份、应用部署和系统管理等场景。readdir函数作为POSIX标准库的重要组成部分，为遍历目录条目提供了高效接口。本文将深入解析如何利用readdir函数构建一个基础目
Node js日志管理最佳实践：提升应用可观测性与排障效率 如何确保您的Node js应用运行稳定、问题排查高效？核心在于构建一套专业的日志管理体系。日志不仅是程序运行的“黑匣子”，更是洞察性能瓶颈、优化代码逻辑、提升运维效率的关键基础设施。以下十项经过验证的实践策略，将帮助您将简单的日志输出转化为
热门专题
热门推荐
vendor目录离线包本质是composer install --no-dev后的完整快照 vendor 目录离线包本质是 composer install --no-dev 后的完整快照 Composer vendor目录离线包，本质上是一个经过精简、可直接部署到生产环境的依赖文件夹快照。其核心目
在CentOS系统中设置PHP定时任务 对于需要在CentOS服务器上自动化执行PHP脚本的场景，crontab无疑是那个最经典、最可靠的工具。它就像一位不知疲倦的守夜人，能帮你精准地按计划完成任务。下面，我们就来一步步拆解如何配置它。 第一步：确保PHP环境就绪 首先，需要确认您的CentOS系统
在CentOS上安装PHP依赖的完整指南 想要在CentOS系统中高效部署PHP扩展？首要步骤并非直接执行安装指令，而是配置好功能强大的“软件源仓库”。EPEL与Remi仓库是构建稳定PHP环境的基石。本教程将详细解析从仓库配置到扩展安装的全流程，助你搭建坚实的PHP运行基础。 安装EPEL仓库 E
CentOS系统下PHP远程连接配置指南：基于cURL扩展的完整教程 在CentOS服务器环境中，实现PHP与外部网络资源的远程通信是常见的开发需求。cURL扩展作为PHP内置的强大网络库，能够高效支持HTTP、HTTPS、FTP等多种协议的数据传输。本教程将详细演示如何在CentOS系统上配置并使
在CentOS上集成vsftpd与其他服务：一份实战指南 将CentOS系统中的vsftpd（Very Secure FTP Daemon）与其他关键服务进行集成，能够大幅增强其功能性、安全性与管理效率。具体的集成方案需根据您的实际业务需求来定制。本文将深入探讨几个最常见的集成场景，并提供清晰、可操