powered by simpleCommunicator - 2.0.41     © 2025 Programmizd 02
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Долгое выполнение запроса на Hot Stanby
5 сообщений из 5, страница 1 из 1
Долгое выполнение запроса на Hot Stanby
    #40050758
Безенчук
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Добрый день!

На двух серверах Ubuntu 18.04 установлен PostgreSQL 11.8 и настроена потоковая репликация. Ведомый сервер работает в режиме hot standby. Есть некоторый запрос, который на ведомом сервере обычно выполняется за секунду-другую, но изредка этот процесс затягивается на десятки минут. При этом, естественно, растёт отставание репликации на ведомом сервере. В обоих ситуациях нагрузка на серверы меняется несущественно. Если обратиться к pg_stat_activity в тот момент, когда выполнение запроса в очередной раз существенно затянулось, то для этого процесса можно увидеть следующее:
Код: sql
1.
2.
3.
4.
wait_event_type  | IO
wait_event       | DataFileRead
state            | active
backend_type     | client backend


Если заглянуть в pg_locks, то для нужного нам pid выдаётся такая информация (пустые стобцы удалены):
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
  locktype  | database | relation  | virtualxid | virtualtransaction |  pid  |      mode       | granted | fastpath
------------+----------+-----------+------------+--------------------+-------+-----------------+---------+----------
 relation   |    16385 |     16787 |            | 8/2110552          | 68295 | AccessShareLock | t       | t
 relation   |    16385 |  10292249 |            | 8/2110552          | 68295 | AccessShareLock | t       | t
 relation   |    16385 |  93750721 |            | 8/2110552          | 68295 | AccessShareLock | t       | t
 relation   |    16385 |     17483 |            | 8/2110552          | 68295 | AccessShareLock | t       | t
 relation   |    16385 |     37093 |            | 8/2110552          | 68295 | AccessShareLock | t       | t
 relation   |    16385 |     17495 |            | 8/2110552          | 68295 | AccessShareLock | t       | t
 virtualxid |          |           | 8/2110552  | 8/2110552          | 68295 | ExclusiveLock   | t       | t
 relation   |    16385 |  10292259 |            | 8/2110552          | 68295 | AccessShareLock | t       | f
 relation   |    16385 |  10209326 |            | 8/2110552          | 68295 | AccessShareLock | t       | f
 relation   |    16385 |  10201111 |            | 8/2110552          | 68295 | AccessShareLock | t       | f
 relation   |    16385 |   9254597 |            | 8/2110552          | 68295 | AccessShareLock | t       | f
 relation   |    16385 |   7512138 |            | 8/2110552          | 68295 | AccessShareLock | t       | f
 relation   |    16385 |     16859 |            | 8/2110552          | 68295 | AccessShareLock | t       | f

Поиск по форуму привёл к теме 20999107 , в которой говорится о том, что ExclusiveLock виртуальной транзакции возникает как в случае CREATE INDEX CONCURRENTLY, так и в случае конфликта на Hot Standby.
Подскажите, пожалуйста, куда смотреть дальше, чтобы понять причину возникшей ситуации?
...
Рейтинг: 0 / 0
Долгое выполнение запроса на Hot Stanby
    #40050765
Melkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
wait_event более чем однозначно указан на DataFileRead

почему вас беспокоят pg_locks?
...
Рейтинг: 0 / 0
Долгое выполнение запроса на Hot Stanby
    #40050774
Безенчук
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ситуация непонятна для меня, поэтому хочу разобраться. Тем более, что далеко не всегда запрос выполняется очень долго, гораздо чаще он выполняется за пару секунд - поэтому и возникла мысль о блокировках. Добавлю, что если запрос прервать и заново выполнить - результат выдаётся сразу же.
...
Рейтинг: 0 / 0
Долгое выполнение запроса на Hot Stanby
    #40050829
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Безенчук,

Я бы сказал что если проблема вида "но изредка этот процесс затягивается на десятки минут." то это через модуль auto_explain решать надо
https://www.postgresql.org/docs/13/auto-explain.html

просто чтобы посмотреть какой план был и сравнить его с планом который обычно получается.

Этот вопрос не про блокировки а про неудачный выбор плана базой вероятнее всего.

80% что запрос имеет вид select ... where (набор условий) order by одно_поле limit N
при этом по одно_поле есть индекс
тут при неудачной оценке базой селективности (набор условий) может пойти index scan + filter и перебрать всю таблицу.


--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
Долгое выполнение запроса на Hot Stanby
    #40050869
Безенчук
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Maxim Boguk, спасибо!
Будем посмотреть.
...
Рейтинг: 0 / 0
5 сообщений из 5, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Долгое выполнение запроса на Hot Stanby
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]