Я только что закончил читать эти старые вопросы и ответы, в которых была действительно хорошая подробная информация о настройке, аналогичной нашей, хотя, к сожалению, наша проблема (сейчас) не в репликации.

Производительность репликации MySQL

У нас есть новый главный сервер базы данных (Версия сервера: 5.5.27-log MySQL Community Server), который находится на голом железном сервере со следующими характеристиками:

• 2 порта Intel E5-2620-v2
• 64 ГБ памяти
• 2 карты Fusion-io 600 ГБ (Raid 1) для MySql
• 1 x SSD для Centos 6.5
• Сеть 1 Гбит / с

HyperThreading не был отключен на сервере, поскольку существуют смешанные мнения о том, помогает ли это в системах с большой памятью, но мы не против того, чтобы попробовать это.

В настоящее время мы выполняем репликацию на 3 ведомых устройства, виртуализированных в кластере SSD. Мы выполняли репликацию до 4, но это казалось слишком большим для SSD-кластера, и у нас были периоды задержки.

Все таблицы - это InnoDB и главная БД и подчиненная Пишет находятся между 3,5–2,5 тыс. Кадров в секунду, пока Читает на мастере о 7,5–10 тыс. Запросов в секунду.

Настройки для главной БД следующие:

long-query-time=10
slow-query-log

max_connections=500
max_tmp_tables=1024

key_buffer = 1024M
max_allowed_packet = 32M

net_read_timeout=180
net_write_timeout=180

table_cache = 512

thread_cache = 32
thread_concurrency = 4 

query_cache_type = 0 
query_cache_size = 0M 

innodb_file_per_table
innodb_file_format=barracuda

innodb_buffer_pool_size=49152M
innodb_buffer_pool_instances=2
innodb_read_io_threads=16
innodb_write_io_threads=16
innodb_io_capacity = 500

innodb_additional_mem_pool_size=20M
innodb_log_file_size=1024M
innodb_log_files_in_group = 2

innodb_doublewrite=0
innodb_flush_log_at_trx_commit=2
innodb_flush_method=O_DIRECT

Наша проблема связана с загрузкой процессора, особенно Sys Cpu. Как видно из mpstat, у нас 0% iowait и очень высокий% sys.

Linux 2.6.32-431.29.2.el6.x86_64            13/11/14    _x86_64_    (24 CPU)

13:57:18     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
13:57:19     all   23.35    0.00   74.65    0.00    0.00    0.88    0.00    0.00    1.13
13:57:20     all   21.95    0.00   75.50    0.00    0.00    0.96    0.00    0.00    1.59
13:57:21     all   23.74    0.00   72.63    0.00    0.00    1.00    0.00    0.00    2.63
13:57:22     all   23.88    0.00   71.64    0.00    0.00    1.17    0.00    0.00    3.31
13:57:23     all   23.26    0.00   73.89    0.00    0.00    0.92    0.00    0.00    1.92
13:57:24     all   22.87    0.00   74.87    0.00    0.00    1.00    0.00    0.00    1.25
13:57:25     all   23.41    0.00   74.51    0.00    0.00    0.96    0.00    0.00    1.12

Раньше главная база данных работала на виртуализированном сервере (тот же SSD-кластер, что и подчиненные). У него был отдельный хост в кластере vSphere, в котором были:

• 2 порта Intel X5570
• 32 ГБ памяти
• SSD общий из кластера

Раньше никогда не было никаких проблем, сервер работал без сбоев в течение многих лет, хотя и с меньшей пропускной способностью SQL.

Все запросы просты, а индексы оптимизированы для вставки и обновления, поскольку сложные клиентские запросы выполняются на ведомых устройствах. Нет никаких удалений, только вставки и обновления. Большинство таблиц (все большие) имеют первичные ключи.

Похоже, что загрузка ЦП увеличивается после заполнения буфера памяти, и MySql - единственное приложение, выполняемое на сервере.

Количество подключений варьируется от 200 до 400, из которых около 100-200 подключены. Коэффициент попадания буферного пула Innodb составляет 100%. Память подкачки никогда не создается, поэтому я не вижу, в чем проблема:

http://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/

У нас богатая история с New Relic, но, к сожалению, я не могу вставить сюда скриншоты.

Я просмотрел бесчисленное количество блогов и вопросов и ответов, но не могу найти ни причины, ни решения, поэтому я выкладываю это там .. Есть идеи?

ОБНОВИТЬ

Кажется, теперь я могу выкладывать скриншоты. Эти два захвата из New relic показывают загрузку системы и загрузку запросов на сервере в течение 6-часового окна с перезапуском mysql в середине.