MariaDB · 社区动态 · MariaDB on Power8 (下)

背景

上一期月报MariaDB on Power8我介绍了下 MariaDB 为 Power 处理器所做的一些优化,但是并没有给出实际测试的效果,这次月报我们借到了一台Power8的机器,有机会亲自试一把 MariaDB 在 Power 上的表现。

环境

一切不交代测试场景的Benchmark都是Benchmarketing。

因为Power和Intel之间对标的CPU型号我无法得知,因此这个测试仅仅用来观察MariaDB/MySQL在Power和Intel之间一些特质的差异,而非性能的直接对比。

Power 这边我们拿到的是 PowerVM 虚拟化的32核Power8机器,Intel这边用的是我们日常测试的E5-2630机型,虚拟机 vs 物理机,两者的价格我也没有数据,所以不要直接对比性能,不要直接对比性能,不要直接对比性能!

Power战队

处理器规格:

processor	: 0
cpu		: POWER8 (architected), altivec supported
clock		: 3425.000000MHz
revision	: 2.1 (pvr 004b 0201)

处理器核数:

[root@plx sysbench]# cat /proc/cpuinfo  | grep processor | wc -l
32

内存:

[root@plx sysbench]# free -g
              total        used        free      shared  buff/cache   available
Mem:             30           7           3           0          19          22
Swap:            15           0          15

Intel战队

处理器规格:

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 45
model name	: Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz
stepping	: 7
cpu MHz		: 2294.709
cache size	: 15360 KB
physical id	: 0
siblings	: 12
core id		: 0
cpu cores	: 6
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 x2apic popcnt aes xsave avx lahf_lm arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid
bogomips	: 4589.41
clflush size	: 64
cache_alignment	: 64
address sizes	: 46 bits physical, 48 bits virtual
power management:

处理器核数:

$cat /proc/cpuinfo  | grep processor | wc -l
24

内存:

$free -g
             total       used       free     shared    buffers     cached
Mem:           189         53        135          0          0          2
-/+ buffers/cache:         50        138
Swap:            1          0          1

CPU理论性能测试

首先我们用sysbench简单测试下CPU的计算能力。

测试命令:

sysbench --test=cpu --cpu-max-prime=20000 --num-threads=$num run

我在每个平台上至少执行了3次测试,只有连续三次测试结果差异极小的时候,才认为最后一次测试结果有效。因为Power8是一台虚拟机,并不能保证宿主机任何时候都只有我在用。

下面是原始测试数据的表格:

Power CPU理论测试

线程 总耗时(s) 平均延时(ms) 95%延时(ms)
1 201.67 20.17 20.19
4 66.61 26.64 33.18
8 59.90 47.90 106.78
16 49.18 78.62 119.75
32 37.37 119.36 119.86
64 37.37 237.32 349.90
128 37.38 469.16 619.61
512 37.38 1671.31 2179.63

Intel CPU理论测试

线程 总耗时(s) 平均延时(ms) 95%延时(ms)
1 827.08 82.71 83.02
4 206.97 82.77 83.24
8 103.45 82.72 83.14
16 60.02 95.96 114.39
32 47.52 151.89 230.74
64 47.53 303.26 350.64
128 47.53 604.46 695.92
512 47.53 2360.40 2759.46

CPU理论性能对比

(注:比值指的是相同线程数下,Intel耗时是Power的多少倍)

线程 Power总耗时(s) Intel总耗时(s) 比值
1 201.67 827.08 4.10
4 66.61 206.97 3.11
8 59.90 103.45 1.73
16 49.18 60.02 1.22
32 37.37 47.52 1.27
64 37.37 47.53 1.27
128 37.38 47.53 1.27
512 37.38 47.53 1.27

从上面三个图我们可以总结一些硬件上的特性:

  • 单核心效率Power要高于Intel。3.425GHz 的 Power8 耗时是 2.6GHZ 的 E5-2630 的 1/4,CPU频率只有1.3倍的差异;
  • 并发足够高时,性能差异并没有那么大,耗时稳定在1.27倍左右。而核心数Power也是Intel的1.33倍。

