MariaDB Galera 集群服务器以 100% CPU 运行且负载上升

Question

我有一个 Drupal 应用程序，它已经在单个 MySQL 数据库服务器上运行了 12 个月，并且性能相对较好（除了峰值负载事件）。我们需要能够支持比当前数据库服务器允许的更高的峰值，并且在 32GB 时，简单地垂直扩展单个数据库服务器并没有太大的收益。

我们决定建立一个包含 2 个 32GB 实例的新 MariaDB Galera 集群。我们尽可能将配置与即将淘汰的数据库服务器相匹配。

迁移到新的数据库服务器后，我们注意到这些实例上的 CPU 使用率一直保持在 100%，并且负载在稳步增加。在 1 小时内，平均负载从 0.1 变为 150。

最初我们认为这可能与服务器之间的同步有关，但即使关闭了 1 台服务器并且没有发生同步，只要 Web 应用程序向它发出请求，它仍然会耗尽 CPU。

经过大量实验后，我发现减少一些配置选项会对 CPU 使用率和负载产生深远影响。进行以下更改后，两个实例的平均负载稳定在 4 到 6 之间。

问题

• 尽管本质上是从旧服务器迁移配置，但新旧服务器之间的 CPU 使用率差异如此之大的可能原因有哪些？
• 负载目前在 4 到 6 之间徘徊（这是我们网站的低流量时期）。我应该注意什么来尝试降低此值，并确保当网站受到一些实际流量的影响时它不会崩溃？

配置更改

innodb_buffer_pool_instances

• 原始值：500（所有数据库共498张表）
• 新值：92

table_cache

• 原值：8
• 新值：4

最大连接数

• 原值：1000
• 新值：400

当前配置

这是来自其中一台服务器 /etc/mysql/my.cnf 的完整配置文件

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

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

[mysqld]

binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
query_cache_type=1
bind-address=0.0.0.0

max_connections = 400
wait_timeout = 600
key_buffer_size    =  16M
max_allowed_packet  = 16777216
max_heap_table_size = 512M
table_cache = 92 
thread_stack    = 196608
thread_cache_size       = 8
myisam-recover         = BACKUP
query_cache_limit = 1048576
query_cache_size        = 128M
expire_logs_days  = 10
general_log = 0
max_binlog_size         = 10485760
server-id = 0
innodb_file_per_table
innodb_buffer_pool_size = 25G
innodb_buffer_pool_instances = 4
innodb_log_buffer_size = 8388608
innodb_additional_mem_pool_size = 8388608
innodb_thread_concurrency = 16
net_buffer_length = 16384
sort_buffer_size = 2097152
myisam_sort_buffer_size = 8388608
read_buffer_size = 131072
join_buffer_size = 131072
read_rnd_buffer_size = 262144
tmp_table_size = 512M

long_query_time = 1
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log

# Galera Provider Configuration
wsrep_provider=/usr/lib/galera/libgalera_smm.so
#wsrep_provider_options="gcache.size=32G"

# Galera Cluster Configuration
wsrep_cluster_name="xxx"
wsrep_cluster_address="gcomm://xxx.xxx.xxx.107,xxx.xxx.xxx.108"

# Galera Synchronization Congifuration
wsrep_sst_method=rsync
#wsrep_sst_auth=user:pass

# Galera Node Configuration
wsrep_node_address="xxx.xxx.xxx.107"
wsrep_node_name="xxx01"


[mysqldump]
quick
quote-names
max_allowed_packet  = 16777216

[isamchk]
key_buffer_size    = 16777216

Answer 1

我们最终聘请了一位 Percona 顾问来帮助解决这个问题。他们发现的主要问题是正在执行大量 EXPLAIN 查询。原来这是一些启用的调试代码（drupal 开发人员的 devel.module 查询日志记录）。禁用此功能会导致 CPU 使用率急剧下降。

他们建议我们实施一些额外的修复。

• 向集群中添加第三个节点以充当观察者并维护集群的完整性。
• 向没有主键的表添加主键。
• 将 MyISAM 表更改为 InnoDB。
• 将 wsrep_sst_method 从 rsync 更改为 xtrabackup-v2。
• 将 innodb_log_file_size 设置为 512M。
• 将 innodb_flush_log_at_trx_commit 设置为 2，因为集群会维护数据的完整性。

我希望这些信息对遇到类似问题的人有所帮助。

Answer 2

innodb_buffer_pool_instances 不应该是表数的函数。手册提倡每个实例不小于1GB。所以，我建议即使是 92 也太高了。但是 my.cnf 只说innodb_buffer_pool_instances = 4??

table_cache = 92

也许你的 cmets 搞砸了？ table_open_cache 为 500 会更合理。 （table_cache 是 旧 名称。）

这可能是问题所在：

query_cache_size = 128M

每当发生写入时，所涉及表的 QC 中的所有条目都会从 QC 中清除。建议不超过50M。或者，更好的是，完全关闭 QC。

您已打开慢速日志。 pt-query-digest 说的前几个查询是什么？ （这可能是您解决问题的最佳方式。）