常常感觉系统资源不够用，一台机子上跑了不下3个比较重要的服务，但是每天我们还要在上面进行个备份压缩等处理，网络长时间传输，这在就很影响本就不够用的系统资源；
这个时候我们就可以把一些不太重要的比如copy/备份/同步等工作限定在一颗cpu上，或者是多核的cpu的一颗核心上进行处理，虽然这不一定是最有效的方法，但可以最大程度上利用了有效资源，降低那些不太重要的进程占用cpu资源；
查看系统下cpu信息： cat /proc/cpuinfo
taskset就可以帮我们完成这项工作，而且操作非常简单；
利用 taskset 可以充分利用多核cpu的好处，可以让某个程序或脚本，运行在某个具体的cpu上。
这个工具系统可能没有默认安装：，rpm包名util-Linux
#taskset --help
taskset (util-linux 2.13-pre7)
usage: taskset [options] [mask | cpu-list] [pid | cmd [args...]]
set or get the affinity of a process
-p, –pid operate on existing given pid
-c, –cpu-list display and specify cpus in list format
-h, –help display this help
-v, –version output version information
查看pid和哪个CPU亲和：
taskset -pc pid
例子：
taskset -pc 3687
返回pid 3687‘s current affinity list:0,1,2,3
taskset -pc 0-1 3687或者taskset -pc 0,1 3687
设置线程3678和0,1两个cpu内核亲和
1）显示进程运行的CPU
命令taskset -p 21184
显示结果：
pid 21184‘s current affinity mask: ffffff
注：21184是redis-server运行的pid
显示结果的ffffff实际上是二进制24个低位均为1的bitmask，每一个1对应于1个CPU，表示该进程在24个CPU上运行
1：让某个程序运行在特定cpu上面
taskset -c 0 sh wade.sh
2：切换某个进程到特定的cpu上。
taskset -pc 0 12345
比如你有一个cpu是4 core你可以这样写你的脚本
#！/bin/bash
taskset -c 0 sh a.sh &
taskset -c 1 sh b.sh &
taskset -c 2 sh c.sh &
taskset -c 3 sh d.sh &
应该可以充分利用你的cpu了。
对运行中的进程，文档上说可以用下面的命令，把CPU#1 #2 #3分配给PID为2345的进程：
# taskset -cp 1,2,3 2345
但我尝试没奏效，于是我关掉了MySQL，并用taskset将它启动：
# taskset -c 1,2,3 /etc/init.d/mysql start
二、配置nginx绑定CPU
刚才说nginx除外，是因为nginx提供了更精确的控制。
在conf/nginx.conf中，有如下一行：
worker_processes 1;
这是用来配置nginx启动几个工作进程的，默认为1。而nginx还支持一个名为worker_cpu_affinity的配置项，也就是说，nginx可以为每个工作进程绑定CPU。我做了如下配置：
worker_processes 3;
worker_cpu_affinity 0010 0100 1000;
这里0010 0100 1000是掩码，分别代表第2、3、4颗cpu核心。
重启nginx后，3个工作进程就可以各自用各自的CPU了。
应用实例：
在一台多核 CPU 的 Web 服务器上，存在负载不均衡问题，其中 CPU0 的负载明显高于其它 CPUx，进一步调查表明 PHP-FPM 的嫌疑很大。话说以前我曾经记录过软中断导致过类似的问题，但是本例中可以排除嫌疑。
让我们在一台四核服务器上采样分析一下数据确认看看是否存在负载不均衡问题：
shell> mpstat -P ALL 1 10
CPU %usr %nice %sys %iowait %irq %soft ... %idle
all 17.57 0.03 1.78 0.00 0.35 0.23 ... 80.04
0 43.17 0.00 4.12 0.00 1.41 1.00 ... 50.30
1 9.80 0.00 0.81 0.00 0.00 0.00 ... 89.39
2 9.31 0.00 1.20 0.00 0.00 0.00 ... 89.49
3 7.94 0.10 0.80 0.00 0.00 0.00 ... 91.16
如上命令的含义是每秒运行一次 mpstat，一共采样 10 次取平均值，可以明显看出 CPU0 的空闲 idle 明显小于其它 CPUx，而且大部分都消耗在了用户态 usr 上面。
再让我们通过 pidstat 来确认一下是不是 PHP-FPM 导致的 CPU0 负载问题：
shell> pidstat | grep php-fpm | awk ‘{print $(NF-1)}‘ | sort | uniq -c
157 0
34 1
34 2
32 3
可见分配给 CPU0 的 PHP-FPM 进程比其他三个 CPUx 总和还要多。为什么大部分进程被分配给了 CPU0？我模模糊糊有一些印象是因为操作系统偏爱使用 CPU0，但我暂时也没找到实质的线索可以佐证，如果有人知道，麻烦告诉我。
问题总要解决，既然 PHP-FPM 没有类似 Nginx 那样 CPU 亲缘性（affinity）绑定的指令，那么我们可以使用 taskset 绑定 PHP-FPM 进程到固定的 CPUx 来解决问题：
#!/bin/bash
CPUs=$(grep -c processor /proc/cpuinfo)
PIDs=$(ps aux | grep "php-fpm[:] pool" | awk ‘{print $2}‘)
let i=0
for PID in $PIDs; do
CPU=$(echo "$i % $CPUs" | bc)
let i++
taskset -pc $CPU $PID
done
如上脚本运行后，让我们再来看看各个 CPU 负载分配情况如何：
shell> mpstat -P ALL 1 10
CPU %usr %nice %sys %iowait %irq %soft ... %idle
all 15.73 0.03 1.61 0.00 0.20 0.23 ... 82.20
0 16.28 0.10 1.62 0.10 0.81 0.91 ... 80.18
1 16.16 0.10 1.51 0.00 0.00 0.10 ... 82.13
2 14.46 0.10 1.71 0.00 0.00 0.00 ... 83.73
3 15.95 0.00 1.71 0.00 0.00 0.00 ... 82.35
终于平均了，不过需要提醒的是，一旦 PHP-FPM 处理的请求数超过 max_requests 的设置，那么对应的进程将自动重启，先前的 taskset 设置也将失效，所以为了一直有效，我们需要把 taskset 脚本添加到 CRON 配置中去，例如每分钟自动设置一遍！
本文把 PHP-FPM 进程平均分配给了 0，1，2，3 四个 CPU，实际操作的时候可以更灵活一些，比如前文我们提过，操作系统总是偏爱使用 CPU0，如果 CPU0 的负载已经很高了的话，那么我们不妨把 PHP-FPM 进程平均分配给 1，2，3 三个 CPU。