|
Задавайте вопросы, мы ответим
Вы не зашли.
Сервер Percona 5.6.19-67.0, в какой-то момент одно ядро проца загружается на 100%, длятся такие зависания минут 5. SHOW FULL PROCESSLIST; показал что в этот момент выполняется запрос:
| 459 | bd_user | 192.168.1.4:50681 | blndb | Query | 663 | updating | DELETE FROM `acclist` WHERE `regtime`!='1407241502' | 0 | 941192636 |
(Rows_sent соответственно 0, Rows_examined - 941192636).
У остальных запросов состояние "Waiting for table level lock".
Таблица acclist:
Rows: 81037
Table Type: MEMORY
Row Format: Dynamic
Index Length: 12,58 MB (13 189 468)
Data Length: 62,77 MB (65 819 744)
CREATE TABLE `acclist` (
`id` mediumint(4) unsigned NOT NULL DEFAULT '0',
`regtime` bigint(20) unsigned NOT NULL,
`name` varbinary(100) NOT NULL,
...
PRIMARY KEY (`id`,`regtime`,`name`),
UNIQUE KEY `id` (`id`,`name`) USING BTREE,
KEY `id2` (`id`,`regtime`) USING BTREE,
KEY `id3` (`regtime`) USING BTREE
) ENGINE=MEMORY DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=256;
Этот запрос проходит около 300 раз в сутки, и обычно выполняется менее чем за секунду.
В чем может заключаться причина такого долгого выполнения?
Неактивен
Сколько реально строк удаляется? Для чего используется ROW_FORMAT=COMPRESSED?
Неактивен
Удаляется не более половины от общего количества, т.е. тогда это было максимум 40518 строки. ROW_FORMAT=COMPRESSED на MEMORY равноценен Dynamic. Вчера сервер на этом запросе так завис 3 раза и 213 этих же запросов прошли без зависаний.
Отредактированно gif-t (06.08.2014 11:34:32)
Неактивен
Похоже на deadlock. Какая-то бага не позволяет ему продолжить работу. Возможно, другой тред взял блокировку для записи в эту же таблицу, а теперь ждет выполнения DELETE. В MEMORY могут быть баги в реализации одновременности. Попробуйте перевести таблицу в Innodb (с innodb_file_per_table).
Неактивен
rgbeast написал:
Похоже на deadlock.
Мне тоже так кажется. Будто пытается пройти транзакция, которая каждый раз не проходит и циклически перезапускается сначала. Но если у всех остальных запросов статус Waiting for table level lock, получается этот DELETE залочил таблицу и транзакция вроде как должна пройти без проблем.
rgbeast написал:
В MEMORY могут быть баги в реализации одновременности. Попробуйте перевести таблицу в Innodb (с innodb_file_per_table).
На Innodb не хотелось бы, т.к. таблица используется как буфер. Она переписывается почти каждую секунду и потеря данных абсолютно не критична.
Сегодня из 273 таких DELETE запросов зависло 4, первый на 167 секунд, второй на 105, третий на 204 и четвертый на 320.
Никакой зависимости в передаваемых цифрах я пока не наблюдаю. Единственное что у этих запросов явно неадекватно - значение Rows_examined всегда девятизначное число, которое, как я полагаю, не должно превышать количество строк в таблице. А пиковое сегодня в таблице было всего 221394 строк. Rows-affected - это, как я понял количество удаленных строк, на этих запросах колеблеца от 1392 до 3463.
Может в MySQL можно выставить лимит на время запроса или значение Rows_examined?
Неактивен
Возможность ограничить время исполнения есть только в будущей MySQL 5.7 ( переменная MAX_STATEMENT_TIME ). Можно использовать внешнюю утилиту из Percona Tools pt-kill, которая убивает запросы, выполняющиеся слишком долго.
Попробуйте все же Innodb. За счет использования буфера это не должно быть серьезной потерей производительности.
Неактивен
В текущей конфигурации сервер не справится с нагрузкой. С помощью memory таблиц я буферизирую запись на винчестеры. Все инсерты и апдейты произвожу в memory, и через необходимые мне интервалы времени (раз в час или раз в сутки для некоторых таблиц) скидываю на винчестер в innodb таблицы. Года 3 назад благодаря этому шагу 5 серваков заменили на один.
Оставлю пока всё как есть, спасибо.
Неактивен
Значит включите pt-kill, чтобы убивал долгие запросы. Это скрипт, его можно настроить под себя.
Неактивен
