Mysql MariaDB Galera群集服务器以100%的CPU运行，负载不断增加

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

我们决定建立一个新的MariaDB Galera集群，它有2个32GB的实例。我们尽可能地将配置与即将推出的obselete DB服务器相匹配

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

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

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

问题

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

配置更改 innodb\u缓冲区\u池\u实例

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

表2\u缓存

• 原始值：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

---

innodb_buffer_pool_实例不应是表数的函数。手册提倡每个实例不小于1GB。所以，我认为即使92也太高了。但是my.cnf只说

innodb\u buffer\u pool\u instances=4

表_cache=92

也许你的评论搞乱了？500对于表\u open\u缓存来说更合理。（

table_cache

是旧名称。）

这可能就是问题所在：

查询\u缓存\u大小=128M

无论何时发生写入，都会从QC中清除所涉及表格的QC中的所有条目。建议不超过50米。或者，更好的办法是完全关闭QC

---

你已经打开了slowlog。pt query digest说最重要的两个查询是什么？（这可能是你处理这个问题的最好方法。）

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

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

• 将第三个节点添加到集群以充当观察者并维护集群的完整性
• 向没有主键的表添加主键
• 将MyISAM表更改为InnoDB
• 将wsrep_sst_方法从rsync更改为xtrabackup-v2
• 将innodb_日志_文件_大小设置为512M
• 将innodb_flush_log_at_trx_commit设置为2，因为集群保持数据的完整性

---

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

是的，您在这两个方面都是正确的。percona工程师还建议我们禁用QC，table_open_cache是该配置的正确名称。