Найкращі параметри кешу MySQL для 8Gb оперативної пам’яті, призначеного для MySQL-сервера, використовуючи лише 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

Тоді я побачив би, як все йде, і спробував би різні речі на основі (серед іншого) результатів згаданих вище інструментів. Я б також переконався в графіці тенденцій за допомогою інструменту моніторингу, такого як Мунін або Кактуси , щоб побачити, з яким навантаженням я справді маю справу. Особисто я маю великий досвід роботи з плагінами MySQL, наданими Муніним.

ІМХО, з яким ви повинні мати можливість піти

innodb_buffer_pool_size=5G

Це було б 62,5% оперативної пам’яті при достатньому обсязі оперативної пам’яті для операційної системи Server плюс пам’яті для з'єднань з БД

@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) дуже низьким (я рекомендую 64М).

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

ОНОВЛЕННЯ 2011-10-15 19:55 EDT

Якщо ви знаєте, що у вас буде 5 Гб даних, тоді моя перша рекомендація була в порядку. Однак я забув додати одне:

[mysqld]
innodb_buffer_pool_size=5G
innodb_log_file_size=1280M

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

ОНОВЛЕННЯ 2011-10-16 13:36 EDT

Правило 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-х файлів журналу, - 2047M, оскільки комбінований розмір файлу журналу повинен бути меншим 4G (4096M)

СЛУЧАЙ В ТОЧКІ: Один із клієнтів мого роботодавця має сервер БД із 192 ГБ оперативної пам'яті. Немає можливості мати файли журналів 48G. Я просто використовую максимальний розмір файлу для файлу журналу innodb, 2047M. @ Коментар Kvisle на мою відповідь просто дає посилання, вказуючи, що вам не потрібно обмежуватись двома файлами журналу. Якщо у вас N файлів журналів, вони не можуть набирати 4G. Моє правило 25% знаходиться просто в ідеальному світі (сервер DB з 8 Гб або менше).