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

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

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

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

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

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

Все таблицы - InnoDB, основная DB и ведомая запись выполняются в диапазоне от 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

Ранее база данных master работала на виртуализированном сервере (тот же кластер 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, но, к сожалению, я не могу вставить скриншоты здесь.

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

ОБНОВИТЬ

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