Лучшие настройки кэша MySQL для выделенного сервера MySQL объемом 8 ГБ ОЗУ, использующего только InnoDB (база данных 5 ГБ)

Я довольно большой нуб, когда дело доходит до настройки MySQL для повышения производительности. И, честно говоря, я не беспокоюсь о тонкой настройке, чтобы выжать из MySQL каждый последний бит производительности, но я знаю, что самое важное, что дает один из лучших результатов, - это правильная настройка кэшей / буферов.

Я пытался упростить задачу, используя только InnoDB в качестве механизма хранения. И у меня есть выделенный сервер для MySQL. Он имеет 8 ГБ оперативной памяти, как я должен распределить это, чтобы максимизировать производительность? Я хотел бы иметь возможность поместить всю мою базу данных в память для лучшей производительности. База данных составляет около 5 ГБ. Это возможно?

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

Поскольку я не использую MyISAM, мне не нужно правильно помещать много памяти в кеш ключей?

Это трудно, не зная много о самой базе данных. Есть несколько инструментов, о которых вы должны знать;

• http://mysqltuner.pl/
• MySQL Tuning Primer

О хранении всей базы данных в памяти; Любые запросы, которые вносят изменения в базу данных, будут оставаться открытыми до тех пор, пока не будет выполнена запись на диск. Единственное, что может сделать диск узким местом, это дисковый контроллер с кэшем записи.

Я бы начал со следующих изменений по умолчанию:

key_buffer_size = 128M
thread_stack = 128K
thread_cache_size = 8
table_cache = 8192
max_heap_table_size = 256M
query_cache_limit = 4M
query_cache_size = 512M

innodb_buffer_pool_size = 4G 

# This is crucial to avoid checkpointing all the time:
innodb_log_file_size = 512M

# If you have control on who consumes the DB, and you don't use hostnames when you've set up permissions - this can help as well.
skip_name_resolve

Затем я посмотрю, как идут дела, и попробую разные вещи, основываясь (помимо прочего) на результатах инструментов, упомянутых выше. Я также хотел бы проследить тенденции с помощью инструмента мониторинга, такого как Munin или Cacti , чтобы увидеть, с какой рабочей нагрузкой я на самом деле имею дело. Лично у меня большой опыт работы с плагинами MySQL, поставляемыми с Munin.

ИМХО ты должен быть в состоянии пойти с

innodb_buffer_pool_size=5G

Это будет 62,5% ОЗУ с достаточным объемом ОЗУ для серверной ОС плюс память для соединений с БД

@kvisle рекомендуется использовать mysqltuner.pl. Этот сценарий отлично подходит для оценки объема ОЗУ, выделяемого для join_buffer_size, sort_buffer_size, read_buffer_size и read_rnd_buffer_size. Эти 4 буфера, добавленные вместе, умножаются на max_connections. Этот ответ добавляется в статические буферы (innodb_buffer_pool_size + key_buffer_size). Объединенные суммы сообщаются. Если эта объединенная сумма превышает 80% ОЗУ, тогда вы должны уменьшить размер буфера. mysqltuner.pl будет очень полезен в этом отношении.

Поскольку все ваши данные - это InnoDB, вы можете сделать key_buffer_size (буфер кэширования ключей для индексов MyISAM) очень низким (я рекомендую 64M).

Вот пост, который я сделал в DBA StackExchange, чтобы вычислить рекомендуемый размер innodb_buffer_pool_size .

ОБНОВЛЕНИЕ 2011-10-15 19:55 ПО ВОСТОЧНОМУ ВРЕМЕНИ

Если вы знаете, что у вас будет 5 ГБ данных, тогда моя первая рекомендация была в порядке. Однако я забыл добавить одну вещь:

[mysqld]
innodb_buffer_pool_size=5G
innodb_log_file_size=1280M

Размер файла журнала должен составлять 25% от пула буферов InnoDB

ОБНОВЛЕНИЕ 2011-10-16 13:36 ПО ВОСТОЧНОМУ ВРЕМЕНИ

Правило 25% основано исключительно на использовании двух файлов журнала. Хотя можно использовать несколько файлов журнала innodb, два обычно работают лучше всего.

Другие выразили, используя 25%

• http://lists.mysql.com/mysql/203879
• http://teaching-2.cs.uml.edu/MySQLdocs/MySQL_Manual/InnoDB_start.html
• http://www.issociate.de/board/post/395589/innodb_buffer_pool_size._How_to_setup_with_more_than_5G_?.html

Однако, честно говоря, кто-то из оригинальной компании InnoBase Oy заявил, что не использует правило 25% из-за наличия большего пула буферов InnoDB .

Естественно, правило 25% не может работать при наличии большого количества оперативной памяти. На самом деле самый большой размер innodb_log_file_size, разрешенный для использования только 2 файлов журнала, составляет 2047 МБ, поскольку объединенный размер файла журнала должен быть менее 4 ГБ (4096 МБ).

ПРИМЕР: Один из клиентов моего работодателя имеет сервер БД с 192 ГБ ОЗУ. Нет никакого способа иметь 48G лог-файлы. Я просто использую максимальный размер файла журнала innodb, 2047M. @ Kvisle в комментарии к моему ответу просто дает ссылку, указывающую, что вам не нужно ограничивать себя двумя файлами журнала. Если у вас есть N файлов журнала, они не могут составлять 4G. Мое правило 25% просто в идеальном мире (сервер БД с 8 ГБ или меньше).