INTEL和AMD CPU的选择

一、前言

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规格来看,对比如下。

对比项目m5m5a
处理器Platinum 8175M CPUAMD EPYC 7571
基础频率3100.886MHz2231.147MHz
一级缓存 L1d32KB64KB
一级缓存 L1i32KB32KB
二级缓存1024KB512KB
三级缓存33792KB8192KB
BogoMIPS4999.994399.34

从AMD的官网查询结果来看,7571是一款定制处理器,并未对外零售,只在提供给AWS等合作伙伴使用。官方的型号规格见这里

这种定制处理器的情况还是很常见的,Apple家的Macbook Pro也是各种定制i5、i7处理器型号。尤其是i5高主频版本是零售市场见不到的。

同样经过查询,Intel的8175M也是一款定制处理器,在Intel官网ARK上并看不到这款处理器。

两款定制处理器之争,看下测试结果。

2、测试结果

以下是m5实例Intel CPU的测试结果。

这里除了可以看到总共跑了38770个Event之外,还可以看到每个Event的最大时间、最小时间、平均时间。这个数字区间约接近,浮动越小,说明处理器的调度能力越好。

总结,把两种处理器的数据汇总如下。

线程数IntelAMD
127793470
255556919
41111111920
82221123849
163877024461
323890524490

将上述信息转为折线图。

从以上测试数据在配合上趋势可以看出:

  • 由于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%还是一个比较客观的数字的。

全文完。

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.