Большое количество операторов INSERT, блокирующих вставки в другие таблицы в MySQL 5.5.

Я пытаюсь понять проблему с сервером MySQL 5.5.

На этом сервере размещено несколько баз данных. Каждый день в определенное время процесс выполняет серию вставок в ДВЕ таблицы в этой базе данных. Этот процесс длится от 5 до 15 минут в зависимости от количества вставляемых строк.

Этот процесс проходит идеально. Но у него есть очень неожиданный побочный эффект. Все остальные вставки и обновления выполняются в таблицах, не связанных с двумя вставляемыми, чтобы просто сидеть и ждать, пока процесс не остановится. Чтение и запись за пределами этой базы данных работают просто отлично, и операторы SELECT тоже в порядке.

Так как же одна таблица может блокировать остальную часть базы данных, но не весь сервер (из-за загрузки)?

Немного предыстории:-

  • Таблицы, в которые вставляются MyISAM, содержат от 10 до 20 миллионов строк.

  • MySQL представляет собой Percona V5.5 и обслуживает одно ведомое устройство, оба работают на Debian.

  • Процесс, вставляющий записи, не требует явной блокировки.

  • Ни один из операторов Insert не выбирает данные из какой-либо другой таблицы. Они также являются операторами INSERT IGNORE.

ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ:

Пока это происходит, в PROCESS LIST нет записей таблицы LOCK, и процессор, вставляющий записи, вызывающие эту проблему, НЕ блокирует таблицы.

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


person Mike Hancock    schedule 16.09.2013    source источник
comment
Это может быть проблемой блокировки мьютекса при ротации fsyncing binlog.   -  person piotrm    schedule 16.09.2013


Ответы (1)


После нескольких недель попыток я в конце концов нашел это: Блог Ёсинори Мацунобу - MyISAM и Disk IO Scheduler

Йошинори демонстрирует, что изменение очереди планировщика на 100000 (по умолчанию 128) значительно повышает пропускную способность MyISAM на большинстве планировщиков.

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

Любой, у кого возникают проблемы с производительностью MyISAM, должен прочитать запись в блоге Йошинори и рассмотреть это исправление.

person Mike Hancock    schedule 26.11.2013