Есть mysql сервер 8.0.13 на каком то виртуальном хостинге (подозреваю что он не сильно шустрый, xeon e5 (2 процессора), 4Gb RAM).
Есть единственная таблица в единственной InnoDB-базе, вида

CREATE TABLE `table1` (
  `str1` varchar(16) NOT NULL,
  `d1` double NOT NULL,
  `d2` double NOT NULL,
  `time` datetime NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=cp1251;

Чтений совсем нет (пока что), идет только вставка, раз в 1-3 секунды от нескольких клиентов (и редкое удаление старых записей), всего в таблице в конкретный момент времени 2-4 тысячи записей.

Так вот, insert очень сильно тормозит, 5-10-30 секунд идут вставки нескольких записей. При чем если один клиент затормозился, то и все встали тоже.
show full processlist показывает постоянные статусы запросов, вида 'waiting for handler commit'.
В слоу-логе на все такие медленные запросы есть логи вида '# Query_time: 19.675364 Lock_time: 0.000865 Rows_sent: 0 Rows_examined: 0'.
Куда еше можно копнуть?

Здравствуйте, Hayabusa, Вы писали:

H>Куда еше можно копнуть?

Нескольких записей — это сколько? И сколько пишущих клиентов? Не может быть что они коннекты ждут из пула?

Здравствуйте, BlackEric, Вы писали:

BE>Нескольких записей — это сколько? И сколько пишущих клиентов? Не может быть что они коннекты ждут из пула?

От одной до 10ти одновременно вставляет один клиент. Клиент сейчас вообще один, ситуация вообще нихрена не изменилась.
'waiting for handler commit' — на этом статусе висит каждый запрос несколько секунд. Да, бывает и быстро выполняется, 50\50 как то.
Может впс дохлая? Там интерфейс даже еле шевелится..

Здравствуйте, Hayabusa, Вы писали:

H>Может впс дохлая? Там интерфейс даже еле шевелится..
Ну я бы с этого начинал.

Здравствуйте, BlackEric, Вы писали:
BE>Ну я бы с этого начинал.

Процессор в среднем 10-20%, оперативы занято 1.5 из 4Gb, подозрение на дисковую подсистему. Как ее можно чекнуть? Может у самой бд есть какие нибудь логи по этому поводу? Slow-лог толком ничего не говорит.

Измерил скорость диска, получилось вот что

	disk

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

А вот что мне показал Workbench на explain запроса вида

insert into `table1` (str1,d1,d2,`time`) values ('str',1,1,'2019-01-01 10:00');

Т.е. происходит полное сканирование таблицы?
Это может повлиять на скорость вставки? И если да, как этого избежать, нужны индексы?

Поправил в my.ini

innodb_buffer_pool_size 8M -> 128M
innodb_log_buffer_size 1M -> 8M
innodb_thread_concurrency 10 -> 4

Slow-лог стал заметно реже тревожиться (7 секунд стоит трезольд), но все равно как то не то.
Видимо виртуальный диск совсем дохлый на WPS.

Здравствуйте, Hayabusa, Вы писали:

H>Чтений совсем нет (пока что), идет только вставка, раз в 1-3 секунды от нескольких клиентов (и редкое удаление старых записей), всего в таблице в конкретный момент времени 2-4 тысячи записей.

H>Так вот, insert очень сильно тормозит, 5-10-30 секунд идут вставки нескольких записей. При чем если один клиент затормозился, то и все встали тоже.
H>show full processlist показывает постоянные статусы запросов, вида 'waiting for handler commit'.
H>В слоу-логе на все такие медленные запросы есть логи вида '# Query_time: 19.675364 Lock_time: 0.000865 Rows_sent: 0 Rows_examined: 0'.
H>Куда еше можно копнуть?

Похоже на проблему локов. Если всех в один поток пустить, уйдут проблемы (innodb_thread_concurrency=1)?

Может это? https://www.percona.com/blog/2012/03/27/innodbs-gap-locks/

Здравствуйте, Буравчик, Вы писали:

Б>Похоже на проблему локов. Если всех в один поток пустить, уйдут проблемы (innodb_thread_concurrency=1)?
Я там чуть выше писал, что оставил даже одного пишущего клиента, ситуация почти не изменилась.
Поставил сейчас и этот флаг — ничего не изменилось.
show full processlist показывает зависшим на 'waiting for handler commit' один insert.
При чем уже большинство инсертов пролетает бодро, раз 10-30 секунд он почему то виснет на несколько секунд..

Б>Может это? https://www.percona.com/blog/2012/03/27/innodbs-gap-locks/
Ну дык читателей у меня сейчас совсем нет..
Вставка идет простым insert, без всяких там ignore и т.д. Индексов на таблице тоже нет. Ключей по полям тоже нет.

Меня вот теперь очень интересует, что означает этот 'waiting for handler commit', гугление что-то ничего внятного по этому вопросу не дало.

Здравствуйте, Hayabusa, Вы писали:

H>При чем уже большинство инсертов пролетает бодро, раз 10-30 секунд он почему то виснет на несколько секунд..

Может, действительно, диск фризится. Попробуй ioping на диске посмотреть.

H>Ну дык читателей у меня сейчас совсем нет..

А "редкое удаление старых записей"?

Здравствуйте, Буравчик, Вы писали:

Б>А "редкое удаление старых записей"?
Да, совсем забыл. Удаление происходит из того же потока\клиента, что и инсерты, раз в три минуты, по условию с датой (последним полем), все делиты пролетают быстро, ну относительно быстро, до секунды.

Б>Может, действительно, диск фризится. Попробуй ioping на диске посмотреть.
Эмм... Windows

Здравствуйте, Hayabusa, Вы писали:

H>Меня вот теперь очень интересует, что означает этот 'waiting for handler commit', гугление что-то ничего внятного по этому вопросу не дало.

Если правильно понял, это новый stage для Performance Schema.

Про Performance Schema:
https://dev.mysql.com/doc/refman/8.0/en/performance-schema.html
https://habr.com/ru/post/126358/

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

Здравствуйте, Буравчик, Вы писали:

Б>Если правильно понял, это новый stage для Performance Schema.
Б>Про Performance Schema:
Б>https://dev.mysql.com/doc/refman/8.0/en/performance-schema.html
Б>https://habr.com/ru/post/126358/
Б>По идее, с помощью этого можно докопаться до самых низкоуровневых причин Вашей проблемы, но я не подскажу как.

Спасибо. Да, тут надо глубоко зарываться..

H>Куда еше можно копнуть?

Диск — дрова?

	Скрытый текст

upd: на всякий случай, это после рестарта в тот же день, стата вроде сбрасывается.

Здравствуйте, Hayabusa, Вы писали:
H>Диск — дрова?

Ну дайте коммент что ли по этим дровам, мускуль перезапускался часа за 2-3 до поста.

Здравствуйте, Hayabusa, Вы писали:

И что за причина перезапуска? Что в логах?
Скорее всего у вас кривое железо. Я бы начал с замены диска под бд.

Здравствуйте, BlackEric, Вы писали:
BE>И что за причина перезапуска? Что в логах?
BE>Скорее всего у вас кривое железо. Я бы начал с замены диска под бд.

Перезапускался из за изменений в my.ini
Что за лог имеется ввиду, slow-лог?
По железу да — не понятно, что там за виртуальный диск, и какая часть скорости от реальной отдана моей wps.

Здравствуйте, Hayabusa, Вы писали:

H>Спасибо. Да, тут надо глубоко зарываться..

Сделай хотя бы

select event_name, source, sum(timer_wait) timer_wait 
from events_waits_history_long 
group by event_name, source 
order by 3 desc 
limit 30;

Здравствуйте, Буравчик, Вы писали:

Б>Сделай хотя бы
Б>

Б>select event_name, source, sum(timer_wait) timer_wait 
Б>from events_waits_history_long 
Б>group by event_name, source 
Б>order by 3 desc 
Б>limit 30;
Б>

В sql8 нет таблички events_waits_history_long.
что есть — https://dev.mysql.com/doc/refman/8.0/en/sys-schema-views.html