Много месяцев назад, когда MySql 5.5 все еще находился в стадии бета-тестирования, этот вопрос задавали раньше. Теперь, когда он был выпущен и есть несколько обновлений для обслуживания, что вы все думаете?
Re: проблемы с innodb_buffer_pool_size и innodb_buffer_pool_instances:
Я думаю, что есть несоответствие между этими переменными. innodb_buffer_pool_size - это общее количество буферный пул доступен. Затем он делится между количеством потоков, указанных в innodb_buffer_pool_instances.
В приведенном выше примере с низкой производительностью 2,5 ГБ было разделено между 64 экземплярами, что оставляет 40 МБ на каждый экземпляр. Рекомендуемый минимальный размер (если вы используете эти параметры) составляет 1 ГБ на экземпляр. Я мог полностью понять, как 40 МБ на экземпляр привели бы к снижению производительности.
В нашей производственной среде мы запускаем серверы с 3 экземплярами, пулом 3 ГБ, по 1 ГБ на экземпляр, без чрезмерного разбиения на страницы. Мы также запускаем 4 экземпляра, пул 10 ГБ, также без чрезмерной подкачки (более новое оборудование, почему бы не воспользоваться этой памятью).
Надеюсь, это поможет.
ПРОБЛЕМА №1) Полусинхронная репликация
Мастер с несколькими подчиненными не так уж хорош, потому что только первое подчиненное устройство будет быстро реплицироваться, а все последующие подчиненные устройства иногда переключаются в асинхронный режим в зависимости от того, сколько времени требуется для выполнения запроса. Что касается первого раба, то это задумано. Я предполагаю, что нет никаких гарантий, что последующие подчиненные будут работать своевременно.
С другой стороны, простой мастер-подчиненный, круговое повторение и мультимастерское повторение работают быстро, IMHO.
ПРОБЛЕМА # 2) Несколько пулов буферов InnoDB
У меня есть клиент с 3 серверами БД, настроенными следующим образом:
Dual HexaCore (12 процессоров)
192 ГБ RAM
2 ТБ SAS RAID10
Клиент имеет 480 ГБ данных, распределенных по 780 базам данных.
Циклическая репликация выполняется между тремя серверами БД.
Определенно, одна из самых мощных функций, которые я активировал для InnoDB, заключается в следующем:
innodb_read_io_threads = 64
innodb_write_io_threads = 64
innodb_io_capacity = 65536
innodb_buffer_pool_instances = 1
(по умолчанию) innodb_bufer_pool_size = 162G
MySQL 5.5 работает как мечта для этого клиента. Все данные клиента практически кэшируются в памяти. Все 12 процессоров полностью задействованы из-за большой активности InnoDB. Все быстро динамит. Грязные страницы InnoDB для пула буферов настолько малы и выгружаются так быстро.
Сначала я попытался настроить буферный пул таким образом (160 ГБ)
innodb_buffer_pool_instances = 64 (максимальное значение)
innodb_buffer_pool_size = 2560 МБ (2,5 ГБ)
Это создало множество блокировок потоков. Я подозреваю, что это связано с кешированием связанных данных в разных пулах буферов. Попытка получить доступ к этим сегментам данных привела к некоторому исключению между пулами буферов. Коллега по моей работе (который является сертифицированным мастером Oracle) сказал мне, что у Oracle есть аналогичная инфраструктура, которую вы можете использовать, и блокировка потоков также является проблемой, поэтому они не продают ее использование.
Все проблемы с блокировкой клиентского потока полностью исчезли, когда я установил следующее:
innodb_buffer_pool_instances = 1
(по умолчанию) innodb_bufer_pool_size = 162G
Мое заключение о нескольких буферных пулах InnoDB
Я очень хотел воспользоваться этой функцией, но разочаровался. Наличие нескольких пулов буферов не принесет вам многого, если у вас есть большие наборы данных, которые связаны, но распределены по пулам буферов, что приводит к усилению блокировки потоков. Я бы хотел, чтобы вы могли назначать данные конкретным пулам буферов, как если бы вы предварительно загружали кеши ключей MyISAM. Только тогда несколько пулов буферов будут очень удобны.
Если у вас очень маленькие базы данных клиентов, но их много, можно использовать несколько пулов буферов. По-прежнему будут проблемы с блокировкой потоков, но не такие серьезные.
IMHO Я бы не стал использовать несколько буферных пулов для больших установок. Гигантский буферный пул с большим количеством потоков работает более эффективно. Я бы определенно сосредоточился на использовании большего количества потоков innodb и задействовании большего количества процессоров, что является явным преимуществом по сравнению с MySQL 5.0 / 5.1.