Кластерные серверы MariaDB Galera работают на 100% ЦП, и нагрузка растет

У меня есть приложение Drupal, которое работает на одном сервере базы данных MySQL в течение 12 месяцев и работает относительно хорошо (не считая событий пиковой нагрузки). Нам нужно было иметь возможность поддерживать гораздо более высокие пики, чем позволяет текущий сервер БД, а при 32 ГБ не было большого выигрыша от простого вертикального масштабирования одного сервера БД.

Мы решили создать новый кластер MariaDB Galera с двумя экземплярами по 32 ГБ. Мы максимально согласовали конфигурацию с сервером БД, который скоро будет устаревшим.

После перехода на новые серверы баз данных мы заметили, что загрузка ЦП на этих экземплярах постоянно составляла 100%, а нагрузка неуклонно возрастала. В течение 1 часа средняя нагрузка изменилась с 0,1 до 150.

Первоначально мы думали, что это может иметь какое-то отношение к синхронизации между серверами, но даже если один сервер отключен и синхронизация не происходит, он все еще загружает ЦП до тех пор, пока веб-приложение делает запросы к нему.

После долгих экспериментов я обнаружил, что сокращение некоторых параметров конфигурации сильно повлияло на использование и нагрузку процессора. После внесения следующих изменений средняя нагрузка стабилизировалась между 4 и 6 в обоих случаях.

Использование ЦП и средняя нагрузка

Вопросы

  • Каковы возможные причины такой резкой разницы в использовании ЦП между старым и новым серверами, несмотря на существенный перенос конфигурации со старого сервера?
  • В настоящее время нагрузка колеблется между 4 и 6 (и это период низкой посещаемости для нашего сайта). На что я должен обратить внимание, чтобы попытаться уменьшить это значение и убедиться, что, когда на сайт попадет реальный трафик, он не упадет?

Изменения конфигурации

innodb_buffer_pool_instances

  • Исходное значение: 500 (всего 498 таблиц во всех базах данных).
  • Новое значение: 92

table_cache

  • Исходное значение: 8
  • Новое значение: 4

max_connections

  • Исходное значение: 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

person nicksanta    schedule 13.03.2015    source источник


Ответы (2)


В конце концов, мы попросили консультанта Percona помочь с этой проблемой. Основная проблема, которую они определили, заключалась в том, что выполнялось большое количество запросов EXPLAIN. Оказалось, что это был какой-то отладочный код, который был оставлен включенным (ведение журнала запросов devel.module для разработчиков drupal). Отключение этого параметра привело к резкому снижению загрузки ЦП.

Угадайте, во сколько мы отключили запросы EXPLAIN?

Они рекомендовали нам внедрить ряд дополнительных исправлений.

  • Добавьте в кластер третий узел, который будет действовать как наблюдатель и поддерживать целостность кластера.
  • Добавьте первичные ключи к таблицам, у которых их нет.
  • Измените таблицы MyISAM на InnoDB.
  • Измените wsrep_sst_method с rsync на xtrabackup-v2.
  • Установите innodb_log_file_size на 512M.
  • Установите innodb_flush_log_at_trx_commit на 2, поскольку кластер поддерживает целостность данных.

Надеюсь, эта информация поможет всем, кто сталкивается с подобными проблемами.

person nicksanta    schedule 14.03.2015

innodb_buffer_pool_instances не должен зависеть от количества таблиц. В руководстве рекомендуется, чтобы размер каждого экземпляра не превышал 1 ГБ. Итак, я полагаю, что даже 92 - это слишком много. Но my.cnf говорит только innodb_buffer_pool_instances = 4 ??

table_cache = 92

Может ваши комментарии запутались? 500 будет более разумным для table_open_cache. (table_cache - это старое имя.)

Это может быть проблема:

query_cache_size = 128 МБ

Каждый раз, когда происходит запись, все записи в QC для задействованных таблиц удаляются из QC. Рекомендую не более 50 м. Или, еще лучше, полностью выключите QC.

У вас включен медленный журнал. Что, по словам pt-query-digest, является парой самых популярных запросов? (Это может быть вашим лучшим способом справиться с проблемой.)

person Rick James    schedule 14.03.2015
comment
Да, вы правы в обоих этих пунктах. Инженер Percona также рекомендовал отключить QC, и table_open_cache - правильное имя этой конфигурации. - person nicksanta; 14.03.2015