1

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

我们决定建立一个具有 2 个 32GB 实例的新 MariaDB Galera 集群。我们尽可能将配置与即将过时的数据库服务器匹配。

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

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

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

CPU 利用率和平均负载

问题

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

配置更改

innodb_buffer_pool_instances

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

表缓存

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

2 回答 2

2

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

猜猜我们什么时候禁用 EXPLAIN 查询？

他们建议我们实施许多其他修复。

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

我希望这些信息可以帮助遇到类似问题的任何人。

于 2015-03-14T06:06:57.017 回答
1

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

表缓存 = 92

也许你的评论搞砸了？500 对于table_open_cache会更合理。（table_cache是旧名称。）

这可能是问题所在：

query_cache_size = 128M

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

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

于 2015-03-14T00:34:33.257 回答