Комментарии 6
По практике — история pg_locks пригождается? Кажется, это огромный объем, а польза не очень ясна. (В целом был бы интересен разбор какого-то реального случая на основе собранных данных.)
Не очень понятно, откуда берутся queryid. Не нашел в коде.
Нет ли проблем с тем, что pid будут повторяться?
История pg_locks помогает получить например вот такой отчет:
Далее, довольно просто получить отчет какой процесс удерживает блокировку и сделать выводы.
Но, вы правы- объем огромный. Надо будет, что-то придумывать. Если нагрузка серъезная отчеты будут недоступны из-за гиганского объема.
Но ведь можно собирать не все блокировки, а только по интересующим queryid.
В общем, тема еще в процессе анализа.
queryid заполняется отдельной функцией. Чуть попозже опишу подробнее, в отдельной статье. Сейчас закончу отчеты по pg_locks и займусь.
С повторением pid, случается. Но не думаю, что это большая проблема, они ведь повторяются в разных отрезках времени. Т.е. backend_start+pid думаю будет достаточно.
Но задача еще требует детального тестирования.
+-----+-------------------------+----------+--------------------+--------------------+--------------------+-------------------- | | LOCKS STATICTICS | +------------------------------------------------------------------------------------ | WAITING FOR LOCKS BY LOCKTYPES +--------------------+------------------------------+-------------------- | locktype| mode| duration +--------------------+------------------------------+-------------------- | transactionid| ShareLock| 18:30:18 | tuple| AccessExclusiveLock| 00:01:35 +--------------------+------------------------------+-------------------- | TAKINGS OF LOCKS BY LOCKTYPES +--------------------+------------------------------+-------------------- | locktype| mode| duration +--------------------+------------------------------+-------------------- | relation| RowExclusiveLock| 50:24:00 | virtualxid| ExclusiveLock| 47:26:38 | transactionid| ExclusiveLock| 43:32:04 | relation| AccessShareLock| 20:43:58 | tuple| AccessExclusiveLock| 16:44:48 | tuple| ExclusiveLock| 01:45:34 | relation| ShareUpdateExclusiveLock| 00:24:39 | extend| ExclusiveLock| 00:00:06 | transactionid| ShareLock| 00:00:04 | object| RowExclusiveLock| 00:00:01 +--------------------+------------------------------+-------------------- | | WAITING FOR LOCKS BY LOCKTYPES FOR QUERIES +------------------------------+--------------------+------------------------------+------------------------------+-------------------- | query| queryid| locktype| mode| duration +------------------------------+--------------------+------------------------------+------------------------------+-------------------- | select test_del ();| 389015618226997618| transactionid| ShareLock| 09:00:51 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+~~~~~~~~~~~~~~~~~~~~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+~~~~~~~~~~~~~~~~~~~~
Далее, довольно просто получить отчет какой процесс удерживает блокировку и сделать выводы.
Но, вы правы- объем огромный. Надо будет, что-то придумывать. Если нагрузка серъезная отчеты будут недоступны из-за гиганского объема.
Но ведь можно собирать не все блокировки, а только по интересующим queryid.
В общем, тема еще в процессе анализа.
queryid заполняется отдельной функцией. Чуть попозже опишу подробнее, в отдельной статье. Сейчас закончу отчеты по pg_locks и займусь.
С повторением pid, случается. Но не думаю, что это большая проблема, они ведь повторяются в разных отрезках времени. Т.е. backend_start+pid думаю будет достаточно.
Но задача еще требует детального тестирования.
Добавил статью по поводу добавления queryid — habr.com/ru/post/467277
В новой версии ASH Viewer можно работать с историей активных сессий в Postgres напрямую. Что было сделано написано здесь, последние сборки можно взять отсюда.
Еще есть PASH Viewer.
Еще есть PASH Viewer.
Будет пакетное решение и исходники на github? А то так по разрозненным примерам вставок кода трудно ориентироваться
Это задача максимум, конечно.
По плану после завершения работ по обработке истории pg_locks, после тестирования на продкашн под более менее реальной нагрузкой, буду планировать выкладывать на github.
Согласен, по кускам кода очень сложно ориентироваться. Но кода набралось уже под пару MB(вместе с системой мониторинга конечно). Если все выкладывать в виде статей врядли будет более удобнее.
Поэтому пока планирую выкладывать в виде идей-тезисов, с примерами результатов.
А позже, если все будет нормально и до github дело дойдет.
Пока так, сорри.
По плану после завершения работ по обработке истории pg_locks, после тестирования на продкашн под более менее реальной нагрузкой, буду планировать выкладывать на github.
Согласен, по кускам кода очень сложно ориентироваться. Но кода набралось уже под пару MB(вместе с системой мониторинга конечно). Если все выкладывать в виде статей врядли будет более удобнее.
Поэтому пока планирую выкладывать в виде идей-тезисов, с примерами результатов.
А позже, если все будет нормально и до github дело дойдет.
Пока так, сорри.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Попытка создать аналог ASH для PostgreSQL