|
Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
В процессе активной чистки некоторых таблиц стали накапливаться запросы со статусом "query end". Вопрос возник потому, что чистится одна таблица, а запросы с "query end" используют другую таблицу, и более того, даже другую БД.
С чем это может быть связано? Сервер Percona 5.5.30, все таблицы InnoDB, данные таблиц в общем файле, innodb_flush_log_at_trx_commit = 0.
ЗЫ Последующие запросы после висящих вполне возможно используют очищаемые таблицы для вставки/обновления, если причина в этом, то вроде как в процессах должны отображаться эти запросы, со статусом "wait for table" или ещё какими-то.
Неактивен
Похоже на багу, запрос выполнился но что-то мешает освободить ресурсы. После чистки они отваливаются?
Неактивен
Не отваливаются, выжидают своего часа и успешно отрабатывают 
Чистка идёт в виде удаления в цикле по Х записей и паузой после каждого запроса удаления. Я ж так понимаю есть какой-то лимит заблокированных строк и со временем он у меня достигается из-за не достаточной паузы, соответственно чтобы обработать новые строки, надо сбрсоить имеющиеся блокировки. Но я всегда был уверен, что этот счётчик работает в пределах одной таблицы, а тут по такому поведению появляются мысли, что счётчик блокировок один на весь СУБД. Правильно ли мыслю?
Неактивен
Это я неудачно выразился насчет "отваливаются".
http://dev.mysql.com/doc/refman/5.6/en/general-thread-states.html написал:
query end
This state occurs after processing a query but before the freeing items state.
Запрос уже выполнился, но что-то мешает ему освободить используемые ресурсы (очистить память, закрыть таблицы и т.д.)
Накапливающиеся запросы они select или меняют данные?
Неактивен
Меняют данные, селектов в это время не наблюдается.
Неактивен
Попробуйте режим innodb_file_per_table
Неактивен
Были такие мысли... на сколько с этим параметром ухудшается производительность?
Неактивен
А почему она должна ухудшиться?
Неактивен
Из минусов у вас возрастет количество операций открытия файла.
С другой стороны: если некоторые таблицы часто изменяются это приводит к фрагментации общего хранилища из-за чего может пострадать производительность других таблиц, поэтому рекомендуют innodb_file_per_table
Кроме того в перконе в режиме innodb_file_per_table есть специальные возможности, например, пометить таблицу как испорченная (при этом остальные будут работать).
Неактивен
Может ли быть связано с query cache? Что дает профайлинг на запрос, который подвисает?
http://stackoverflow.com/questions/1231 … y-end-step
Неактивен
А как можно посмотреть профайлинг при выполнении самого запроса? По приведённой ссылке выполняется три шага, это для меня закончится суецидом, ибо сначала надо "положить на лопатки" сервер и мониторить процессы, а уже потом делать профилирование.
Неактивен
Допишите в скрипт, который генерит запросы в статусе "query end", чтобы сохранял инфу из INFORMATION_SCHEMA.PROFILING куда-нибудь. Потом запустите активную чистку и разгребаqте полученный завал.
Других вариантов, имхо, нет.
К сожалению, в данный момент есть возможность сохранять по ходу выполнения только план запроса (да и только в MariaDB 10.0).
Неактивен
Справился с тремя шагами))
mysql_5 ((none))>set profiling = 1;
Query OK, 0 rows affected (0.00 sec)
mysql_5 ((none))>REPLACE INTO `log`.`files`(`user_id`,`file`,`message`) VALUES (NULL,'ks.dlr','Not found ks_dlr with msg_id \"61302d50-52fb-35dc-bb56-ddef36bbd961\"');
Query OK, 2 rows affected (7.46 sec)
mysql_5 ((none))>show profile for query 1;
+--------------------------------+----------+
| Status | Duration |
+--------------------------------+----------+
| starting | 0.000049 |
| checking permissions | 0.000009 |
| Opening tables | 0.000017 |
| exit open_tables() | 0.000024 |
| System lock | 0.000006 |
| mysql_lock_tables(): unlocking | 0.000002 |
| exit mysqld_lock_tables() | 0.000003 |
| init | 0.000014 |
| update | 0.000471 |
| end | 0.000003 |
| query end | 7.457470 |
| innobase_commit_low():trx_comm | 0.000004 |
| query end | 0.000002 |
| ha_commit_one_phase(1713779783 | 0.000006 |
| query end | 0.000003 |
| closing tables | 0.000006 |
| freeing items | 0.000014 |
| logging slow query | 0.000001 |
| logging slow query | 0.000045 |
| cleaning up | 0.000002 |
| sleeping | 0.000001 |
+--------------------------------+----------+
21 rows in set (0.00 sec)
Неактивен
А отключение query_cache пробовали? Чтобы исключить эту версию http://bugs.mysql.com/bug.php?id=54584
Неактивен
Не пробовали, почитаю и подумаем.
Неактивен
И снова здрассьте У нас без изменений (в поведении и настройках), забИли, в общем.
Чисто случайно обнаружил, что время статуса "query end" соответствует времени выполнения кластерных запросов "committed X" и теперь я более, чем на 99,99% уверен, что причина именно в этом. У нас 3 ноды в XtraDB Cluster, в одну пишем, с трёх читаем.
Может теперь у кого-то есть мысли как избежать этих висюков?
Неактивен
Про XtraDB Cluster вы не говорили. Посмотрите обсуждение здесь - это похоже на вашу проблему?
https://bugs.launchpad.net/percona-xtra … ug/1197771
Неактивен
Да, не говорил, не видел зависимостей...
Предложенное обсуждение немного не то, больше подходит вот это: https://bugs.launchpad.net/percona-xtra … ug/1268978 но оно не решено и не активно.
Неактивен
Про отставание в галере лучше всего написано в районе статьи про flow control:
http://www.mysqlperformanceblog.com/201 … for-mysql/
Ну и понятно, что в синхронном коммите вы будете ждать сеть + самую медленную
машинку из кластера. Это жизнь — или синхронность, или скорость
Неактивен
Страниц: 1
