1

単一の MySQL データベース サーバーで 12 か月間実行されている Drupal アプリケーションがあり、(ピーク負荷イベントを除いて) 比較的良好に動作しています。現在の DB サーバーが許容するよりもはるかに高いスパイクをサポートできるようにする必要があり、32 GB では、単一の DB サーバーを単純に垂直方向にスケーリングするだけではあまりメリットがありませんでした。

2 つの 32GB インスタンスを備えた新しい MariaDB Galera クラスターをセットアップすることにしました。間もなく廃止されるDBサーバーと可能な限り構成を一致させました。

新しいデータベース サーバーに移行した後、これらのインスタンスの CPU 使用率が常に 100% であり、負荷が着実に増加していることに気付きました。1 時間の間に、負荷平均は 0.1 から 150 になりました。

当初はサーバー間の同期に関係があるのではないかと考えていましたが、1 台のサーバーがオフになっていて同期が行われていない場合でも、Web アプリケーションがサーバーにリクエストを送信している限り、CPU を使い果たしていました。

多くの実験の後、いくつかの構成オプションを減らすと、CPU 使用率と負荷に大きな影響があることがわかりました。以下の変更を行った後、負荷平均は両方のインスタンスで 4 ~ 6 の間で安定しました。

CPU 使用率と負荷平均

質問

  • 基本的に古いサーバーから構成を移行しているにもかかわらず、古いサーバーと新しいサーバーの間で CPU 使用率が劇的に異なる理由として考えられるものは何ですか?
  • 現在、負荷は 4 ~ 6 の間で推移しています (これは、Web サイトのトラフィックが少ない期間です)。この値を減らして、サイトが実際のトラフィックに見舞われたときにフォールオーバーしないようにするには、何を確認する必要がありますか?

構成の変更

innodb_buffer_pool_instances

  • 元の値: 500 (すべてのデータベースで合計 498 のテーブルがあります)
  • 新しい値: 92

table_cache

  • 元の値: 8
  • 新しい値: 4

最大接続数

  • 元の値: 1000
  • 新しい値: 400

現在の構成

これは、サーバーの1つからの完全な構成ファイルです/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 クエリを無効にしたのはいつだと思いますか?

彼らが私たちが実装することを推奨した追加の修正がいくつかありました.

  • クラスターに 3 つ目のノードを追加して、オブザーバーとして機能し、クラスターの整合性を維持します。
  • 主キーを持たないテーブルに主キーを追加します。
  • 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 に答える