前几天帮朋友排查一台测试机的性能波动发现一个挺典型的现象同样的压测脚本每次跑出来的延迟曲线差别都很大甚至能看到某几个CPU核心负载特别高其余核心闲着。排查到最后问题出在进程没有固定CPU亲和性上——多线程程序在核间来回迁移L1/L2缓存反复失效性能自然飘忽不定。最后用Linux自带的taskset命令把进程固定到指定CPU上问题立刻清晰了很多。这篇不准备讲太高深的理论就是把taskset从原理到实战讲透怎么看亲和性、怎么设置亲和性以及为什么有时候你绑了核但性能依旧不稳定。1. 先搞明白CPU亲和性是什么以及为什么值得折腾它1.1 调度器的默认行为公平优先缓存靠边Linux默认的CFS调度器完全公平调度器的核心理念是把负载均匀分散到所有CPU上同时尽量让同一个进程继续在之前运行过的CPU上运行这就是所谓的软亲和性。软亲和性只是调度器的一个倾向不是铁律。当内核发现当前CPU负载偏高、其他核比较空闲时会毫不犹豫地把这个进程迁移过去。对大多数应用来说一次迁移的开销微乎其微。但对那些高频访问共享状态、对缓存依赖极高的应用来说一次迁移意味着CPU内部的L1/L2缓存几乎全部失效。进程下次访问数据时得重新从L3缓存甚至内存里加载多线程程序还要重新把热数据搬进cache。如果进程每毫秒都在访问同一份热数据迁移一次可能就损失几十微秒的性能。折合成压测数据就是延迟曲线出现毛刺、P99持续走高。举个生活化的例子你工位上的资料是按自己的习惯排好的找起来得心应手。如果领导每隔几分钟就让你换一次工位你得重新适应新环境、重新定位资料位置日常办公还能忍但关键项目冲刺的时候这种来回折腾非常耽误事。操作系统里的缓存迁移就是这样一种换工位。1.2 硬亲和性把规则从建议变成命令和软亲和性相对的是硬亲和性。硬亲和性直接告诉内核这个进程只能在指定的CPU集合里运行集合之外的核心一个都不能碰。taskset命令做的事情本质上就是设置这个硬性约束——通过修改进程的CPU亲和性掩码CPU affinity mask把进程可以使用的CPU集合钉死。需要特别注意的是硬亲和性不等于CPU独占。taskset只是把进程的活动范围限制在某几个核心上它不阻止其他进程也跑到这些核心上来抢资源。真正的独占需要配合内核隔离参数isolcpus或者cgroup的cpuset机制这一步放在后面实战章节细说。1.3 哪些场景值得折腾哪些场景别乱绑我在实际工作中总结出来的判断标准很简单先测量再优化。不要一上来就taskset你至少得先确认性能波动确实和调度迁移有关否则就是在瞎折腾。值得做亲和性绑定的场景大致有这几类数据库和缓存中间件Redis、MySQL这类对延迟敏感、热数据集中在内存里的服务绑核之后延迟曲线会明显更稳。尤其是Redis 6.0之后引入多线程IO处理绑核的价值更明显。实时性要求高的采集程序比如证券行情采集、工业控制、音视频编码推流这类任务对最大延迟而非平均吞吐极其敏感。性能基准测试跑benchmark的时候如果不统一绑核结果可能忽高忽低。绑定之后至少能排除调度器带来的随机噪声复现性会好很多。NUMA架构下的大内存应用跨NUMA节点访问内存的代价远高于核间迁移这类应用往往需要同时考虑CPU绑定和内存绑定。不适合绑核的情况也很明确通用Web服务、任务负载高度动态的批处理程序本来就需要调度器在多个核之间做负载均衡绑死核心反而可能导致某些核打不满、另一些核排队整体吞吐反而下降。另外在虚拟机里绑物理核意义也不大——宿主机层面的调度和虚拟机内部的调度是两层非宿主机管理员可以控制的。2. taskset命令详解查看、设置、掩码格式一次吃透2.1 命令结构与常用参数taskset来自util-linux包几乎所有Linux发行版都自带不需要额外安装。它的基本调用方式有两种# 启动新命令时绑定 taskset [options] mask command [arguments] # 对已运行的进程设置或查看 taskset [options] -p [mask] pid常用参数就三个用熟完全够了参数作用说明-p操作已存在的PID不加-p时taskset会启动一个新命令并给它设置亲和性-c用CPU列表格式显示/设置比十六进制掩码直观得多强烈建议默认加-a操作进程组内所有线程新版util-linux支持旧版本可能没有这个选项一个很实用的自测命令是taskset -pc $$$$是当前shell的PID运行一下就能看到你的终端进程当前允许跑在哪些CPU上。$ taskset -pc $$ pid 12345s current affinity list: 0-7输出里的0-7表示这个shell可以在CPU 0到7号之间任意调度。默认情况下系统对普通进程没有任何限制所以看到的是所有可用的逻辑CPU。2.2 设置亲和性的两种典型用法场景A启动新进程时直接绑定# 只允许进程在CPU 0、2、4上运行 taskset -c 0,2,4 ./myapp # 允许CPU 1到4之间的连续范围 taskset -c 1-4 ./myapp这种方式最适合测试场景比如你写了个性能测试脚本希望它只在指定的几个核上跑直接在命令行前面套一个taskset -c即可。命令执行后所有子进程都会继承这个亲和性非常省事。场景B进程已经跑起来了运行时调整# 把PID为1800的进程绑定到CPU 0、1 taskset -pc 0,1 1800运行期间调整的好处是不用重启服务对生产环境友好。如果服务本身没有在启动脚本里配置亲和性你可以临时绑一下观察效果确认收益后再做成持久化配置。要注意的是如果进程已经在运行使用-p且不指定mask只会查看而不会修改。指定了mask才会修改而且修改是立即生效的。2.3 掩码格式一个很多人理解错的地方不带-c参数时taskset使用的是十六机制/十进制的位掩码。位掩码的每一个bit代表一个CPU编号bit为1就表示允许在该CPU上运行。举个例子taskset -p 3 1800中的3二进制是11低位0和1都是1所以实际上是把进程绑定到了CPU 0和CPU 1上。如果某天你想绑定的是CPU 3这一颗核正确写法是taskset -p 8十六进制0x8或者更直观地写taskset -pc 3。这个理解偏差非常容易踩尤其是刚接触的人看到-p 3会直觉认为绑的是CPU 3结果进程跑在CPU 0和1上完全不是本意。我的建议是新手和日常操作永远用-c把掩码换算留给那些确实需要写脚本批量设置的场景。还要注意一点掩码的位数是有限的。如果服务器逻辑CPU超过64个裸掩码可能显示不完整用-c则可以扩展到更大范围。这也印证了-c格式在日常运维中的实用性。2.4 查看进程真实运行位置taskset得不到的信息taskset的-pc PID输出的是允许范围不是当前实际跑在哪个核上。想知道进程此刻到底在哪个CPU上干活可以用ps或pidstat# 查看进程当前运行的CPU编号psr列 ps -o pid,psr,comm -p 1800 # 每1秒采样一次观察CPU使用率和实际核 pidstat -p 1800 1也可以用top进入后按f开启P列Last Used CPU或者直接用htop每个进程后面都会显示当前核心编号。顺便提一句/proc文件系统也可以直接读出信息# 查看进程的CPU允许集合 cat /proc/1800/status | grep -i cpus_allowed输出会包含两行Cpus_allowed显示十六进制掩码Cpus_allowed_list显示十进制列表。这两个字段和taskset查看的结果是同一个数据的两种表示方式。3. 深入taskset背后系统调用、亲和性继承规则与NUMA纠缠3.1 taskset只是sched_setaffinity的漂亮外壳用strace跟踪一下taskset你会发现它最终调用了/proc之外的一个核心系统调用sched_setaffinity。Linux内核为每个线程维护着一个cpumasksched_setaffinity就是用来改写这个掩码的接口。taskset本质上是对这个系统调用的命令行封装把用户输入的CPU列表转换成位图再传给内核。如果你写C程序想在代码里直接实现同样的功能大致是这样的一个流程#define _GNU_SOURCE #include sched.h #include stdio.h #include unistd.h int main(int argc, char **argv) { cpu_set_t set; CPU_ZERO(set); CPU_SET(0, set); CPU_SET(2, set); if (sched_setaffinity(getpid(), sizeof(set), set) -1) { perror(sched_setaffinity); return 1; } printf(affinity set, pid: %d\n, getpid()); return 0; }编译运行之后再通过taskset -pc $$或者/proc/self/status查看就能看到掩码已经变成了0,2。这个底层视角对理解很多事情有帮助。比如为什么taskset修改的是允许集合而不是当前实际位置——因为内核调度器在每次唤醒、迁移、负载均衡时都会拿着这个掩码去过滤可选CPU它只管限制范围不管具体落点。3.2 亲和性继承规则哪些会留哪些会丢亲和性掩码是进程线程在内核里叫task的属性它有明确的继承规则fork子进程子进程会完整继承父进程的亲和性掩码。所以你在命令行用taskset启动一个服务服务再fork出的工作子进程都会保持同样的绑定。exec执行新程序亲和性不会被重置。也就是说无论这个进程再怎么执行别的二进制文件只要它没自杀重启亲和性就一直留住。系统重启所有亲和性设置全部丢失。taskset做的不是持久化配置它只是在内存里改了task的属性重启后一切回到默认状态。进程自己调用sched_setaffinity进程可以用代码主动修改自己的亲和性优先级高于外部设置。这个规则带来一个实际影响生产环境里如果你只靠手动taskset绑定某个服务一旦被守护进程自动拉起、或者机器重启后自动启动绑核就失效了。这也是后面要讲systemd持久化方案的原因。另外要特别留意线程级别的差异一个多线程进程里每个线程都有自己独立的亲和性掩码。taskset -p PID操作的是进程的主线程工作线程并不会自动跟着变除非新版util-linux里使用-a参数或者逐个线程设置。这一点在踩坑章节里详细展开。3.3 NUMA架构下taskset管不了内存这摊子事现代服务器大多是NUMA架构CPU被分成若干个节点每个节点有自己的内存控制器。CPU访问自己节点上的内存快访问其他节点的内存慢延迟差甚至可以有1.5到2倍。taskset只能决定进程在哪个CPU上跑它管不了进程访问的内存放在哪个节点。这就出现一个很有迷惑性的场景你通过taskset把一个进程从CPU节点0迁移到了CPU节点1进程本身确实在节点1上跑了但它之前分配的内存依然留在节点0的物理内存里。于是每个内存访问都变成跨节点访问性能可能比不迁移还差。很多人绑核后发现性能没提升甚至下降原因往往就在这里。解决跨节点问题需要引入numactl命令# 查看NUMA节点拓扑 numactl --hardware # 绑定CPU节点0同时绑定内存节点0 numactl --cpunodebind0 --membind0 -- ./myapp简单理解taskset告诉你在哪个工位干活numactl告诉你资料放在哪个柜子。理想情况下两者应该就近。如果你的场景已经涉及NUMA建议直接用numactl做主管理taskset适合做临时细粒度的CPU绑定。一个比较隐蔽的细节是用taskset对一个已在运行的进程改绑到其他NUMA节点时已经分配的内存不会自动迁移。如果想迁移需要用move_pages这类更底层的机制普通运维场景很难直接用。所以实际操作时我宁愿先停服务、设置亲和性、再启动服务确保进程一开始就在正确的节点上分配内存。4. 实战组合拳从临时绑核到生产级持久化4.1 案例1压测临时调整把服务固定到一致性组核心假设线上压测时你发现MySQL服务的延迟波动很大怀疑是调度迁移引起的想临时试一下绑核。第一步找到进程的PIDpgrep -f mysqld假设结果是1800用ps -o pid,psr,comm -p 1800看下它当前运行在哪颗核上。第二步绑定到连续的核心区间比如CPU 1到7号taskset -pc 1-7 1800为什么要避开CPU 0因为CPU 0经常承担内核的部分关键线程、迁移线程和未处理的软中断负载本身就偏高把业务进程绑到那里容易互相干扰。实际生产服务器上我一般会留出至少一个核给系统使用。第三步观察效果# 拉取进程每秒的系统态/用户态CPU pidstat -p 1800 1绑核前后各压测一轮对比延迟P50、P99和吞吐值。正确的绑核效果通常不是吞吐暴涨而是延迟更稳定、毛刺明显减少。如果机器本身核多、负载低可能看不出差别这属于正常现象不代表绑核没用只代表当前瓶颈不在调度上。4.2 案例2基准测试前先搞懂CPU拓扑再决定绑哪些核跑基准测试时最怕的不是不绑核而是绑错了核——把两个互相干扰的逻辑CPU当成两个独立核心来用。超线程技术下同一个物理核有两个逻辑CPU它们共享执行单元和L1/L2缓存。如果你把两个重负载任务分给同一个物理核的两个逻辑CPU它们会互相争抢资源性能可能比两个任务跑在两个物理核上低30%甚至更多。用lscpu -e能把CPU拓扑看得明明白白$ lscpu -e CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ MINMHZ 0 0 0 0 ... yes 1 0 0 0 ... 2 0 0 1 ... 3 0 0 1 ...注意看CORE这一列CPU 0和CPU 1的CORE都是0说明它们属于同一个物理核的两个逻辑CPUCPU 2和CPU 3的CORE是1属于另一个物理核。压测时如果只想用两个真实物理核应该选taskset -c 0,2或者taskset -c 1,3而不是图省事选0,1。我踩过一次很深的坑在一台20核机器上做网络收发的性能测试把收发进程分别绑到了CPU 0和CPU 1上结果吞吐只有预期的一半。后来用lscpu -e一看这两个逻辑CPU共享同一个物理核的执行单元两个进程根本没在并行干活等于一个物理核心被拆成两半互相抢资源。把绑定改成CPU 0和CPU 2之后吞吐立刻恢复正常。所以基准测试前的标准动作是lscpu -e看清楚拓扑再决定选哪些逻辑CPU。选的原则是让每个任务落在不同的物理核上避免多个重负载任务共享同一个物理核。4.3 案例3生产服务持久化绑核systemd和cgroup才是正解手动taskset有一个明显短板重启即失效。生产环境需要一个能开机自动生效的机制systemd的CPUAffinity是最常用的方案。假设你有个服务叫myapp.service在它的Unit文件[Service]段里加一行[Service] CPUAffinity0,2,4-7保存后执行systemctl daemon-reload重启服务亲和性就会在进程启动时自动设置。这里的CPUAffinity语法和taskset的-c参数一致支持列表和范围混合写法。如果你的机器上所有服务都想默认绑在一个核组里也可以在/etc/systemd/system.conf里设置全局默认值DefaultCPUAffinity0-7容器场景下Docker也原生支持绑核docker run --cpuset-cpus0-3 --name myapp myimage对于直接在cgroup上管理亲和性的场景cpuset是更底层也更灵活的方式# 创建cpuset组并允许CPU 0-3 mkdir /sys/fs/cgroup/cpuset/myapp echo 0-3 /sys/fs/cgroup/cpuset/myapp/cpuset.cpus # 把进程加入该组 echo 1800 /sys/fs/cgroup/cpuset/myapp/tasks或者用systemd-run直接创建瞬态服务并设置CPU亲和性systemd-run --propertyCPUAffinity0-3 --unitmyapp ./myapp从机制上看cgroup的cpuset和taskset的关系有点像大楼门禁和房间门锁cgroup限定进程只能在某个范围内活动taskset再在范围内细化到具体某个或某几个CPU。两者的约束是取交集的不是取并集。如果taskset指定的CPU不在cgroup允许范围内系统调用会直接返回EINVAL设置失败。我的习惯是临时调试用taskset生产配置用systemd或cgroup。taskset定位问题的速度很快但把它直接写进生产环境维护流程容易被重启击穿。4.4 进阶配合isolcpus参数给关键任务腾出干净核如果你有一个对延迟要求极其苛刻的任务希望它独占几个核心光靠taskset是不够的。原因前面说过taskset只管这个进程能去哪不管其他进程能不能也来这些核。要想制造真正的干净核需要从内核启动参数里孤立一部分CPU。在GRUB的内核命令行中加入isolcpus2-7重启之后CPU 2到7会从全局调度器的候选列表里被剔除。普通进程默认不会被调度到这些核上只有显式把亲和性设置为这些核的进程比如用taskset指定才能使用它们。实际操作时需要额外注意一点isolcpus只隔离了进程调度内核线程、网络中断、kworker这些照样可能落在孤立核上。如果连这些都想赶走还得配合中断亲和性设置把网络队列的IRQ绑定到非隔离核。这是一个比预想更深的坑真正的实时场景需要完整规划GRUB加isolcpus2-7隔离CPU。systemd服务设置CPUAffinity2-7让业务进程只用隔离核。网卡多队列的IRQ绑定到CPU 0-1避免中断干扰关键核。通过cpupower把隔离核频率设为performance模式避免频率波动。这样搭出来的环境才叫真正的关键任务专核专用。taskset在其中扮演的角色是最后一步显式指定路径的扳道工。5. 越用越容易踩的坑taskset实战避坑清单5.1 mask格式的1和CPU 1根本不是一回事这个坑我前面提过但值得再强调一遍因为它实在太常见了。taskset -p 3 PID绑定的是CPU 0和CPU 1因为3的二进制是11两个bit都是1。如果你想绑的是CPU 3这一颗核正确写法是# mask方式 taskset -p 0x8 PID # 更推荐的方式 taskset -pc 3 PID看输出的时候也要留意taskset -p 1234显示的affinity mask: f这个f是十六进制代表CPU 0-3而不是CPU f。看到mask输出第一反应是转成二进制或列表不要直接念成第f个CPU。5.2 多线程进程只绑了壳工作线程还在乱跑taskset -p PID设置的是进程主线程的亲和性不代表所有线程跟着改。Java应用、MySQL线程池、Redis 6.0及之后的IO线程都有自己独立的线程ID内核视角下每个线程都是独立task需要单独设置。我在某次压测现场排查过一个问题明明taskset了MySQL进程ps -T列出来的线程却分散在8个不同的核上。原因就是taskset只改了主线程InnoDB的线程池线程完全没受影响。新版本util-linux的taskset提供了-a参数可以一次设置整个进程组内所有线程taskset -pc 0-3 -a 1800如果版本较老不支持-a就只能遍历线程ID逐个操作for t in /proc/1800/task/*; do taskset -pc 0-3 ${t##*/} done绑定多线程服务之前先确认服务线程模型再决定用哪种方式。这一步做漏了后面的压测数据都是脏的。5.3 逻辑CPU编号和物理核的对应关系很反直觉现代服务器BIOS和系统的CPU编号规则经常和物理布局不是线性对应的。有可能CPU 0和CPU 8才是同一个物理核的两个逻辑CPU而CPU 0和CPU 1反而是两个不同的物理核。不要想当然地把编号相邻当成物理相邻。操作前一定用lscpu -e或者读拓扑文件确认cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list如果输出0,8就说明CPU 0和CPU 8共享同一个物理核。绑核时尽量把任务分散到不同的thread_siblings组充分利用真正的物理执行单元。5.4 权限与cgroup边界为什么提示Operation not permitted非root用户修改其他用户的进程Linux会直接拒绝返回EPERM。容器内运行taskset时更要注意容器默认被cgroup的cpuset约束在某个CPU子集内如果你试图把进程绑到宿主机上但不在容器允许范围内的CPU也会失败而且错误信息和权限问题一样都是Operation not permitted。遇到这种情况先确认目标进程归属的cgroup允许集合# 查看进程所属cgroup cat /proc/1800/cpuset # 查看该cgroup允许的CPU范围 cat /sys/fs/cgroup$(cat /proc/1800/cpuset)/cpuset.cpus只能在这个允许范围内选择绑定目标。如果你确定想让进程使用更大范围的CPU得先调整cgroup配置再执行taskset。5.5 绑核不等于独占别忘了中断和频率这两个隐形干扰最后聊一个很多人搞混的点taskset绑定之后进程确实不会跑出你指定的范围但这个范围内的CPU不等于只有它一个进程在用。系统负载高的时候其他进程照样会被调度进来争抢资源。taskset做的是限定范围不是申请独占。想真正独占一个核需要叠加三层配置isolcpus内核隔离把指定核从全局调度器中剔除普通进程默认进不来。IRQ亲和性设置把网卡中断、RPS等绑定到非隔离核防止硬中断频繁唤醒隔离核上的进程。CPU频率锁定绑核解决不了频率波动如果CPU governor是powersave或者打开了动态睿频即使独占核频率也可能忽高忽低影响延迟。对实时任务来说用cpupower frequency-set -g performance锁频很有必要。我搭实时数据采集环境时这三步缺一不可否则延迟毛刺从根上就消不掉。6. 个人实践体会taskset的正确打开方式用了这么多年taskset我的整体感受是它是一个极其锋利的小工具解决进程到底跑在哪个核上这类问题几乎零成本但它只负责指定范围这一步。完整的性能调优链路至少还包括numactl管内存、cgroup管约束、isolcpus管隔离、cpupower管频率每一步都有各自的边界。几个日常习惯值得分享凡是用到多核压测先把lscpu -e的输出存一份。后续想要确认拓扑、排查绑核是否合理这份输出就是最直接的依据。写测试脚本时把taskset直接写在命令最前面让它成为整个命令的前缀这样所有子进程自动继承亲和性省得每个子进程单独设置。临时绑核一定用-cmask格式留给那些确实需要程序化批量操作的人。我在同一台机器上管理几十个进程时才会手动算mask。最后再说一个小技巧如果你不确定某个服务绑核前后到底有没有变化不要只盯着平均延迟要看P99甚至P999。调度迁移对平均值的影响有时并不大但会显著拖长尾部延迟。把P99画成曲线绑核效果的差异会非常直观。