mySQL v5.6 复制的事务速度基准测试 - 似乎很慢

Question

我正在尝试为我们的新基础架构选择最佳配置，但对结果有些困惑。

我使用 sysbench v0.5 进行测试：

准备数据

 sysbench --test=/usr/share/doc/sysbench/tests/db/oltp.lua \
 --oltp-test-mode=complex --oltp-table-size=1000000 \
 --mysql-db=mydb --mysql-user=root --mysql-password=mypassword prepare

做测试

 sysbench --test=/usr/share/doc/sysbench/tests/db/oltp.lua \
 --oltp-test-mode=complex --oltp-table-size=1000000 --oltp-read-only=off \
 --num-threads=6 --max-time=60 --max-requests=0 \
 --mysql-db=mydb --mysql-user=root --mysql-password=mypassword run

从下面的结果可以看出，主-主复制（3台机器的percona）性能最差，然后是mySQL主-从（2台机器）配置，最快的是mySQL作为单个独立服务器。

这是复制解决方案的正常情况吗？看起来太慢了，配置之间的 10 倍差异在我看来很不正常。也许我错过了一些东西......我对 Percona Galera Cluster 完全失望，它以对 innodb 的速度着称。呼:)

请检查下面提供的信息并提出建议，谢谢。

关于服务器

---

硬件

• 英特尔® 至强® E5-1650 v2 六核
• 64 GB ECC 内存
• 2 x 240 GB 6 Gb/s SSD 数据中心版（软件-RAID 1）
• 1 Gbit/s 带宽

操作系统

• Debian Wheezy
• 所有软件包都已更新/升级。

连接等

• 服务器位于同一个数据中心，都与一个 Gbit 交换机相连，并有第二个以太网卡，所有这些都配置为它们之间的专用网络。

• 目前，服务器上没有负载。

磁盘性能

第一次测试

# hdparm -Tt /dev/sda

/dev/sda:
 Timing cached reads:   27166 MB in  2.00 seconds = 13599.63 MB/sec
 Timing buffered disk reads: 1488 MB in  3.00 seconds = 495.64 MB/sec

第二次测试

# dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output
 10240+0 records in
 10240+0 records out
 83886080 bytes (84 MB) copied, 0.0517404 s, 1.6 GB/s

/etc/my.cnf 配置

• Percona 的向导用于初始配置。

• 我使用官方手册/网站和其他可靠来源来学习和配置复制。

• 默认存储引擎使用InnoDB（sysbench创建的测试表也是InnoDB）

Percona XtraDB v5.6 Galera Cluster：第一个节点的my.cnf

[client]
port            = 3306
socket          = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket          = /var/run/mysqld/mysqld.sock
nice            = 0

[sst]
streamfmt=xbstream

[xtrabackup]
# compress
# compact
parallel=8
compress-threads=8
rebuild-threads=8

[mysqld]
wsrep_node_name=db1
# Path to Galera library
wsrep_provider=/usr/lib/libgalera_smm.so
# Cluster connection URL
wsrep_cluster_address=gcomm://192.168.1.4,192.168.1.5,192.168.1.6
# This changes how |InnoDB| autoincrement locks are managed and is a requirement for Galera
innodb_autoinc_lock_mode=2
# Node #1 address
wsrep_node_address=192.168.1.4
# SST method
wsrep_sst_method=xtrabackup-v2
# Cluster name
wsrep_cluster_name=my_cluster
# Authentication for SST method
wsrep_sst_auth="replicateuser:replicateuserpassword"

# GENERAL #
user                           = mysql
default_storage_engine         = InnoDB
socket                         = /var/run/mysqld/mysqld.sock
pid_file                       = /var/run/mysqld/mysqld.pid

# Rolandomysqldba's recommendation
innodb_thread_concurrency       = 0
innodb_read_io_threads          = 64
innodb_write_io_threads         = 64

# MyISAM #
key_buffer_size                = 32M
myisam_recover_options         = FORCE,BACKUP

# SAFETY #
max_allowed_packet              = 16M
max_connect_errors              = 1000000
skip_name_resolve
sysdate_is_now                  = 1
innodb                          = FORCE

# DATA STORAGE #
datadir                         = /var/lib/mysql/

# BINARY LOGGING #
log_bin                         = /var/lib/mysql/mysql-bin
expire_logs_days                = 14
sync_binlog                     = 1

# CACHES AND LIMITS #
tmp_table_size                  = 32M
max_heap_table_size             = 32M
query_cache_type                = 0
query_cache_size                = 0
max_connections                 = 500
thread_cache_size               = 50
open_files_limit                = 65535
table_definition_cache          = 4096
table_open_cache                = 8K

# INNODB #
innodb_flush_method             = O_DIRECT
innodb_log_files_in_group       = 2
innodb_log_file_size            = 512M
innodb_flush_log_at_trx_commit  = 1
innodb_file_per_table           = 1
innodb_buffer_pool_size         = 42G

# LOGGING #
long_query_time                 = 5
log_error                       = /var/log/mysql/error.log
log_queries_not_using_indexes   = 1
slow_query_log                  = 1
slow_query_log_file             = /var/log/mysql/slow.log

