Чи можливо змусити MySQL використовувати більше одного ядра?

Мені були представлені деякі виділені сервери MySQL, які ніколи не використовують більше одного ядра. Я більше розробник, ніж DBA для MySQL, тому мені потрібна допомога

Налаштування

Сервери досить здорово з завантаженням типу OLAP / DataWarehouse (DW):

• Основне: 96 ГБ оперативної пам’яті, 8 ядер + один масив RAID 10
• Тест: 32 ГБ оперативної пам’яті з 4 ядрами
• Найбільша база даних - 540 ГБ, загальна сума - близько 1,1 ТБ та переважно таблиці InnoDB
• Solaris 10 Intel-64
• MySQL 5.5.x

Примітка: Найбільша БД - це реплікувана з DRTP-сервера OLTP, і DW завантажується з цього. Це не повний DW: останні останні 6 місяців до 6 тижнів, тому він менший, ніж OLTP DB.

Спостереження на тестовому сервері

• 3 окремих з'єднання
• кожен має одночасний (і різний) ALTER TABLE...DROP KEY...ADD INDEX
• 3 таблиці мають 2,5, 3,8 та 4,5 мільйона рядків
• Використання процесора збільшується до 25% (одне ядро ​​заміряється) і не вище
• 3 ALTER займають 12-25 хвилин (один на найменший займає 4,5)

Запитання

1. Які налаштування або виправлення потрібні для використання декількох ядер?
   Тобто, чому MySQL не використовує всі наявні ядра? (як і інші RDBMS)
2. Це наслідок реплікації?

Інші примітки

• Я розумію різницю між "потоком" RDBMS та "потоком" ОС "
• Я не запитую про будь-яку форму паралелізму
• Деякі системні змінні для InnoDB і потоків є неоптимальними
  (шукають швидкого виграшу)
• За короткий термін я не можу змінити макет диска
• ОС можна налаштувати за потреби
• Один ALTER TABLE на найменшому столі займає 4,5 хвилини (шокуюче IMO)

Редагуйте 1

• innodb_thread_concurrency встановлено на 8 обох. Так, це неправильно, але не змусить MySQL використовувати декілька ядер
• innodb_buffer_pool_size 80GB на первинному, 10GB на тестовому (інший екземпляр закрито). На сьогодні це нормально.
• innodb_file_per_table = УВІМКНЕНО

Редагуйте 2

