VCPU负载压测

由于云主机项目提供的是整套虚拟化服务,上层服务并没有直接用到物理节点上的CPU,而是通过创建云主机的时候,指定规格来申请vcpu资源来使用,虚拟化出vcpu,需要得到硬件的支持,通常来说就是Intel VT和AMD-V,在此基础上一个云主机实际上是通过一个QEMU用户进程而在节点机上运行的,而vcpu实际上就是以QEMU进程的线程而存在

来看云主机vcpu和节点cpu之间的关系

~$ sudo virsh vcpuinfo instance-000ac3af
VCPU:           0
CPU:            26
State:          running
CPU time:       8600.1s
CPU Affinity:   ----yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy

VCPU:           1
CPU:            13
State:          running
CPU time:       8064.1s
CPU Affinity:   ----yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy

通过virsh可以查看云主机vcpu对应节点机物理cpu的core id,比如这里可以看出来instance-000ac3af这台云主机申请了两个vcpu,vcpu0此刻运行在了物理cpu 26上,vcpu此刻运行在了物理cpu 13上,说此刻是因为它不停在变,在各个物理cpu上辗转,随系统调度,从CPU Affinity的结果也可以看出来,vcpu除了0-3这四个物理cpu,其它cpu都能够调度上去,这四个物理cpu其实是为节点上所有服务(OpenStack)所预留

直接宿主机上通过top也可以看到两个vcpu所在的线程以及调度的物理CPU

top - 15:33:54 up 66 days,  4:38,  2 users,  load average: 11.61, 10.38, 10.11
Threads: 538 total,   0 running, 538 sleeping,   0 stopped,   0 zombie
%Cpu(s): 20.7 us,  1.1 sy,  0.0 ni, 78.1 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem:    387143 total,   227153 used,   159990 free,      660 buffers
MiB Swap:        0 total,        0 used,        0 free,   109773 cached

PID USER         PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND           P
129806 root      20   0 10.4g 2.1g  14m S   4.3  0.5 144:26.00 CPU 0/KVM        42
129809 root      20   0 10.4g 2.1g  14m S   2.7  0.5 135:26.78 CPU 1/KVM        36

从上面的小例子可以理解,云主机的vcpu和宿主机的物理cpu并没有直接的对应关系,但如果所有云主机里cpu负载都很高,对整个宿主机来说总负载也会很高,这时候系统服务以及云主机中的业务都需要进行异常测试;同理,如果宿主机本身负载就比较高,那么云主机中的cpu就会相对繁忙

云主机vcpu和宿主机cpu之间没有严格的关系,但假如一个物理cpu只虚拟化出一个vcpu,那么宿主机(48CPU,预留4个)最多能虚拟化出44个vcpu,最终整个节点只能创建出vcpu为1这种规格的云主机44台,本身cpu的处理能力比较过剩,假如每个云主机负载还十分空闲,那么就会造成十分严重的资源浪费,或者说利用率太低,因此就有了cpu超售比例这个概念,作用是为了资源利用率的最大化

从上图可以很清楚地看出,超售比能够在基础可虚拟化的cpu数量的基础上提升vcpu的倍数,这样就能够创建更多的资源,但需要注意几点:

1)        宿主机物理cpu是固定的,所虚拟化出的vcpu越少,平均每个vcpu的处理能力越强,反之越弱,就好比如果超售比例为1,那么vcpu和物理cpu数量1:1,可以理解为每个vcpu的处理能力和每个物理cpu相当;如果超售比例设为2,那么vcpu和物理cpu数量2:1,此时vcpu的处理能力就只有物理cpu的一半,一个不恰当的比喻,超售比为1的时候,每个vcpu相当于I7的能力,超售比为2的时候,每个vcpu相当于I5的处理能力(假如I7处理能力为I5的两倍)

2)        宿主机上vcpu资源如果用尽,根据超售比每个vcpu的处理能力很好理解,平均即可,但假如未完全用尽,算法就有些不同了,比如cpu超售比例为2,一共可以虚拟化出88个vcpu,如果创建了88台vcpu为1规格的云主机,那么每个vcpu的处理能力就是44 * 物理CPU / 88 = 半个物理CPU的处理能力,但假如宿主机上创建了66台vcpu为1规格的云主机,每个vcpu的处理能力并不是半个物理CPU的处理能力,而是44 * 物理CPU / 66 = 2/3个物理CPU的处理能力,假如继续新建一个vcpu为1的云主机,每个vcpu的处理能力就是44 * 物理CPU / 67 个物理CPU的处理能力,也就是说每个vcpu的处理能力都不固定,而是随着vcpu数量的变化,每个vcpu的能力来做平衡,从线程的角度理解就是,多了一个耗费cpu负载的线程,平均每个线程的处理能力就会降低

3)        正常情况下,CPU的处理能力都是过剩的,假如超售比例为1,节点上44个拥有最大处理能力的vcpu全部都是空负载,如果每个内存512M一共就用了20G左右内存,而这些空负载的vcpu却使得节点上无法继续创建了,造成严重的资源浪费,此时如果超售比设为4,那44个空负载的云主机可以随便打发1/4的cpu处理能力,剩下3/4的cpu资源还可以充分利用起来

4)        从收益的角度,由于这些计算资源都要收费,在合理资源利用最大化的基础上,数量越多,费用收入也会更大

 

由于cpu的使用涉及到宿主机和云主机,以及超售状况,因此在测试过程中,要结合宿主机的cpu负载和云主机的cpu负载进行异常测试,要关注的是宿主机的load和软中断数量以及满cpu负载和空cpu负载的云主机的运行状态以及服务情况

 

cpu负载工具,这里主要介绍burnintest和stress

burnintest不开源,Linux环境下只提供32bit/64bit的可执行程序,版本也相对较老,但是可用

下载地址:wget http://www.passmark.com/ftp/burnintest_2.1.tar.gz

运行方式:./bit_cmd_line_x64(根据操作系统环境选择32位或者64位)

参数:

默认是15分钟一个cycle

指定参数-D 1:

Run for 1.0 minutes or 0 cycles (0 is forever)

指定参数-X 1:

Run for 15.0 minutes or 1 cycles (0 is forever)

最终压测结果可以直接通过top或者htop来查看

 

stress,压力测试工具

安装:sudo apt-get/yum install stress

运行方式:/usr/bin/stress –c N

其中,N代表产生N个进程来反复不停地计算随机数的平方根,会加满N个CPU负载

发表回复