Можно ли заставить 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

Примечание. Самая большая БД является реплицированной с сервера OLTP DR, и из нее загружается DW. Это не полный DW: всего от 6 месяцев до 6 недель, поэтому он меньше, чем OLTP DB.

Наблюдения на тестовом сервере

  • 3 отдельных соединения
  • у каждого есть параллельный (и другой) ALTER TABLE ... DROP KEY ... ADD INDEX
  • 3 таблицы имеют 2,5, 3,8 и 4,5 миллиона строк
  • Использование ЦП достигает 25% (одно ядро ​​максимизировано) и не выше
  • 3 ALTERs занимают 12-25 минут (один на самом маленьком занятии 4,5)

Вопросы

  1. Какие настройки или патч необходимы для использования более одного ядра?
    То есть, почему MySQL не использует все ядра? (как и другие СУБД).
  2. Это следствие репликации?

Другие примечания

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

Изменить 1

  • innodb_thread_concurrency устанавливается равным 8 на обоих. Да, это неправильно, но MySQL не будет использовать несколько ядер.
  • innodb_buffer_pool_size - 80 ГБ на первичной, 10 ГБ на тест (другой экземпляр отключен). Сейчас все в порядке.
  • innodb_file_per_table = ON

Изменить 2

Чтобы проверить

  • innodb_flush_method не отображается как O_DIRECT, когда он должен быть
  • будет следовать настройкам RolandoMySQLDBA

Сообщите мне, если я пропустил что-нибудь важное

Приветствия

Update

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

101 голос | спросил gbn 12 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 12 Sep 2011 18:59:54 +0400 2011, 18:59:54

5 ответов


103

Я фактически обсуждал innodb_thread_concurrency с экспертом MySQL на конференции Percona Live NYC еще в мае 2011 года .

Я узнал что-то удивительное: несмотря на документацию, лучше оставить innodb_thread_concurrency в 0 (бесконечный параллелизм). Таким образом, InnoDB решает наилучшее количество innodb_concurrency_tickets , чтобы открыть для данной установки экземпляра MySQL.

После того, как вы установили innodb_thread_concurrency в 0, вы можете установить innodb_read_io_threads и innodb_write_io_threads (оба начиная с MySQL 5.1.38) до максимального значения 64. Это должно включать больше ядер.

ответил RolandoMySQLDBA 12 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 12 Sep 2011 19:35:21 +0400 2011, 19:35:21
24

MySQL будет автоматически использовать несколько ядер, поэтому либо ваша нагрузка 25% будет совпадением 1 , либо потенциальной неправильной конфигурацией на Solaris. Я не буду притворяться, что знаю, как настраивать солярис, но вот статья, в которой описывается информация о настройке солярия .

Настраиваемые страницы InnoDB прошли капитальный ремонт в MySQL 5.5, поэтому есть и хорошая информация. Из подсказок IO для дисководов InnoDB :

  

Если верхний инструмент Unix или диспетчер задач Windows показывает, что процент использования процессора с рабочей нагрузкой составляет менее 70%, ваша рабочая нагрузка, вероятно, связана с диском. Возможно, вы делаете слишком много транзакционных коммитов, или буферный пул слишком мал. Создание пула буферов больше может помочь, но не устанавливает его равным до более 80% физической памяти.

Некоторые другие вещи для проверки:

  • Переключение innodb_flush_method на O_DIRECT стоит проверить , Если это поможет, возможно, вам потребуется подключить файловую систему с помощью опции принудительное перенаправление

  • Измените innodb_flush_log_at_trx_commit от 1 до 0 ( если вы не против потери последней секунды при сбое mysql) или 2 (если вы не против потери последней секунды при сбое ОС).

  • Проверьте значение innodb_use_sys_malloc . В этой статье дополнительной информации о переменной.

      

    В то время не было библиотек-распределителей памяти, настроенных для многоядерных процессоров. Таким образом, InnoDB реализовал свой собственный распределитель памяти в подсистеме памяти. Этот распределитель охраняется одним мьютеком, который может стать узким местом.

    Но в конце раздела есть некоторые оговорки о том, что значит включить переменную (по умолчанию она включена в 5.5).

      

    Обратите внимание, что когда распределитель памяти InnoDB отключен, InnoDB игнорирует значение параметра innodb_additional_mem_pool_size.

  • Возможно, что репликация вызывает некоторые проблемы. Я понимаю, что вас не интересует параллелизм, но из описания этого рабочего журнала :

      

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

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

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

ответил Derek Downey 12 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 12 Sep 2011 19:21:06 +0400 2011, 19:21:06
12

В одном соединении будет использоваться только одно ядро. (ОК, InnoDB использует другие потоки, следовательно, ядра для некоторой обработки ввода-вывода, но это не имеет значения.)

У вас было 3 ALTERs, поэтому вы не использовали гораздо больше, чем 3 основных достоинства.

Увы, даже PARTITION не использует несколько ядер.

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

ответил Rick James 18 Mayam12 2012, 03:23:39
6

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

ответил jfg956 8 Mayam15 2015, 08:31:47
4

Учтите, что ваше узкое место может быть производительностью IO вашей файловой системы. В дополнение к настройкам, предложенным @RolandoMySQLDBA, я также устанавливаю параметры монтирования noatime в /etc /fstab для раздела, содержащего мой каталог данных mysql (/data01 /mysql в моем случае с /dev /sdb1, установленным на /data01).

По умолчанию linux записывает время доступа для чтения или записи КАЖДОГО диска, что отрицательно влияет на производительность ввода-вывода, особенно для приложений с высоким IO, таких как базы данных. Это означает, что даже чтение данных из файла вызывает запись на диск ... WAT!

Чтобы отключить это, добавьте параметр монтирования noatime в /etc /fstab для нужной точки монтирования следующим образом (пример в моем случае):

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

Затем перемонтируйте раздел:

mount -o, remount /data01

Это должно повысить производительность чтения /записи приложений с использованием этого раздела. НО ... ничего не бьет все ваши данные в памяти.

ответил OkezieE 23 PM00000090000003631 2016, 21:09:36

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132