引言

本文是我的原博客 https://blog.mariadb.org/performance-evaluation-of-mariadb-10-1-and-mysql-5-7-4-labs-tplc 的后续。首先，我要感谢收到的所有评论。根据评论，有人担心看到的性能差异是否由于不同的配置设置所致。此外，我之前不知道 MySQL 中有一个配置变量可以实现类似于 MariaDB 的多线程刷新机制。为了弄清不同的配置变量或不同的默认设置是否是性能差异的原因，我进行了几轮新的测试。

测试 1

更改 buffer pool 实例的数量或 innodb thread concurrency 的值似乎对至少 LinkBench 基准测试的性能结果没有显著影响。但是，更改刷新线程的数量会产生影响。下面我将展示 MariaDB 和 MySQL 使用页面压缩的结果。最低那条线是之前已在 https://blog.mariadb.org/performance-evaluation-of-mariadb-10-1-and-mysql-5-7-4-labs-tplc/ 中展示的原始结果。

更改参数产生了影响，并且 LinkBench 基准测试的性能结果有所改善。然而，改进对两个服务器来说是相似的。显然，在这种配置下，MariaDB 在此基准测试中仍然优于 MySQL。下面是本次测试中使用的全套配置变量。

[mysqld]
basedir=/usr/local/mysql
user=root
socket=/tmp/mysql.sock
server_id=1
local_infile=1
pid-file=/tmp/server1.pid
port=3306
max_connections = 3000
back_log = 1500
open_files_limit = 1500
table_open_cache = 520
table_open_cache_instances = 32
key_buffer_size = 16M
query_cache_type = 0
join_buffer_size = 32K
sort_buffer_size = 32K
skip-grant-tables

innodb_buffer_pool_size=50G
innodb_use_native_aio=1
innodb_data_file_path=ibdata1:50M:autoextend
innodb_file_per_table=1
innodb_open_files=100
innodb_flush_log_at_trx_commit=1
innodb_lock_wait_timeout = 120
innodb_doublewrite=0
innodb_buffer_pool_instances=16
innodb_mtflush_threads=16
innodb_compression_level=6
innodb_compression_algorithm=2
max-prepared-stmt-count=400000
innodb_fast_shutdown=0

innodb_log_buffer_size=256M
innodb_log_files_in_group=3
innodb_log_file_size=8G

innodb_thread_concurrency=32
innodb_flush_method = O_DIRECT
innodb_write_io_threads=16
innodb_read_io_threads=16

innodb_max_dirty_pages_pct=90
skip-name-resolve
innodb_adaptive_flushing=1
innodb_file_format=barracuda
innodb_fast_shutdown=0

#used on MariaDB
innodb_mtflush_threads=16
innodb_use_mtflush=1

#used on MySQL
#innodb_page_cleaners=16
#innodb_compression_punch_hole=1

# IO
innodb_checksum_algorithm=crc32  
innodb_flush_neighbors=0
innodb_lru_scan_depth=2500 
innodb_io_capacity=25000 
innodb_io_capacity_max=35000

#xtradb
ignore-builtin-innodb
plugin-load=innodb=ha_innodb.so
plugin-dir=/mnt/fiob/10.0-FusionIO/storage/innobase
#innodb_log_block_size=4096

[mysql]
local-infile=1
[client]

测试 2

在我还在测试不同配置设置时，一篇关于类似性能测量的优秀博客发表在 http://dimitrik.free.fr/blog/archives/2014/08/mysql-performance-analyzing-linkbench-workload-on-mysql-57-and-mariadb-101.html。这篇博客又使用了不同的配置（自然硬件也不同）。结果非常有趣，我决定尝试重复一遍。

我从使用未压缩表获得的结果开始，我的系统使用的是 Intel Xeon CPU e5-2690 2.90GHz，2 个插槽，8 个核心，使用超线程，即总共 32 个核心。我使用 CentOs 6.4 和 Linux 3.4.12。存储是 Fusion-io ioDrive2 Duo，驱动版本 3.3.3 build 716，固件 v7.2.5，格式化为 NVMFS。

