一、前言
AWS EC2计算实例同时提供了Intel和AMD的产品,在申请EC2实例时候,尾号带有小写a的就是AMD的,不带a的就是Intel的。如下截图,红色区域有标注。
那么,该怎么选择呢?
AWS官方介绍的产品系列如下截图。
在选择时候,AMD和Intel的实例价格有一定差异,因此这里做一个简单性能测试。
二、产品解析
1、测试前提
(1)本文以通用计算型m5实例为例,选比4xlarge,即16CPU/64GB内存,规格较大的,适合应用系统各种中间件的场景。
(2)本文不选择t系列突发实例,因此这里不研究t系列如何积攒CPU积分,如何平时不忙碌然后突发忙碌花掉积分这个话题。有兴趣可以看这里的文档对突发实例的原理描述。
(3)测试地点选AWS 海外新加坡,ap-southeast-1区域。测试时间2019年9月。
(4)本次测试主要考察CPU的整数运算能力,适合企业应用场景,不测试视频、图像渲染等领域需要的浮点预算能力。此外,不使用复杂的benchmark套件测试内存、网络、磁盘等。测试工具为软件包源直接安装,预先build好,不做build过程的调参数。
2、处理器内核与超线程
AWS上的EC2实例除个别低端特殊型号外,绝大部分实例的定义是:一个vCPU就是一个线程。通俗的说,一个虚拟机有8个vCPU,16GB内存,其实它对应的是4core,每个core有2个线程。点击这里的这篇文章有详细讲解。
在创建EC2时候,选定规格之后,其实是可以指定内核数和线程数的。当然指定的过程没有vCenter那么任性,VMware组合姿势繁多,什么几个socket几个core等。AWS的EC2配置选项的位置需要手工先选中“Specify CPU options”,就可以调整。如下截图。
以本次测试创建的m5.4xlarge型号为例,有16个vCPU。配置过程可能是如下情况:
- 默认,按照1个内核2线程配置,总vCPU数量16个
- 打开超线程,内核数设为8,1个处理器2个内核,总vCPU为16个
- 打开超线程,内核数设为6,1个处理器2个内核,总vCPU为12个
- 打开超线程,内核数设为4,1个处理器2个内核,总vCPU为8个
- 打开超线程,内核数设为2,1个处理器2个内核,总vCPU为4个
- 关闭超线程,内核数设为8,1个处理器1个内核,总vCPU为8个
- 关闭超线程,内核数设为6,1个处理器1个内核,总vCPU为6个
- 关闭超线程,内核数设为4,1个处理器1个内核,总vCPU为4个
- 关闭超线程,内核数设为2,1个处理器1个内核,总vCPU为2个
通过以上信息可以看出,CPU可以降低配置,不超过选择实例规格的4xlarge限制的上限16个vCPU即可。不过不管怎么配置,AWS计费都是按照4xlarge的规格计费。
本文测试直接选默认值,8个core,每个core 2个线程,总计16vCPU。
三、测试工具
1、安装
测试使用sysbench工具。sysbench工具可以压CPU内存、磁盘、网络、数据库等。代码在这里。
注意:AWS上的CentOS、Redhat Enterprise Linux、Amazon Linux 2默认的源不包含这个包,Ubuntu 18.04是包含的可以在线安装。如果使用Amazon Linux 2,可以使用额外的扩展源安装。命令如下。
amazon-linux-extras install epel
yum update -y
yum install sysbench
安装过程如下截图。
这里需要补充一下,amazon-linux-extras 是个好东西。Amazon Linux 2 本身是基于CentOS 7的发行版,yum就能装好大部分。但少数包太老了,需要高版本的又不想build,也不想在生产环境上随意去找第三方的binary包。就算拿过来第三方的Source RPM,还要自己编译一遍,也不方便。那么用Amazon Linux,这个额外的extra包含了很多工具的多个版本,部署简单多了。这也是我开始基本上只用Amazon Linux 2的理由之一。
2、使用
Sysbench压CPU的方式是算素数,又叫分解质因数。先设定一个范围,例如1~10000,程序开始逐个计算确认是不是质数,其实就是一个个强行除法分解。然后从1到10000都算完毕了,这是一个event。然后,重复继续跑第二次,每算完一次1~10000的区间就叫一个event。
性能对比是看指定时间内,谁跑的event多,谁的性能高。或者反之,限制event次数,谁先跑完,谁快。本次测试用的是限制时间,谁跑的event多,谁性能高的方法。
测试脚本如下:
sysbench cpu --cpu-max-prime=100000 --time=60 --threads=1 run
解释如下。
- 参数 –cpu-max-prime=100000 是指定素数的范围,如果不指定默认数值是10000,这里改到100000
- 参数 –time=60 是程序跑满60秒,谁算的event多,谁的性能好。如果不指定,默认是10秒,这里改到1分钟
- 参数 –threads=1 是线程数
于是在这个脚本上,分别用线程1,2,4,8,16,32跑性能看看,且分别在Intel和AMD处理器的实例上运行。
下边开始测试。
四、测试过程
1、查看CPU信息
使用ssh登陆上去,运行lscpu命令可以看到CPU的信息。
例如采用AMD处理器的m5a.4xlarge信息如下截图。注:图中的参数BogoMIPS也是一个处理器性能标称值。
采用Intel处理器的m5.4xlarge实例的CPU信息如下截图。
2、各线程下测试
sysbench cpu --cpu-max-prime=100000 --time=60 --threads=1 run > /var/www/html/threads-1.txt
sysbench cpu --cpu-max-prime=100000 --time=60 --threads=2 run > /var/www/html/threads-2.txt
sysbench cpu --cpu-max-prime=100000 --time=60 --threads=4 run > /var/www/html/threads-4.txt
sysbench cpu --cpu-max-prime=100000 --time=60 --threads=8 run > /var/www/html/threads-8.txt
sysbench cpu --cpu-max-prime=100000 --time=60 --threads=16 run > /var/www/html/threads-16.txt
sysbench cpu --cpu-max-prime=100000 --time=60 --threads=32 run > /var/www/html/threads-32.txt
测试结果收集起来写入到/var/www/html/下,可以直接挂在web server上,不需要ssh登录也能看到结果。
五、小结
1、规格对比
仅从CPU规格来看,对比如下。
对比项目
m5
m5a
处理器
Platinum 8175M CPU
AMD EPYC 7571
基础频率
3100.886MHz
2231.147MHz
一级缓存 L1d
32KB
64KB
一级缓存 L1i
32KB
32KB
二级缓存
1024KB
512KB
三级缓存
33792KB
8192KB
BogoMIPS
4999.99
4399.34
从AMD的官网查询结果来看,7571是一款定制处理器,并未对外零售,只在提供给AWS等合作伙伴使用。官方的型号规格见这里。
这种定制处理器的情况还是很常见的,Apple家的Macbook Pro也是各种定制i5、i7处理器型号。尤其是i5高主频版本是零售市场见不到的。
同样经过查询,Intel的8175M也是一款定制处理器,在Intel官网ARK上并看不到这款处理器。
两款定制处理器之争,看下测试结果。
2、测试结果
以下是m5实例Intel CPU的测试结果。
这里除了可以看到总共跑了38770个Event之外,还可以看到每个Event的最大时间、最小时间、平均时间。这个数字区间约接近,浮动越小,说明处理器的调度能力越好。
总结,把两种处理器的数据汇总如下。
线程数
Intel
AMD
1
2779
3470
2
5555
6919
4
11111
11920
8
22211
23849
16
38770
24461
32
38905
24490
将上述信息转为折线图。
从以上测试数据在配合上趋势可以看出:
- 由于EC2实例默认都是开启超线程,每个内核2个线程的,因此本次测试的16vCPU实际是8内核2线程。
- 在单线程和线程数较少的情况下,AMD处理器有一定的优势。
- 当测试线程数跑到8线程时候,还是可以跑满AMD处理器的能力,AMD依然小幅领先。
- 当来到16线程时候,处理器已经没有物理Core了,是虚拟机出来的超线程,此时Intel发挥了碾压的优势,将AMD摔在身后。
- 继续施压到32线程,可以发现处理能力几乎不在上升了。这是因为处理器算上超线程就16个线程的能力,强行施压基本上就是排队,而不会有计算效能显著提升。
另外一个角度来看,存在一定可能是本次测试使用的sysbench在多线程优化上完全是按照intel来做的,并没有给AMD做任何调优。看起来可能有些不够公平。但是换一个角度,可能很多通用软件也并未给AMD做任何调优,都是从源上直接downlad binary包下来跑。这个时候,AMD处理器在多线程跑的比较高负载时候的性能劣势就体现出来了。
本次测试也不能代表全部,并且还有浮点运算场景,以及完整的benchmark还应该结合内存吞吐、磁盘IO、网络吞吐(数据中心内网)等因素,并施以一定的权重比例区评测。因此本测试只是单纯的一个方面来考察下两款处理器之间的能力。从AWS将AMD本身定价比Intel便宜10%这个来看,AMD的在不敏感不是满负载的普通企业应用场景下,还是有成本优势的,可以选择。而且使用云的一个特点就是灵活,真的负载上来了遇到性能不好,或者水平扩展,或者直接migrate到Intel处理器规格,都可以灵活的迁移。当看中成本优化时,而且资源量较多时候,10%还是一个比较客观的数字的。
全文完。
最后修改于 2019-09-30