场景

本次测试共有三种场景:

  • MariaDB 10.1.10 on Power
  • MariaDB 10.1.10 on Intel
  • RDS MySQL 5.6.16 on Intel

为何没有 MySQL on Power 呢,因为编译不过。。。

Buffer Pool全部为16G,数据文件大小为8G上下,保证数据可以全部载入内存。

测试命令:

./sysbench --db-dirver=mysql --mysql-host=127.0.0.1 --mysql-port=3001 --mysql-user=root --test=tests/db/select.lua  --mysql-table-engine=innodb --oltp-table-size=500000  --oltp-tables-count=64 --max-time=1800 --max-requests=2000000000 --num-threads=$num run

为什么只测读?因为Power主机和Intel主机上使用的硬盘不一样,HDD vs. SDD,测写就完全没有意义了,HDD会被SSD吊打。

因为做过PREPARE之后就直接开测,没有关过MySQL,因此测试时数据都是在内存中的,不会产生物理IO。

下面是测试结果原始数据的表格:
(注:TPS变动比例指当前线程数下的TPS相对于上一轮测试的TPS的比值)

MariaDB on Power

线程 TPS 平均耗时(ms) 95%耗时(ms) TPS变动比例
1 14279.19 0.07 0.08
4 41563.43 0.09 0.12 291.08%
8 63601.75 0.12 0.18 153.02%
16 94346.29 0.17 0.23 148.34%
32 119444.32 0.26 0.45 126.60%
64 129451.95 0.49 0.82 108.38%
128 123414.89 1.03 1.75 95.34%
256 112408.11 2.27 4.00 91.08%
512 113163.74 4.52 8.59 100.67%
768 105875.56 7.24 15.53 93.56%

RDS MySQL on Intel

线程 TPS 平均耗时(ms) 95%耗时(ms) TPS变动比例
1 10742.70 0.09 0.11
4 40061.40 0.10 0.12 372.92%
8 68544.88 0.12 0.14 171.10%
16 109659.96 0.14 0.16 159.98%
32 149450.12 0.21 0.39 136.29%
64 145596.26 0.44 0.75 97.42%
128 139679.85 0.91 4.96 95.94%
256 141907.18 1.80 11.73 101.59%
512 61794.87 8.28 25.79 43.55%

MariaDB on Intel

线程 TPS 平均耗时(ms) 95%耗时(ms) TPS变动比例
1 9673.51 0.10 0.12
4 37394.20 0.11 0.13 386.56%
8 47347.03 0.17 0.19 126.62%
16 107496.94 0.15 0.18 227.04%
32 140805.33 0.22 0.35 130.99%
64 137045.70 0.46 0.66 97.33%
128 138472.96 0.92 0.36 101.04%
256 134908.32 1.90 7.23 97.43%
512 131814.55 3.88 19.04 97.71%

下面是对比的表格:

MySQL vs MariaDB on Intel

(注:变化率是指MariaDB的数值相对于MySQL的数值的比值的百分比)

线程 MySQL TPS 平均耗时(ms) 95%耗时(ms) MariaDB TPS 平均耗时(ms) 95%耗时(ms) TPS变化率 平均延时变化率 95%延时变化率
1 10742.70 0.09 0.11 9673.51 0.10 0.12 90.05% 111.11% 109.09%
4 40061.40 0.10 0.12 37394.20 0.11 0.13 93.34% 110.00% 108.33%
8 68544.88 0.12 0.14 47347.03 0.17 0.19 69.07% 141.67% 135.71%
16 109659.96 0.14 0.16 107496.94 0.15 0.18 98.03% 107.14% 112.50%
32 149450.12 0.21 0.39 140805.33 0.22 0.35 94.22% 104.76% 89.74%
64 145596.26 0.44 0.75 137045.70 0.46 0.66 94.13% 104.55% 88.00%
128 139679.85 0.91 4.96 138472.96 0.92 0.36 99.14% 101.10% 7.26%
256 141907.18 1.80 11.73 134908.32 1.90 7.23 95.07% 105.56% 61.64%
512 61794.87 8.28 25.79 131814.55 3.88 19.04 213.31% 46.86% 73.83%

