Таблица InnoDB с высокой вставкой не будет использовать весь мой процессор

У меня есть база данных журнала пакетов, которая почти никогда не запрашивается. Это просто должно быть быстро на вставках. Я использую InnoDB, потому что хотел бы поддерживать соответствие ACID, поскольку даже потеря одного пакета может нанести ущерб нашим клиентам. В сценарии настройки производительности я отправляю 1 000 000 пакетов на сервер через несколько подключений к БД. Но независимо от того, какие настройки я использую в my.cnf, я не могу заставить процесс mysqld использовать более 900% ЦП в системе с 12 ядрами. (На коробке больше ничего не работает.)

Я установил следующее

innodb_file_per_table = 1
innodb_write_io_threads = 64
innodb_read_io_threads = 64
innodb_thread_concurrency = 0

Если я использую MyISAM, я могу получить все записанные пакеты за 6 секунд. Но InnoDB занимает около 25. Могу ли я заставить MySQL использовать оставшиеся системные ресурсы и вставлять быстрее?

Изменить: вот схема для таблицы:

+-------+----------------------+------+-----+---------+-------+
| Field | Type                 | Null | Key | Default | Extra |
+-------+----------------------+------+-----+---------+-------+
| t     | bigint(20) unsigned  | YES  |     | NULL    |       |
| a     | char(1)              | YES  |     | NULL    |       |
| sa    | int(10) unsigned     | YES  |     | NULL    |       |
| sb    | int(10) unsigned     | YES  |     | NULL    |       |
| sc    | int(10) unsigned     | YES  |     | NULL    |       |
| sd    | int(10) unsigned     | YES  |     | NULL    |       |
| sp    | smallint(5) unsigned | YES  |     | NULL    |       |
| da    | int(10) unsigned     | YES  |     | NULL    |       |
| db    | int(10) unsigned     | YES  |     | NULL    |       |
| dc    | int(10) unsigned     | YES  |     | NULL    |       |
| dd    | int(10) unsigned     | YES  |     | NULL    |       |
| dp    | smallint(5) unsigned | YES  |     | NULL    |       |
+-------+----------------------+------+-----+---------+-------+

edit2: я упаковал больше вставок вместе, чтобы один запрос был близок к максимальной длине (около 16 000 000 символов). Теперь база данных увеличивается до 1100% в течение двух секунд, а затем снижается до 100% в течение остального времени. Общее время теперь составляет 21 секунду, или примерно на 16% быстрее, чем когда я начинал.

— sep332
источник

Ответы:

Вы также должны проверить innodb_io_capacity .

По умолчанию это 200. Увеличьте до 5000 для начинающих. Я бы пошел на 20000.

Вы также можете убедиться ib_logfile0и ib_logfile1достаточно большой. Значение по умолчанию для innodb_log_file_size - 5M. Я бы поднял это до 1G для начинающих.

Также может помочь большой буферный пул InnoDB, возможно, 4G.

Напомним, используйте эти дополнительные настройки:

[mysqld]
innodb_io_capacity=5000
innodb_buffer_pool_size=4G
innodb_log_file_size=1G

После добавления этих настроек в my.cnf, чтобы изменить размер ib_logfile0 / ib_logfile1, сделайте следующее

service mysql stop
rm -f /var/log/mysql/ib_logfile[01]
service mysql start

Файлы ib_logfile0 и ib_logfile1 воссоздаются. Не волнуйся, я делал это много раз .

Возможно, вам придется сделать что-то необычное для InnoDB

Попробуйте следующее:

Полная блокировка таблицы на столе InnoDB
Выполнить массовую загрузку
Отпустите замок

— RolandoMySQLDBA
источник

Поможет ли это иметь несколько буферных пулов? Или, поскольку это всего лишь один стол, это будет иметь значение?

— Sep332

Только один буферный пул. Таким образом, нет виртуального ограничения. У меня есть клиент с MySQL 5.5.9, использующий один буферный пул 162 ГБ, и он работает просто замечательно.

— RolandoMySQLDBA

Используя это, я получил около 950% процессорного времени, но, похоже, не быстрее.

— Sep332

Попробуйте полную блокировку таблицы для таблицы InnoDB перед массовой загрузкой.

— RolandoMySQLDBA

Существует ряд факторов, которые влияют на возможность максимального использования нескольких ядер.

Некоторые мьютексы воздействуют на несколько процессоров, оставляя некоторое ожидание, прежде чем они смогут продолжить работу.
Вам нужно столько активных потоков, сколько у вас процессоров. Если ваша рабочая нагрузка приводит к 9 параллельным потокам, вы не можете заполнить 12 ядер.
Емкость ввода / вывода должна быть достаточной для обеспечения достаточной работы для всех процессоров. Если вы ставите в очередь на дисковый ввод-вывод или ожидаете сетевых сообщений, вы не сможете заполнить процессоры.

Такие инструменты, как SAR, позволят вам определить, есть ли какие-либо узкие места, снижающие вашу емкость. Просто будьте предупреждены, устраняя одно узкое место, просто переместите узкое место.

— BillThor
источник