正在阅读：再次吹响号角，扬帆更壮阔的征途——AMD EPYC 7F72/7F52处理器测试再次吹响号角，扬帆更壮阔的征途——AMD EPYC 7F72/7F52处理器测试

　　AMD EPYC 7F72处理器双路系统评测

　　测试说明：

　　本次测试通过远程接入AMD测试机房的形式来进行。

　　系统配置：

　　AMD双路服务器使用了两颗AMD EPYC 7F72 24核处理器，支持超线程。如此，在系统中我们可以看到这台服务器有96个逻辑CPU。在测试中，Numa Nodes设置为2。

　　CPU信息：

　　具体到NUMA节点的设置，我们使用numactl进行了读取：

　　可以看到两个NUMA node均分了逻辑CPU和512GB的内存。AMD双路服务器以性能见长，在此我们通过实验对这台服务器的性能进行了全面的评估。测试环境及工具如下：

　　01、HPL Linpack 2.3测试

　　Linpack是目前流行的理论性能测试工具，用于测试系统的浮点运算性能。在这一项目中我们使用更能突出系统并行计算能力的HPL Linpack 2.3来进行测试。

　　测试中，关键参数的设置为P=4,Q=3,N= 239008, NB= 224。测试执行了4056秒，最终结果为PASSED，这款AMD EPYC 7F72双路服务器获得了2171.3 Gflops的成绩。

　　02、Sysbench 1.0.20

　　SysBench是一个模块化的、跨平台、多线程基准测试工具，主要用于评估测试各种不同系统参数下的数据库负载情况；其中包括CPU、磁盘IO、调度程序性能、内存、POSIX线程性能、数据库性能（OLTP）等数个基准测试模块。在这里我们主要选取CPU、内存以及OLTP的测试结果。编译器方面，我们使用的是LuaJIT 2.1.0 beta2。

　　CPU：

　　Sysbench CPU测试使用1，4，16，32，48，64，80，96及128线程分别对服务器压测300s，并记录双路AMD EPYC 7F72的速度及延时数据。结果如下图所示：

　　随着压力逐步上升，测试成绩也被划为三个阶段，第一个阶段压力明显偏小，CPU每秒钟执行的events数随着压力升高而升高，并且延时一直保持在2ms以内。当Threads超过48是，CPU测试成绩趋近于35000，而延时小幅增长，但是仍然低于3ms。第三个阶段，当压力超过系统的逻辑CPU数时，延时明显升高。Thread=96时，CPU Speed为34885.8 events/s，同时延时（95%）为2.76ms。

　　内存：

　　Sysbench内存测试中我们使用了1，4，16，32，48，64，80，96，128几种Threads几种不同的压力做4k写测试，每种压力测试10s。与CPU测试不同的是，这里我们展示的是内存写带宽和最大延时。

　　当Thread为1时，此时负载完全是4k顺序写，内存带宽成绩达到本次测试最大值13825.82 MiB/s，此时最大延时为0.07ms。

　　OLTP：

　　Sysbench的OLTP测试则是模拟一个数据库的压测环境，对服务器性能进行全面评估。这项测试中我们将Sysbench的Table size分别设置为200000，500000，1000000，1500000，2000000；并使用32，48，64，80，96，128等几种不同的Threads参数进行组合测试。结果如下图：

　　本次测试固定为100个Table，将单个Table的数据量作为测试数据量规模的主要变量，而并发线程数作为并发压力的主要变量。从测试结果来看，在不同Table大小的情况下，线程数增加可以带来性能成线性增加，并且始终保持着5ms以内的低延时，并在最大并发压力128线程时取得最好的成绩，可以看出不同Table大小设置对于性能表现的影响并不大。显然，这与测试环境本身配置的512GB大内存有直接关系，如果MySQL的缓存被占满，数据需要不断下刷到SSD，届时延时将会明显升高。

　　峰值性能出现在Table大小为20W，线程数为128时，此时峰值性能为47873.84 TPS，95% 延时为4.25ms。

　　03、TPCC基准测试

　　此项测试中我们使用的数据库是Oracle官方的MySQL 8.0，并使用Perconas的TPCC-MySQL工具进行测试。

　　TPCC是TPC（Transaction Processing Performance Council）设计的一个OLTP基准测试规范，TPCC模拟的是一个大型商品批发商的在线订单处理系统；这一大型商品批发商拥有 N 个位于不同区域的仓库，每个仓库负责为 10 个销售点供货，每个销售点有 3000 个客户，每个客户平均一个订单有 10 项产品。

TPCC 测试模型（source: http://www.tpc.org/）

　　TPCC测试涉及到了新订单处理、更新客户账户余额并反馈支付状态、发货、查询客户交易记录及仓储状态等操作。其中每分钟的新订单量也被称为TpmC，是TPCC测试最重要的指标。

　　通过设置仓库个数（N）的值及并发连接数，可以调节TPCC测试的压力。由于TPCC测试涉及的操作类型较多，所以应用下发的I/O模型是个复杂的混合读写模型。因此，TPCC测试是一个对系统、CPU、内存及存储等组件综合性能及稳定性的评估方案。

　　TPC 不提供基准测试程序的代码，而只给出基准程序的标准规范。目前，很多厂商和实验室给出了符合TPCC测试规范的应用，本次我们测试使用的Percona TPCC-MySQL测试工具便是其中使用较为广泛的一种。

　　此次TPCC测试我们共生成了10000个仓库，整个数据库超过1.1TB，如此的数据库规模可以让压测短时间内充满系统Cache，让系统性能趋于稳定，避免大容量内存带来的结果偏高的现象。测试中将使用32，48，64，80，96，128几种不同的连接数对服务器进行压测，每次压测时间为30分钟（每次测试之前我们都会重启MySQL服务，以规避上次测试的影响）。首先是不同连接数的TPCC测试结果：

　　可以看到当Connection为48时，AMD EPYC 7F72双路系统的TPCC测试可以达到298951.875的TpmC的成绩。具体到Connection为48的这项测试，结果如下图：

　　可以看到TpmC值不足30万的实践主要集中在前10分钟，而之后的测试结果处于30万附近，且随时间的推进，测试成绩也趋于稳定。

　　04、OracleDB TPCC

　　最后，我们选择了商用数据库中最主流的产品——OracleDB来测试AMD EPYC 7F72双路系统的性能表现。

　　与之前使用的MySQL测试类似，通过设置仓库个数（N）的值及并发连接数，可以调节OracleDB的TPCC测试压力。测试中我们分别设置了1000、5000和12000三种warehouse数量，测试其在48、96、144和192个连接情况下的性能表现。

　　从上面的测试结果当中，我们可以看出无论warehouse数量多寡，峰值性能总是出现在96连接时。而在1000warehouse设置下，TPCC性能达到了峰值，为480,135 TpmC。

　　在不同的warehouse数量的设置当中1000和5000的峰值性能表现较为接近；而当warehouse数量来到12000时，性能下降则比较明显，并且不同连接数时的性能差异也在收窄，说明这一数量的warehouse已经达到了双路7F72系统的性能瓶颈。