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

MySQL Replication Performance

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

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

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

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

Всеми таблицами является InnoDB и основной DB, и ведомые Записи между 3.5K - 2.5K qps, пока Чтения на ведущем устройстве о 7.5k - 10k qps.

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

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

Наша проблема с загрузкой ЦП, особенно CPU Sys. Как Вы видите от 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 x 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/

У нас есть тонна истории с Новым Пережитком, но к сожалению я не могу вставить в снимках экрана здесь.

Я прошел бесчисленные блоги и Q&As как это, но не могу найти причину, ни решение так помещает его там.. Какие-либо идеи?

ОБНОВЛЕНИЕ

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