MariaDB on Intel vs Power

(注:变化率是指Power平台的数值相对于Intel平台的数值的比值的百分比)

线程 Intel TPS 平均耗时(ms) 95%耗时(ms) Power TPS 平均耗时(ms) 95%耗时(ms) TPS变化率 平均延时变化率 95%延时变化率
1 9673.51 0.10 0.12 14279.19 0.07 0.08 147.61% 70.00% 66.67%
4 37394.20 0.11 0.13 41563.43 0.09 0.12 111.15% 81.82% 92.31%
8 47347.03 0.17 0.19 63601.75 0.12 0.18 134.33% 70.59% 94.74%
16 107496.94 0.15 0.18 94346.29 0.17 0.23 87.77% 113.33% 127.78%
32 140805.33 0.22 0.35 119444.32 0.26 0.45 84.83% 118.18% 128.57%
64 137045.70 0.46 0.66 129451.95 0.49 0.82 94.46% 106.52% 124.24%
128 138472.96 0.92 0.36 123414.89 1.03 1.75 89.13% 111.96% 486.11%
256 134908.32 1.90 7.23 112408.11 2.27 4.00 83.32% 119.47% 55.33%
512 131814.55 3.88 19.04 113163.74 4.52 8.59 85.85% 116.49% 45.12%

这个测试结果跟上一篇月报中IBM给出的官方测试对比有很大差异。

我们就来看看这些测试结果反映了些什么问题:

  • 如果只看 MariaDB on Power 和 MySQL on Intel 的结果,我会以为 Power 在高并发时性能更稳定,但看了 MariaDB on Intel 的测试结果之后,意识到这是 MariaDB Thread Pool 的功劳,并不是Power平台的优势;
  • 对比 MySQL on Intel 和 MariaDB on Intel 可以明显的看到,16并发和256并发是明显的分水岭,16并发之前MySQL优势明显,16并发到256并发之间两者差距不大,256并发之后,MariaDB完爆MySQL;
  • 看 MariaDB 在 Power 和 Intel 平台下的表现,16并发之前 Power 优势会明显一点,16并发之后 Intel 就追上来了并且超越了 Power。这跟我们上面做的 CPU 理论测试结果差不多,大家可以上去翻表格,16线程之前 Power 效率要高于 Intel,但是之后基本就稳定了;
  • 所以,官方的Benchmark永远不可靠,自己动手才是硬道理。
时间: 2024-08-30 08:12:53

MariaDB · 社区动态 · MariaDB on Power8 (下)的相关文章

MariaDB · 社区动态 · MariaDB on Power8

前言 Power平台作为IBM的企业级平台,其稳定性和高效能在业界尤其是大型金融企业有着良好的口碑,MariaDB作为MySQL的重要开源分支,也对IBM Power8平台进行了适配. 很幸运我拿到了一台Power8的机器,在Linux on Power上成功编译了MariaDB 10.1版本,不过还没有拿到同规格的PC服务器用于对比,所以本期我先介绍一下MariaDB on Power的一些信息,下期月报我会拿出实测对比数据,并且分析一下MariaDB在Power平台和x86平台上关键路径的效

MySQL · 社区动态 · MariaDB 10.2 前瞻

继 MariaDB 10.1 之后,对标 MySQL 5.7 的 MariaDB 10.2 版本也即将封板,那么我们就来看看新的版本有哪些新的功能吧. 之前的月报我们写过一篇关于 Window Function 的介绍,除此之外,10.2.2 又即将发布一些新的特性. Virtual Columns 进一步加强 目前有两种类型的虚拟列:PERSISTENT/STORED 类型,这种类型的虚拟列的值是直接存在表中的:而 VIRTUAL 类型,其实只是一个定义,表结构中并不包括这个列,在需要用到的时

