Всем хорошего дня!

Debian, MySQL 5.6.19.
Работал сайт прекрасно, вдруг недавно начались проблемы с запросами, при чем с любыми (select, update, insert).
Например:

# Query_time: 28.738771 Lock_time: 0.000094 Rows_sent: 0 Rows_examined: 1
update `user` set `timeZone`='Europe/Moscow' where `id`='2';

Его explain:

id select_type table type possible_keys key key_len ref rows filtered Extra'1' 'SIMPLE' 'user' 'range' 'PRIMARY' 'PRIMARY' '8' 'const' '1' '100.00' 'Using where'

Это вообще что-то его личное:
# Query_time: 27.254406 Lock_time: 0.000266 Rows_sent: 0 Rows_examined: 210
select count(*) into @discard from `information_schema`.`PARTITIONS`;
# Query_time: 23.213852 Lock_time: 0.000166 Rows_sent: 2 Rows_examined: 126
SELECT ENGINE,SUM(DATA_LENGTH),COUNT(ENGINE) FROM information_schema.TABLES WHERE TABLE_SCHEMA NOT IN ('information_schema','mysql') AND ENGINE IS NOT NULL GROUP BY ENGINE ORDER BY ENGINE ASC;

А вот моё:
# Query_time: 2.580645 Lock_time: 1.431141 Rows_sent: 1 Rows_examined: 12
SET timestamp=1411141756;
select count(1) cnt from `lib` where createdate >= '2014-09-19 15:48:58';
Индексов в этой таблице нет, но там сейчас около 10 записей, в любом случае такого времени не должно быть.
Есть свои селекты и на десятки секунд.

Короче итог такой, что в любой момент любой запрос может зависнуть на произвольное время.
Кучу параметров уже наменял в my, ничего не меняется. После перезапуска mysql проблема сразу наблюдается. Сейчас innodb_flush_log_at_trx_commit = 0. Но ведь не только с update проблемы.
Короче, я уже не знаю что делать, второй день сижу над этим.
Есть лог медленных запросов примерно за пол года - нет там таких долгих запросов, а тут вдруг началось такое.

Что подскажете?
Кстати, можно ли выполнить explain update с выполнением самого update? То есть чтобы на выполненном запросе увидеть, что происходит?

LumixprogrammisterКстати, можно ли выполнить explain update с выполнением самого update? То есть чтобы на выполненном запросе увидеть, что происходит?

только в mysql версии 5.6 и выше

И как это сделать? При explain сам update не выполняется.

Ясно. Тогда может в целом что-нибудь подскажете?

netwindprogrammisterЯсно. Тогда может в целом что-нибудь подскажете?
Обратиться к хостеру.
Прекратить ожидать от унылых VPS производительности выше чем древний ноутбук. Вы же не один на сервере.

Это Ажур :)

ScareCrowperfomance_scema

Спасибо, узрел я эту штуку в workbench. Что-то там столько всего :). Можете подсказать куда в моём случае лучше смотреть там? :)

ScareCrow,

вот, кстати, один из основных проблемных запросов:

Query Full Table Scan Executed (#) Errors (#) Warnings (#) Total Time Max Time Avg Time Rows Sent (#) Avg. Rows Sent (#) Rows Scanned (#) Avg. Rows Scanned (#) Temp. Tables (#) Temp. Disk Tables (#) Rows Sorted (#) Sort Merge Passes (#) DigestUPDATE `user` SET `timeZone` = ? WHERE `id` = ? 227 0 0 58799743.94 7674932.65 259029.71 0 0.0 227 1.0 0 0 0 0 826222397d4b7b4637ca7c69c368fbeb

miksoftprogrammisterЯсно. Тогда может в целом что-нибудь подскажете?Поищите настоящие долгие запросы. В т.ч. последите, не создаются ли временные таблицы диске. Последить можно как глазами (по наличию файлов в /tmp), там и по статус-переменным в MySQL.

Долгие запросы-то я и так знаю :). Как можно подробно изучить конкретный уже выполненный запрос или в процессе выполнения?

miksoft,

по отчётам этот запрос не создаёт временных таблиц.
В Full Table Scan его тоже нет.

miksoftprogrammisterДолгие запросы-то я и так знаю :).А нам показать?programmisterКак можно подробно изучить конкретный уже выполненный запрос или в процессе выполнения?Для начала посмотреть план.

Я же показал в первом посте и запрос, и его план. :)
Вот его за основу взял. Там поиск про ключу и обновление поля.
update `user` set `timeZone`='Europe/Moscow' where `id`='2';

miksoftprogrammisterЯ же показал в первом посте и запрос, и его план. :)
Вот его за основу взял. Там поиск про ключу и обновление поля.
update `user` set `timeZone`='Europe/Moscow' where `id`='2';Не, это не настоящие долгие запросы, это "наведенные". Имхо, они чего-то долго ждали. Либо соседей по серверу (о чем говорил netwind), либо ресурсов, занятых вашими настоящими долгим запросами.

1. Я этот запрос тестировал просто из своего локального workbench, когда на сайте никого нет, то есть больше нет никаких запросов.
2. В slow-логе часто идёт ТОЛЬКО этот запрос, то есть перед ним или после него нет долгих запросов, а этот может от 5 до 70 секунд висеть.

miksoftКакая текущая схема(база) при выполнении этого запроса? mysql или другая?

Другая. И в workbench, и в php при подключении параметр dbname=...
Я сейчас остановил веб-сервер и от себя поотправлял этот update - иногда зависает на 5-10 сек.

miksoftprogrammisterДругаяТ.е. таблица user - это ваша таблица?
Какой движок у таблицы? Полный DDL можете показать? Сколько записей?

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

Записей около 200.

miksoft,

Это что-то с чем-то.
Опять всё отключил на сервере, и через консоль зашёл в mysql и начал отправлять запросы - один из 5-10 запросов длиться 3-8 сек.

miksoftАвтокоммит включен? Как вообще коммит происходит?

Ну, в php транзакция явно открывается только в редких случаях (когда по логике нужно несколько запросов сделать). А так для одного запроса, типа этого, своей транзакции нет.
В консоле тем более никаких транзакций не открываю. Сейчас при тесте просто update отправлял.
В workbench по умолчанию нажата autocommit.

В самом mysql autocommit = ON
innodb_commit_concurrency = 0
innodb_flush_log_at_trx_commit = 0