[mysqldump]
quick
quote-names
max_allowed_packet      = 16M

[isamchk]
key_buffer              = 16M

Sysbench 测试结果

---

mySQL v5.6.21（单机）

transactions: 101001 (1683.29 per sec.)

mySQL v5.6.21 复本（主+1从）

主从在线

transactions: 10501  (174.95 per sec.)

Slave 离线，binlog 同步关闭

transactions: 11280  (187.86 per sec.)

从站离线

transactions: 10779  (179.55 per sec.)

具有主从延迟（1 小时）

transactions: 10595  (176.48 per sec.)

MariaDB v5.5（单机）

transactions: 73683  (1228.00 per sec.)

Percona XtraDB v5.6 Galera Cluster (3 Master-Master, xtrabackup-v2)

Master（初始节点）

transactions: 703    (11.65 per sec.)

在另一个节点上测试

transactions: 643    (10.67 per sec.)

将复制方法更改为 rsync

transactions: 652    (10.80 per sec.)

Answer 1

你应该把一切都放在一个公平的竞争环境中。如何 ？

\n

如果没有适当的调整，旧版本的 MySQL 可能会超越新版本。

\n

\n
• Sep 25, 2013：为什么我应该使用InnoDB和MySql而不是XtraDB和MariaDB？
\n
• Mar 26, 2012：Percona 与 MySQL
\n
• Nov 24, 2011:为什么mysql 5.5比5.1慢（linux，使用mysqlslap）
\n
• Oct 05, 2011：在一些较新的 MySQL 版本中查询运行时间很长
\n
• Jun 19, 2011：如何正确执行 MySQL 烘焙？
\n

\n

在三个环境上运行 SysBench 之前

\n

\n
• 确保所有数据库服务器的所有 InnoDB 设置均相同
\n
• 对于Master/Slave，STOP SLAVE;在Slave上运行
\n
• 对于 PXC（Percona XtraDB Cluster），关闭两个 Master
\n

\n

比较独立 MySQL、Percona 和 MariaDB 的速度。

\n

分析

\n

如果 MySQL 是最好的（Percona 的人，请不要向我扔烂蔬菜。这只是推测），运行START SLAVE;。在主/从机上运行 SysBench。如果性能明显变慢，您可能必须实施半同步复制。

\n

如果 PXC 最好，您可能需要调整 wsrep 设置或网络本身。

\n

如果 MariaDB 最好，您可以切换到MariaDB Cluster（如果您有钱）或使用 MariaDB 设置主/从。运行 Sysbench。如果性能明显变慢，您可能需要调整 wsrep 设置或网络本身。

\n

为什么要调整 wsrep 设置？请记住，Galera wsrep（WriteSet Replication）使用几乎同步的提交和回滚。换句话说，要么所有节点提交，要么所有节点回滚。在这种情况下，最薄弱的环节必须是

\n

\n
• 节点之间的通信速度有多快（尤其是当节点位于不同的数据中心时）
\n
• 如果任一节点的硬件设置配置不足
\n
• 如果任何一个节点的通信速度比其他节点慢
\n

\n

旁注：您还应该确保针对多个 CPU 调整 MySQL

\n

\n
• Jun 01, 2012:我有16GB内存，我应该如何配置MySQL服务器？
\n
• May 07, 2012：MySQL服务器性能
\n
• Apr 26, 2012：CPU 性能与数据库服务器相关吗？
\n
• Mar 16, 2012：在 Debian 上使用多核进行单个 MySQL 查询
\n
• Oct 07, 2011：我应该使用 MyISAM 以外的存储引擎来优化这些表还是应该使用更好的磁盘？
\n
• Sep 20, 2011：多核和 MySQL 性能
\n
• Sep 12, 2011:可以让MySQL使用多个核心吗？
\n
• May 26, 2011：关于单线程与多线程数据库性能
\n

\n

更新时间 2014-11-04 21:06 美国东部时间

\n

请记住，Percona XtraDB Cluster 一开始就不能很好地编写扩展。请注意文档在其缺点（第二个缺点）下所说的内容：

\n

\n

这可以\xe2\x80\x99 用作有效的写入扩展解决方案。当您将写入流量运行到 2 个节点与将所有流量运行到 1 个节点时，写入吞吐量可能会有所提高，但您不能期望太多。所有写入仍然必须在所有节点上进行。

\n

\n

建议#1

\n

对于 PXC，关闭一个节点。针对两节点集群运行 SysBench。如果写入性能优于三节点集群，那么很明显节点之间的通信是瓶颈。

\n

建议#2

\n

我注意到您有一个 42GB 缓冲池，这超过了服务器 RAM 的一半。您需要通过将 innodb_buffer_pool_instances设置为 2 或更多来对缓冲池进行分区。否则，您可能会发生一些交换。

\n

建议#3

\n

你的innodb_log_buffer_size默认是8M。尝试将其设置为 256M 以提高日志写入性能。

\n

建议#4

\n

你的innodb_log_file_size是512M。尝试将其设置为 2G 以提高日志写入性能。如果应用此设置，请将innodb_log_buffer_size设置为 512M。

\n