首页 > 代码库 > 关于CPU亲和性的测试
关于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_testint 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
关于CPU亲和性的测试