• innodb_flush_log_at_trx_commit = 2
• innodb_use_sys_malloc = УВІМКНЕНО
• innodb_flush_method має бути O_DIRECT (але SHOW VARIABLES не показує цього)
• innodb_doublewrite = ВИКЛ
• Файлова система = ZFS (І мій sysadmin знайшов це: http://blogs.oracle.com/realneel/entry/mysql_innodb_zfs_best_practices )

Перевіряти

• innodb_flush_method не відображається як O_DIRECT, коли це має бути
• буде дотримуватися налаштувань RolandoMySQLDBA

Дайте мені знати, якщо я пропустив щось важливе

Ура

Оновлення

Змінено innodb_flush_method + 3 x налаштування потоку у відповіді RolandoMySQLDBA
Результат:> 1 ядро, використане для тестів = позитивний результат

Я фактично обговорював innodb_thread_concurrency з експертом MySQL на конференції Percona Live NYC ще в травні 2011 року .

Я дізнався щось дивовижне: незважаючи на документацію, найкраще залишити innodb_thread_concurrency0 (нескінченна паралельність). Таким чином, InnoDB визначає найкращу кількість innodb_concurrency_ticketsдля відкриття для заданої установки екземпляра MySQL.

Як тільки ви встановите innodb_thread_concurrency0, ви можете встановити innodb_read_io_threadsі innodb_write_io_threads(обидва з MySQL 5.1.38) максимальне значення 64. Це повинно залучати більше ядер.

MySQL автоматично використовуватиме декілька ядер, тому або завантаження 25% - це збіг ^1, або потенційна неправильна конфігурація на Solaris. Я не буду робити вигляд, що знаю, як налаштувати сонячні батареї, але ось стаття, яка описує певну інформацію про налаштування, що стосується сонячних батарей .

На сторінках настройки InnoDB було проведено капітальний ремонт у MySQL 5.5, тому тут є і хороша інформація. З порад IO диска InnoDB :

Якщо верхній інструмент Unix або диспетчер завдань Windows показує, що відсоток використання процесора з вашим навантаженням менше 70%, навантаження, ймовірно, пов'язана з диском. Можливо, ви робите занадто багато трансакцій, або буферний пул занадто малий. Збільшення пулу буфера може допомогти, але не встановлюйте його більше 80% фізичної пам'яті.

Ще деякі речі для перевірки:

• Переключення методу innodb_flush_mode на O_DIRECT варто перевірити. Якщо це допоможе, можливо, вам доведеться встановити файлову систему з forcedirectioопцією

• Змініть innodb_flush_log_at_trx_commit з 1 на 0 (якщо ви не заперечуєте втратити останню секунду під час аварії mysql) або 2 (якщо ви не проти втратити останню секунду при аварії ОС).

• Перевірте значення innodb_use_sys_malloc . У цій статті є додаткова інформація про змінну.

  На той час не було бібліотек розподільчої пам'яті, налаштованих на багатоядерні процесори. Тому InnoDB реалізував власний розподільник пам'яті в підсистемі mem. Цей розподільник захищений єдиним мутексним кодом, який може стати вузьким місцем.

  Але в кінці розділу є деякі застереження про те, що означає включити змінну (вона за замовчуванням у 5.5).

  Зауважте, що коли розподільник пам'яті InnoDB відключений, InnoDB ігнорує значення параметра innodb_additional_mem_pool_size.

• Можливо, що тиражування викликає певну проблему. Я розумію, що вас цікавить не паралелізм, а опис цього робочого журналу :

  В даний час реплікація не набирає масштабів на багатоядерних машинах. Один потійний підпорядкований потік виконує події реплікації по черзі і може не справлятися з навантаженням, створюваним одночасно декількома клієнтськими з'єднаннями, що обслуговуються центральним процесором головного сервера.

Зрештою, InnoDB може бути не найкращим двигуном для зберігання даних, через операції на основі диска. Ви можете розглянути можливість зміни таблиці (таблиць) сховищ даних для стиснення MyISAM .

¹ _{За збігом обставин, я маю на увазі, що існує вузьке місце, яке не дозволяє вашому навантаженню збільшитися вище 25%, але це не обов'язково є вимушеною одноядерною проблемою.}

Для одного з'єднання буде використовуватися лише одне ядро. (Гаразд, InnoDB використовує інші потоки, отже, ядра для деякої обробки вводу / виводу, але це не суттєво.)

У вас було 3 АЛЬТЕРИ, тож ви не використовували більше 3-х ядерних цінностей.

На жаль, навіть PARTITION не використовує декілька ядер.

До недавнього часу кілька з'єднань не перевищували б 4-8 ядер. Xtradb Percona (включений до MariaDB) дозволяє краще використовувати декілька ядер, але все одно лише одне на нитку. Максимум вони становлять приблизно 32 ядра.

IMHO і в описаному випадку використання ви ніколи не будете використовувати більше одного ядра. Причина полягає в тому, що ваше навантаження пов'язане з IO, а не з процесором. Оскільки ваші 3 з'єднання створюють новий індекс, кожен з них повинен прочитати всю таблицю з диска: саме на це потрібно час, а не обчислення індексів.

Подумайте, що вашим вузьким місцем може бути продуктивність вводу-виводу вашої файлової системи.

На додаток до параметрів, запропонованих @RolandoMySQLDBA , я також встановив параметри noatimeкріплення /etc/fstabдля розділу, що містить мій каталог даних mysql ( /data01/mysqlу моєму випадку, із /dev/sdb1встановленим /data01).

За замовчуванням Linux записує час доступу для ВСЕГО читання чи запису диска, що негативно впливає на продуктивність вводу-виводу, особливо для додатків із високим рівнем вводу-виводу, таких як бази даних. Це означає, що навіть зчитування даних з файлу запускає запис на диск ... WAT!

Щоб вимкнути це, додайте параметр noatimeкріплення /etc/fstabдля потрібної точки монтажу наступним чином (наприклад, у моєму випадку):

/dev/sdb1  /data01  ext4  defaults,noatime  0  2

Потім знову встановіть розділ:

mount -o,remount /data01

Це повинно підвищити ефективність читання / запису програм, що використовують цей розділ. АЛЕ ... нічого не б'ється, зберігаючи всі ваші дані в пам'яті.