2015-03-13 50 views
0

我有一个Drupal应用程序,它已经在单个MySQL数据库服务器上运行了12个月,并且性能相对较好(除峰值负载事件外)。我们需要能够支持比当前的数据库服务器更高的峰值,而在32GB的情况下,从简单的垂直扩展单个数据库服务器就没有多少收获。MariaDB Galera集群服务器以100%CPU和负载上升运行

我们决定设置一个具有2x 32GB实例的新MariaDB Galera集群。我们尽可能将配置与即将成为obselete的数据库服务器进行匹配。

迁移到新数据库服务器后,我们注意到这些实例的CPU使用率始终保持在100%,并且负载稳步增加。在1小时的过程中,平均负载从0.1到150.

最初我们认为它可能与服务器之间的同步有关,但即使关闭了1台服务器,也没有发生同步,它仍然是最大的只要Web应用程序向它发出请求就可以使用CPU。

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

CPU utilisation & Load average

的问题

  • 哪些是在新老服务器之间的CPU使用率如此巨大差异的一些可能的原因,尽管本质上从旧服务器迁移的配置?
  • 负载目前在4到6之间徘徊(这对我们的网站来说是一个低流量期)。我应该考虑怎样降低这个价值,并确保当这个网站被一些真正的流量所击中时,它不会崩溃?

配置改变

innodb_buffer_pool_instances

  • 原始值:(有498个表总量中的所有数据库)
  • 新值:

table_cache

  • 原始值:
  • 新值:

MAX_CONNECTIONS

  • 原始值:
  • 新值:

当前配置

下面是从服务器/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 

回答

1

innodb_buffer_pool_instances不应表的数量的函数的一个完整的配置文件。手册提倡每个实例不小于1GB。所以,我建议92甚至太高。但my.cnf只说innodb_buffer_pool_instances = 4 ??

的table_cache = 92

也许你的意见是搞砸了? 500将更合理table_open_cache。 (table_cache名称。)

这可能是问题:

query_cache_size变量= 128M

每当在写操作发生,所有条目在QC为表(s)被从QC中清除。建议不要超过50M。或者,更好的是,完全关闭QC。

您打开缓慢日志。 pt-query-digest说什么是顶级的几个查询? (这个可能是是你解决问题的最好方法。)

+0

是的,你在这两点上都是正确的。 Percona工程师还建议我们禁用QC,而table_open_cache是​​该配置的正确名称。 – nicksanta 2015-03-14 06:08:27

1

我们最终得到了一个Percona顾问来帮助解决这个问题。他们发现的主要问题是正在执行大量的EXPLAIN查询。原来这是一些调试代码,它被启用(devel。模块查询记录drupal devs)。禁用此功能会导致CPU使用率下降。

Guess what time we disabled the EXPLAIN queries?

有一定数量的,他们建议我们实行的其他修复。

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

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

相关问题