Далее, довольно просто получить отчет какой процесс удерживает блокировку и сделать выводы.
Но, вы правы- объем огромный. Надо будет, что-то придумывать. Если нагрузка серъезная отчеты будут недоступны из-за гиганского объема.
Но ведь можно собирать не все блокировки, а только по интересующим queryid.
В общем, тема еще в процессе анализа.
queryid заполняется отдельной функцией. Чуть попозже опишу подробнее, в отдельной статье. Сейчас закончу отчеты по pg_locks и займусь.
С повторением pid, случается. Но не думаю, что это большая проблема, они ведь повторяются в разных отрезках времени. Т.е. backend_start+pid думаю будет достаточно.
Но задача еще требует детального тестирования.
Спасибо за приглашение.
Опубликовано — habr.com/ru/post/467181
Чуть попозже подготовлю более подробные описания по шагам и скриптам. Сейчас как раз идет тестирование. Материала очень много. Может быть будет интересно кому.
Спасибо за ссылку, посмотрел, взял в коллекцию, очень интересно. Но не совсем, то, что хотелось.
Непонятно, как работает песочница.
С одной стороны — ожидает модерации
— Песочница
Мои публикации rinace 10 сентября 2019 в 16:51
ASH для PostgreSQL
— С другой стороны, в песочнице, в разделе «Ожидают приглашения», я тоже статью не вижу.
Видимо сначала модерация, потом приглашение.
В двух словах идея довольно простая(ну если сильно упрощенно)
1)Создаются таблицы хранения снимков представлений pg_stat_avtivity, pg_locks (просто добавляется поле timepoint) — history_pg_stat_avtivity, history_pg_locks
2)systemd service каждую секунду сохраняет снимок представлений в таблицы history_*
2)каждый час создается новая секция archive_pg_stat_avtivity, archive_pg_locks для хранения истории
3)Для таблицы archive_pg_stat_avtivity добавлется дополнительный столбец queryid, который хранить queryid выполняемого запроса из представления pg_stat_statements
В результате можно получить информацию:
-Общее время CPU
-Общее время Waitings
-Время CPU для отдельного запроса по queryid
-Время Waitings для отдельного запроса по queryid
-Какие конкретно события ждал запрос
-Освобождения каких блокировок ждал запрос
-Какой процесс(запрос) удерживал блокировки
Смысл именно в том, что бы связать pg_stat_statement + pg_locks + pg_stat_activity
В результате получается некое подобие отделено напоминающее AWR в Oracle.
Первая статья в основном по ожиданиям, вторая будет по блокировкам, используя ваши статьи. Кстати пользуясь случаем спасибо.
Про семплирование.
В песочнице ожидает модерации статья о личном опыте решения.
Кратко — ведется история pg_stat_activity, pg_locks, pg_stat_user_tables.
История храниться не в целевой базе, а в отдельной базе мониторинга.
В результате получаемые отчеты очень помогает получать картину происходящего. Особенно по деградации отдельных запросов.
Далее, довольно просто получить отчет какой процесс удерживает блокировку и сделать выводы.
Но, вы правы- объем огромный. Надо будет, что-то придумывать. Если нагрузка серъезная отчеты будут недоступны из-за гиганского объема.
Но ведь можно собирать не все блокировки, а только по интересующим queryid.
В общем, тема еще в процессе анализа.
queryid заполняется отдельной функцией. Чуть попозже опишу подробнее, в отдельной статье. Сейчас закончу отчеты по pg_locks и займусь.
С повторением pid, случается. Но не думаю, что это большая проблема, они ведь повторяются в разных отрезках времени. Т.е. backend_start+pid думаю будет достаточно.
Но задача еще требует детального тестирования.
Опубликовано — habr.com/ru/post/467181
Чуть попозже подготовлю более подробные описания по шагам и скриптам. Сейчас как раз идет тестирование. Материала очень много. Может быть будет интересно кому.
Спасибо за ссылку, посмотрел, взял в коллекцию, очень интересно. Но не совсем, то, что хотелось.
С одной стороны — ожидает модерации
— Песочница
Мои публикации
rinace 10 сентября 2019 в 16:51
ASH для PostgreSQL
— С другой стороны, в песочнице, в разделе «Ожидают приглашения», я тоже статью не вижу.
Видимо сначала модерация, потом приглашение.
В двух словах идея довольно простая(ну если сильно упрощенно)
1)Создаются таблицы хранения снимков представлений pg_stat_avtivity, pg_locks (просто добавляется поле timepoint) — history_pg_stat_avtivity, history_pg_locks
2)systemd service каждую секунду сохраняет снимок представлений в таблицы history_*
2)каждый час создается новая секция archive_pg_stat_avtivity, archive_pg_locks для хранения истории
3)Для таблицы archive_pg_stat_avtivity добавлется дополнительный столбец queryid, который хранить queryid выполняемого запроса из представления pg_stat_statements
В результате можно получить информацию:
-Общее время CPU
-Общее время Waitings
-Время CPU для отдельного запроса по queryid
-Время Waitings для отдельного запроса по queryid
-Какие конкретно события ждал запрос
-Освобождения каких блокировок ждал запрос
-Какой процесс(запрос) удерживал блокировки
Смысл именно в том, что бы связать pg_stat_statement + pg_locks + pg_stat_activity
В результате получается некое подобие отделено напоминающее AWR в Oracle.
Первая статья в основном по ожиданиям, вторая будет по блокировкам, используя ваши статьи. Кстати пользуясь случаем спасибо.
В песочнице ожидает модерации статья о личном опыте решения.
Кратко — ведется история pg_stat_activity, pg_locks, pg_stat_user_tables.
История храниться не в целевой базе, а в отдельной базе мониторинга.
В результате получаемые отчеты очень помогает получать картину происходящего. Особенно по деградации отдельных запросов.