WSL2中taskset不起作用，因其仅影响当前进程且不传递给Node.js的worker线程或子进程，而WSL2内核采用cfs_quota软限频机制，taskset在该机制下易被忽略；真正有效的是cgroups v2硬约束结合Node.js运行时主动适配。
Windows子系统（WSL2）里 taskset 为什么不起作用
直接在 WSL2 中运行 taskset -c 0,1 node app.js，看似绑定了 CPU，但实际效果常为零——因为 WSL2 的 Linux 内核调度器不完全继承 host 的 CPU 管理策略，且 taskset 只影响当前进程，不传递给 Node.js 启动的 worker thread 或 child_process。更关键的是：WSL2 默认使用 cpu.cfs_quota_us 限频机制，而非物理核心隔离，taskset 在这种软限制下容易被内核忽略。
- 验证是否生效：
cat /proc/<pid>/status | grep Cpus_allowed_list</pid>，若返回0-3（而非你指定的0,1），说明未生效 - Node.js 的
worker_threads创建的新线程默认亲和性为全核，必须显式调用pthread_setaffinity_np()设置，仅靠taskset无法覆盖 - WSL2 的
/dev/cpu_dma_latency和cpufreq支持有限，chrt（实时调度）多数情况下静默失败，不报错但无效
真正有效的 WSL2 多核绑定方式
绕过 taskset 的局限，需结合 cgroups v2 和启动时预设策略。WSL2 2.0+ 已默认启用 cgroups v2，这是唯一能稳定约束子进程/线程的机制。
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 先创建专用 cgroup：
sudo mkdir -p /sys/fs/cgroup/node-app<br>echo "0-1" | sudo tee /sys/fs/cgroup/node-app/cpuset.cpus<br>echo $$ | sudo tee /sys/fs/cgroup/node-app/cgroup.procs
- 再在该 cgroup 下启动 Node.js：
sudo cgexec -g cpuset:node-app node app.js - 若用 PM2，需改写
ecosystem.config.js："exec_mode": "cluster",<br>"instances": 2,<br>"cgroup": { "cpuset": "0-1" }（注意：原生 PM2 不支持，需 patch 或换用pm2-cgroup插件） - 对 Jest/pytest 等测试框架，必须在外层包裹：
sudo cgexec -g cpuset:node-app npm test，否则各 worker 进程仍跑满所有核
VSCode + WSL2 调试时的 CPU 优先级陷阱
VSCode Remote-WSL 启动的调试会话（如 launch.json 中的 node 调试器）默认以普通优先级运行，且调试器自身（vscode-js-debug）会 fork 出多个子进程，这些进程不受你手动设置的 taskset 影响。
- 必须禁用
"console": "integratedTerminal"，改用"console": "externalTerminal"或"none"，否则终端模拟器会重置调度策略 - 在
preLaunchTask中调用 cgroup 命令，例如："command": "sudo cgexec -g cpuset:debug-node node",<br>"args": ["--inspect-brk=9229", "${file}"] - 关闭 VSCode 后台争抢项：
"typescript.preferences.disableAutomaticTypeAcquisition": true、"git.autoRepositoryDetection": false，否则 tsserver 和 git watch 会持续抢占 CPU 时间片 - WSL2 中
vmmem进程内存占用高时，CPU 调度延迟会放大，此时即使绑核也难改善响应卡顿，需先调低.wslconfig中的memory值并重启
Node.js 应用层如何配合 WSL2 绑核
光靠系统层绑定不够，Node.js 自身需主动适配。主线程绑核后，worker thread 和 cluster 子进程若不显式设置，仍会跨核迁移，缓存失效反而更严重。
- 启动时读取 cgroup 限制：
const cpus = fs.readFileSync('/sys/fs/cgroup/cpuset.cpus').toString().trim();<br>// 解析出可用 core 列表，传给 worker_threads - 创建 worker 时指定亲和性（Linux only）：
const worker = new Worker('./worker.js', {<br> resourceLimits: { maxYoungGenerationSizeMb: 512 }<br>});<br>// 需在 worker 内部调用 process.setCPUs([0,1])（Node.js ≥18.17） - 使用
cluster模式时，主进程用process.setCPUs([0])，子进程 fork 后立即执行process.setCPUs([1])—— 注意此 API 仅限主线程，且需--experimental-perf-hooks - 避免
child_process.fork()启动未绑核的子进程；若必须，用env: { ...process.env, NODE_OPTIONS: '--experimental-perf-hooks' }并在子进程中同步设置
taskset）几乎必然失效。真正起效的永远是 cgroups v2 的硬约束 + Node.js 运行时的主动适配，二者缺一不可。 