与 DimitriK 博客中获得的结果存在明显差异。首先，两个服务器的结果都好得多。我使用的系统核心数量较少，但频率更高。此外，该系统使用了较新版本的 NVMFS。在我的结果中，我使用了 24 小时的测量时间和 150G 数据库。DimitriK 在他的博文中使用了 30 分钟。此外，我使用了几乎相同的配置，只有一个例外。我使用了与 innodb_page_cleaners 完全相同数量的 innodb_mtflush_threads。在我的结果中，MariaDB 的性能仍然优于 MySQL。但是，让我们也看看页面压缩的结果。

显然，这些新参数比之前使用的参数更好。我感谢 DimitriK 指出了这些。

MariaDB 和 MySQL 之间的差异更大，并且 MariaDB 的性能仍优于 MySQL。底线是我无法重复该博客中的结果。这个版本的 MariaDB 确实不包含 InnoDB 索引锁争用的修复，但这在这种环境下似乎不是问题。查看 performance schema 的数值，可以发现这一点。

仅供记录，这里是使用的配置变量。

[mysqld]
basedir=/usr/local/mysql
socket=/tmp/mysql.sock
user=root
port=3306
max_connections=4000
skip_grant_tables

#myisam
key_buffer_size = 4000M
ft_max_word_len = 16
low_priority_updates = 2

#general
table_open_cache = 8000
table_open_cache_instances=16
back_log=1500
query_cache_type = 0

#files
innodb_file_per_table=1
innodb_file_format=Barracuda
innodb_log_file_size=1024M
innodb_log_files_in_group=12
innodb_open_files=4000

#buffers
innodb_buffer_pool_size = 75000M
innodb_buffer_pool_instances=32
innodb_log_buffer_size=64M

#tune
innodb_checksums=1
innodb_checksum_algorithm=crc32
innodb_doublewrite=0
innodb_support_xa=0
innodb_thread_concurrency=0
innodb_flush_log_at_trx_commit=1
innodb_flush_method=O_DIRECT
innodb_max_dirty_pages_pct=90
innodb_max_dirty_pages_pct_lwm=10
innodb_lru_scan_depth=4000
#for MYSQL
#innodb_page_cleaners=4

join_buffer_size=32K
sort_buffer_size=32K
innodb_use_native_aio=1
innodb_stats_persistent = 1
innodb_spin_wait_delay=6

#perf special
innodb_adaptive_flushing=1
innodb_flush_neighbors=0
innodb_read_io_threads=16
innodb_write_io_threads=16
innodb_io_capacity=15000
innodb_purge_threads=4
innodb_max_purge_lag_delay=30000000
innodb_max_purge_lag=1000000
innodb_adaptive_hash_index=0

#monitoring
innodb_monitor_enable = '%'
performance_schema=ON
performance_schema_instrument='%sync%=on'

#mariadb
innodb_compression_algorithm=2
innodb_use_mtflush=1
innodb_mtflush_threads=4
innodb_use_fallocate=1
innodb_use_atomic_writes=1
ignore-builtin-innodb
plugin-load=ha_innodb.so
plugin-dir=/mnt/fioa/MariaDB-10.1/storage/innobase

结论

我的观察

• 配置变量的值会显著影响性能，因此根据基准测试和硬件来调优变量以获得最佳性能非常重要。
• 我的原始博客中的性能测量结果是正确的，即使不是最优的。
• 我未能重复 DimitriK 博客中呈现的显著性能差异。一些可能的原因：
  • 我们使用不同的发行版和硬件
  • 博客使用了较短的 30 分钟测量时间（我不认为这是问题）
  • 博客仅使用了未压缩的表（根据我的结果，这不是问题）
  • 博客在 MariaDB 上使用了 XtraDB（作为默认值），这可能会产生一些影响，但不是全部
  • 我使用了默认编译 (cmake . ; make )
• 由于 DimitriK 指出的索引锁争用，MariaDB 的性能不是最优的。这将在更高版本的 MariaDB 10.1 中修复。