关于CPU亲和性的测试

今天看到运维的同事在配置nginx的CPU亲和性时候，运维同事说他在所有的机器上都是按照8核的方式来配置worker进程的CPU亲和性的。

但我觉得就是有点不太对劲，就查了一下nginx的处理worker_cpu_affinity的源代码，发现nginx并不会在发现配置错误的时候拒绝启动worker进程，而是仅仅打印一条错误日志“sched_setaffinity() failed”。

如果设置亲和性失败则按照SMP负载策略进行处理，linux的SMP负载均衡是基于进程数的，每个cpu都有一个可执行进程队列，只有当其中一个cpu的可执行队列里进程数比其他cpu队列进程数多25%时，才会将进程移动到另外空闲cpu上，也就是说cpu0上的进程数应该是比其他cpu上多，但是会在25%以内，呈现的是一种梯形分布。

如果都使用8核的方式，那么配置在4核的机器上，就会有约一半进程是按照SMP方式分配CPU的；配置在16核机器上，就会有约一半的CPU核心空闲。

我是喜欢打破砂锅问到底的，那么就顺道写了一些测试程序来研究一下Linux下的CPU亲和性在不同设置的情况下是什么状况。

测试前提：

系统是8个CPU逻辑核心(cpu0-cpu7)。

可以通过cat /proc/cpuinfo查看. 也可以使用 int num_procs = sysconf(_SC_NPROCESSORS_CONF); 获取CPU逻辑核心的数量

#define _GNU_SOURCE
#include <sched.h>
#include <unistd.h> /* sysconf */
#include <stdlib.h> /* exit */
#include <stdio.h>

//cat /proc/cpuinfo
//gcc cpu_affinity_test.c -o cpu_affinity_test
//ps -eo pid,args,psr | grep cpu_affinity_test

int main(void)
{
    cpu_set_t mask;

    CPU_ZERO(&mask);

    CPU_SET(7, &mask);

    pid_t cur_pid = getpid();

    /* Set the CPU affinity for a pid */
    if (sched_setaffinity(cur_pid, sizeof(cpu_set_t), &mask) == -1) {
        perror("sched_setaffinity");
        //exit(EXIT_FAILURE);
    }

    while(1){
        printf("hi\n");
        usleep(1000);
    }

    return 0;
}

运行之后，

ps -eo pid,args,psr | grep cpu_affinity_test 查看该进程所占用的cpu，

可以看到这个程序一定是运行在cpu7上。

如果把 CPU_SET(7, &mask);

修改为 CPU_SET(8, &mask);

再编译运行，则CPU亲和性设置会失败，系统会随机给该进程分配一个cpu，但也会固定下来。

如果修改为 CPU_SET(6, &mask); CPU_SET(7, &mask);

再编译运行，理论上会绑定两个CPU，由于这个进程再每次打印之前会休息1秒，所以基本都是在占用cpu6， 如果再修改一下程序，把休息时间修改为1毫秒，则会发现该进程会交替使用cpu6和cpu7。

如果修改为 CPU_SET(6, &mask); CPU_SET(8, &mask);

再编译运行，则cpu6被绑定成功，而cpu8是不存在的，所以该进程就只会在cpu6上运行。

备注： linux的SMP负载均衡是基于进程数的，每个cpu都有一个可执行进程队列，只有当其中一个cpu的可执行队列里进程数比其他cpu队列进程数多25%时，才会将进程移动到另外空闲cpu上，也就是说cpu0上的进程数应该是比其他cpu上多，但是会在25%以内。它也自带负载均衡策略，可以在运行时将某些进程从某一个cpu核心的进程队列移到另外一个cpu核心的进程队列。

https://my.oschina.net/xuhh/blog/755825