数据库内核月报 - 2015 / 08-MySQL · 社区动态 · MariaDB InnoDB表空间碎片整理

介绍 当你对InnoDB进行修改操作时,例如删除一些行,这些行只是被标记为"已删除",而不是真的从索引中物理删除了,因而空间也没有真的被释放回收.InnoDB的Purge线程会异步的来清理这些没用的索引键和行,但是依然没有把这些释放出来的空间还给操作系统重新使用,因而会导致页面中存在很多空洞.如果表结构中包含动态长度字段,那么这些空洞甚至可能不能被InnoDB重新用来存新的行,因为空间空间长度不足. 有些用户可能会使用 OPTIMIZE TABLE 或者 ALTER TABLE <

MySQL · 社区动态 · MariaDB Role 体系

背景 从 MairaDB 10.0.5 开始,MariaDB 开始提供 Role(角色)的功能,补全了大家一直吐槽的 MySQL 不能像 Oracle 一样支持角色定义的功能. 一个角色就是把一堆的权限捆绑在一起授权,这个功能对于有很多用户拥有相同权限的情况可以显著提高管理效率.在有角色之前,这种情况只能为每个用户都做一大堆的授权操作,或者是给很多个需要相同权限的用户提供同一个账号去使用,这又会导致你要分析用户行为的时候不知道哪个操作是哪个具体用户发起的. 有了角色,这样的管理就太容易了.例如,

MySQL · 社区见闻 · MariaDB Developer Meeting 2016

高能预警:这还不是一篇纯技术的月报-- 前言 Percona Live 之后紧接着第二天就是 MariaDB Developer Meeting,会议地点就在Booking的办公大楼这次会议的主题就是讨论 10.3 的规划,以及 10.2 的 GA 计划,以及还需要加入 10.2 的功能. 先哭一会别人家的办公楼,这风景. MariaDB Foundation 不比各种商业公司,全靠捐赠维持,所以能简化就简化,因此没有高大上的参会证了,就这么个手写的-- 本次作为基金会 Replication

mariadb multi-source replication(mariadb多主复制)

mariadb multi-source replication(mariadb多主复制) 在mariadb-10.0里面加入了多主复制功能. 修改过的语法:针对每个复制线程会有一个对应的connection_name,而connection_name是default_master_connection变量的值,如果你要操作对应的复制线程,需要将这个变量设置为对应的复制线程的名字. connection_name的值是长度小于64的任何字符串,并且对大小写不敏感.你需要尽量让连接名固定,因为它会

jquery动态加载select下拉框示例代码

 动态加载select下拉框的实现方法有很多,在接下来的文章中为大家介绍下jquery是如何实现的 如题,直接上代码,实战学习.  代码如下: <head><title>jquery实现动态加载select下拉选项</title>  <script type="text/javascript">  function init(){  makemoduleSelect();  }  //加载模板下拉框选项  function makemod

Android动态修改src目录下的Properties文件如何做?

问题描述 Android动态修改src目录下的Properties文件如何做? 解决方案 http://wenku.baidu.com/link?url=IXMKvhkrBs8_wj_uY27b3BYf_0fqCWm-XwXpwDAvNgMDkByJiw7j2nZOfSWcnmI2XlGdokvfD5zVXjhYKiyToHzfl4YxzgHDXlvOsjHXV9i(java修改properties文件)希望对你帮助!

Android应用开发提高系列(5)——Android动态加载(下)——加载已安装APK中的类和资源

前言  Android动态加载(下)--加载已安装APK中的类和资源.   声明 欢迎转载,但请保留文章原始出处:)  博客园:http://www.cnblogs.com 农民伯伯: http://over140.cnblogs.com  Android中文Wiki:http://wikidroid.sinaapp.com     正文 一.目标 注意被调用的APK在Android系统中是已经安装的.    上篇文章:Android应用开发提高系列(4)--Android动态加载(上)--加载