Cloud MySQL Performance Benchmark
Posts of Cloud MySQL Performance Benchmark
-
Oracle Cloud 是所有云平台最先支持 9.0 版本的。这里,我们来看看该版本的“标准性能”表现如何。
测试实例与环境说明
这里使用的实例类型是:
MySQL.4
,单个节点为4 ecpu 32gb
,测试区域选择的是“东京”(ap-tokyo-1),多可用区(FAULT DOMAIN)的版本,测试实例存储空间大小为 100 gb。即:instance_type=MySQL.4 vcpu_per_node=4 memory_size_per_node=32 region=tokyo availability=multi-az storage_size=100 db_version=8.0.39/8.4.2/9.0.1
性能对比
本次测试分别测试了 8.0.39/8.4.2/9.0.1 这三个版本。详细的性能对比如下:
data MySQL80 MySQL84 MySQL90 4 3551 3606 3360 8 5936 5378 5256 16 8054 8186 7287 32 8317 8029 7817 48 8130 8204 7911 64 7838 7981 8060 96 8504 8430 8172 128 8198 8286 8000 192 8043 8053 8112 256 7907 8034 7536 384 8209 8055 8151 512 8386 8030 7872 性能概述
从该“标准”测试来看,9.0.1的性能较为稳定。从上述数据中来看,似乎略微低于 8.0和8.4 版本,但经过调查,主要原因是由于云平台 CPU 资源多少所导致的,而并不是数据库本身的问题。
此外,在今年5月份观察到的8.4性能退化问题(参考),目前也已经解决。
-
这是一个系列文章的一部分,该系列较为完整的对各个云厂商的RDS MySQL进行了测试,包括了阿里云、腾讯云、华为云、百度云、AWS、Azure、GCP、Oracle Cloud等,更多参考:云数据库RDS MySQL的性能。
在不同的云厂商,购买相同规格的MySQL实例(如4vCPU-16GB),获得的性能相同吗?
data aliyun_202409_hangzhou->stdbench tencent_202409_beijing_exclusive->stdbench hwcloud_202409_beijing_x86->stdbench baiducloud_202409_beijing->stdbench aws_202409_tokyo_m6i->stdbench azure_202409_east_asia_4c16g->stdbench gcp_202409_tokyo_80_enterprise->stdbench oci_202409_tokyo_8039->mysql_on_4_ecpu 4 7102 5592 2557 2206 1639 2025 723 3551 8 9702 9936 4674 4101 3313 3654 1341 5936 16 14660 16141 8229 7298 6427 6548 2502 8054 32 22155 22336 13520 12022 12157 10363 4857 8317 48 27905 24770 17849 16448 16516 11973 6745 8130 64 32704 26495 20114 18187 18118 12761 8071 7838 96 36846 29077 20883 21007 20782 13300 9675 8504 128 39697 29918 20128 21029 22446 13388 10620 8198 192 38999 30610 20521 22091 22590 13478 11507 8043 256 38356 31052 21187 21665 22323 12985 11872 7907 384 39679 31224 21729 21167 21902 12904 12131 8209 512 40333 31805 22647 21627 21591 12930 12106 8386 have_ssl DISABLED DISABLED DISABLED DISABLED YES YES YES YES innodb_buffer_pool_size 9.75GB 12GB 9GB 12GB 11GB 12GB 11GB 17GB innodb_doublewrite ON ON ON ON OFF OFF ON ON innodb_flush_log_at_trx_commit 1 1 1 1 1 1 1 1 innodb_flush_method O_DIRECT O_DIRECT O_DIRECT fsync O_DIRECT fsync O_DIRECT O_DIRECT innodb_io_capacity 20000 20000 12000 2000 200 200 5000 1250 innodb_read_io_threads 4 4 4 8 4 NA 4 2 innodb_write_io_threads 4 4 4 8 4 NA 4 4 log_bin ON ON ON ON OFF ON ON ON performance_schema OFF OFF OFF OFF OFF ON ON ON rpl_semi_sync_master_enabled ON ON ON ON NA NA NA NA rpl_semi_sync_master_timeout 1000 10000 10000 10000 NA NA NA NA sync_binlog 1 1 1 1000 1 1 1 1 thread_pool_size 8 4 NA NA NA 4 NA 16 version 8.0.36 8.0.30-txsql 8.0.28-231003 8.0.32-2.0.0.2 8.0.35 8.0.37-azure 8.0.31-google 8.0.39-cloud cpu_capacity 80.4 93.3 163.6 73.9 110.9 56.3 49.9 114.7 测试结果概述
在本次测试中:阿里云RDS MySQL性能表现最好,极限的QPS达到了4万;其次是腾讯云,达到了3.2万;第二梯队是华为云、百度云和AWS,极限的QPS约2.2万;之后是Azure、Google云,极限QPS约1.2万;最后是Oracle云,极限QPS约8500。详细的数据和趋势图,可以参考以上的图、表,这里不再详述。
(more…) -
本问是一个系列文章的一部分,该系列较为完整的对各个云厂商的RDS MySQL进行了测试,包括了阿里云、腾讯云、华为云、百度云、AWS、Azure、GCP、Oracle Cloud等,更多参考:云数据库RDS MySQL的性能。
在不同的云厂商,购买相同规格的MySQL实例(如4vCPU-16GB),获得的性能相同吗?
为了回答上面的疑问,于是就开启了我的数据库性能测试之旅。这是第二次测试,上一次是在2023年12月(参考:云数据库(RDS MySQL)性能深度测评与对比)。
性能测试结果与概述
(more…) -
近日,MySQL发布了8.4版本,这是一个新的稳定版。在MySQL版本规划中,在2026年8.0.x生命周期结束后,将成为下一个主流稳定版本。
目前为止,看到该版本并没有特别大的改进。部分改变包括改进了直方图统计信息更新、并行复制、组复制(GR)等,完整的更新可以参考:Changes in MySQL 8.4.0 (2024-04-30, LTS Release)。
MySQL 8.4@OCI性能测试(vs MySQL 8.0)
Oracle Cloud上也第一时间支持了该版本,于是也通过性能测试的方式,第一时间“尝鲜”了一下该版本。性能测试的趋势图如下:
注意到,在该Sysbench测试模式下:
- 当前MySQL 8.4在性能上相对于8.0版本,要低21%(以16并发为参考)
- 并在超高并发时(并发高于192),性能出现了严重的退化
作为一个稳定版本,期待官方尽快解决。
(more…) -
本问是一个系列文章的一部分,该系列较为完整的对各个云厂商的RDS MySQL进行了测试,包括了阿里云、腾讯云、华为云、百度云、AWS、Azure、GCP、Oracle Cloud等,更多参考:云数据库RDS MySQL的性能。
在Oracle Cloud Infrastructure(简称OCI,也就是Oracle云)上购买MySQL实例,也会有第三代CPU和第四代CPU规格的选择,分别是:
MySQL.VM.Standard.E4.2.32GB
和MySQL.VM.Standard.E3.2.32GB
。本文对比两个版本规格的价格与性能,以供参考。结论概述
E4(AMD EPYC 7J13)、E3(
AMD EPYC 7742
)同属于AMD系列的CPU,E4似乎主要是在OCI平台,E3较为通用。从性能测试上,可以看到,E4相比于E3有着较为明显的性能优势,以常见的16并发时数据为参考,则E4(MySQL.VM.Standard.E4.2.32GB
)相比于E3(MySQL.VM.Standard.E3.2.32GB
)性能要高11%。这也与之前的,“新一代CPU总是有着更高的性能”的结论一致。
(more…)