lekss361/gendesign

Fork 0

tradein: транзакция живёт дольше часа регулярно (50 замеров из 4033 за 14 суток, пик 2.2 ч) — пока она жива, vacuum не убирает мёртвые строки во ВСЕЙ базе #3480

New issue

Open

opened 2026-09-12 11:01:11 +00:00 by bot-backend · 2 comments

bot-backend commented

2026-09-12 11:01:11 +00:00

Collaborator

Найдено 12.09.2026 по тревоге PostgresLongTransaction со скриншота владельца. Разбирал историей метрики, а не одним наблюдением.

Факт

pg_activity_horizon_oldest_xact_age_s за 14 суток, шаг 5 мин:

БД	точек	дольше часа	пик
gendesign	4033	0	0.1 ч
infra	4033	0	0.0 ч
tradein	4033	50 (1.2 %)	2.2 ч

Это не разовый выброс: окна повторяются, и почти все — в одно и то же время суток.

09-09 05:43–05:53 UTC — 0.2 ч
09-10 06:08–06:13 UTC — 0.1 ч
09-10 22:28–23:43 UTC — 1.2 ч
09-11 06:43–06:53 UTC — 0.2 ч
09-12 06:13–06:43 UTC — 0.5 ч

Две другие базы того же кластера чисты — значит дело не в настройках сервера, а в коде именно трейд-ин.

Чем это платится

Пока открыта самая старая транзакция, vacuum не может убрать мёртвые строки во всей базе, а не только в задетых таблицах. Рядом уже живёт тревога PostgresDeadTuplesHigh и разбор #2607, где осиротевшие запросы висели 46 часов и держали горизонт vacuum. Здесь то же самое, только регулярно и по часу.

Куда смотреть

Окно 09-12 06:13–06:43 UTC закрылось ровно тогда, когда закончились три прогона — и все три с точностью до секунды (06:39:28–06:39:29), то есть их завершил дрейн, а не естественный конец:

6787 | avito_newbuilding_sweep | cancelled | 02:36:00 → 06:39:29
6801 | domclick_city_sweep     | done      | 05:10:07 → 06:39:28
6808 | yandex_detail_backfill  | done      | 06:10:08 → 06:39:28

Гипотеза (её надо подтвердить, а не принять): длинный прогон сбора держит ОДНУ транзакцию на всю свою длительность вместо того, чтобы коммитить по частям. Проверяется тем же способом — снять pg_stat_activity с xact_start в момент следующего срабатывания и сопоставить application_name/query с активным прогоном.

Почему это стоит отдельной задачи

statement_timeout из #3463 сюда не поможет: он ограничивает ОДИН запрос, а тут долго живёт транзакция между запросами. Лечится либо коммитом по батчам, либо idle_in_transaction_session_timeout, либо тем и другим — но сначала надо назвать виновника по имени, а не по подозрению.

Приёмка

За неделю после правки: ноль точек pg_activity_horizon_oldest_xact_age_s > 3600 по БД tradein (сейчас 50 из 4033 за 14 суток). Замер тем же запросом к Prometheus.

Refs #2607, #3463, #3449.

Найдено 12.09.2026 по тревоге `PostgresLongTransaction` со скриншота владельца. Разбирал историей метрики, а не одним наблюдением. ## Факт `pg_activity_horizon_oldest_xact_age_s` за 14 суток, шаг 5 мин: | БД | точек | дольше часа | пик | |---|---|---|---| | gendesign | 4033 | **0** | 0.1 ч | | infra | 4033 | **0** | 0.0 ч | | **tradein** | 4033 | **50 (1.2 %)** | **2.2 ч** | Это не разовый выброс: окна повторяются, и почти все — в одно и то же время суток. ``` 09-09 05:43–05:53 UTC — 0.2 ч 09-10 06:08–06:13 UTC — 0.1 ч 09-10 22:28–23:43 UTC — 1.2 ч 09-11 06:43–06:53 UTC — 0.2 ч 09-12 06:13–06:43 UTC — 0.5 ч ``` Две другие базы того же кластера чисты — значит дело не в настройках сервера, а в коде именно трейд-ин. ## Чем это платится Пока открыта самая старая транзакция, `vacuum` не может убрать мёртвые строки **во всей базе**, а не только в задетых таблицах. Рядом уже живёт тревога `PostgresDeadTuplesHigh` и разбор #2607, где осиротевшие запросы висели 46 часов и держали горизонт vacuum. Здесь то же самое, только регулярно и по часу. ## Куда смотреть Окно 09-12 06:13–06:43 UTC закрылось ровно тогда, когда закончились три прогона — и все три с точностью до секунды (`06:39:28–06:39:29`), то есть их завершил дрейн, а не естественный конец: ``` 6787 | avito_newbuilding_sweep | cancelled | 02:36:00 → 06:39:29 6801 | domclick_city_sweep | done | 05:10:07 → 06:39:28 6808 | yandex_detail_backfill | done | 06:10:08 → 06:39:28 ``` Гипотеза (её надо подтвердить, а не принять): длинный прогон сбора держит ОДНУ транзакцию на всю свою длительность вместо того, чтобы коммитить по частям. Проверяется тем же способом — снять `pg_stat_activity` с `xact_start` в момент следующего срабатывания и сопоставить `application_name`/`query` с активным прогоном. ## Почему это стоит отдельной задачи `statement_timeout` из #3463 сюда не поможет: он ограничивает ОДИН запрос, а тут долго живёт транзакция между запросами. Лечится либо коммитом по батчам, либо `idle_in_transaction_session_timeout`, либо тем и другим — но сначала надо назвать виновника по имени, а не по подозрению. ## Приёмка За неделю после правки: ноль точек `pg_activity_horizon_oldest_xact_age_s > 3600` по БД `tradein` (сейчас 50 из 4033 за 14 суток). Замер тем же запросом к Prometheus. Refs #2607, #3463, #3449.

bot-backend commented

2026-09-12 14:52:05 +00:00

Author

Collaborator

Гипотеза подтверждена независимым замером

В issue я написал предположение: «длинный прогон сбора держит ОДНУ транзакцию на всю свою длительность вместо того, чтобы коммитить по частям», и пометил его как требующее проверки.

При работе над #3463 (потолок на запрос и на ожидание блокировки) это вскрылось с другой стороны и независимо. Автор той правки замерял на проде, можно ли ставить idle_in_transaction_session_timeout, и нашёл:

живая сессия idle in transaction 29 с — свипы держат транзакцию всё время внешнего HTTP; сессионный потолок убивал бы рабочий сбор

То есть механизм именно такой, как предполагалось: транзакция открыта, а внутри неё идёт внешний HTTP к площадке. Длительность транзакции тогда равна длительности сетевого обхода, а не работы с базой, — отсюда и часы.

Что из этого следует для обеих задач

#3463 сознательно НЕ ставит idle_in_transaction_session_timeout — и это верное решение в его рамках: сессионный потолок оборвал бы законный сбор. Но он же консервирует эту задачу: пока транзакция открыта на время внешнего HTTP, горизонт vacuum держится, сколько бы ни длился обход.
Значит чинить надо не потолком, а коммитом по границам: транзакция не должна оставаться открытой на время сетевого запроса. Это правка в трактах сбора, а не в настройках БД.
statement_timeout здесь тоже не поможет по построению: он ограничивает ОДИН statement, а между statement'ами транзакция может жить сколько угодно.

Уточнение приёмки

Прежний критерий («ноль точек pg_activity_horizon_oldest_xact_age_s > 3600») остаётся, но к нему добавляется проверка механизма, а не только следствия: в момент срабатывания снять pg_stat_activity и убедиться, что самая старая транзакция находится в состоянии idle in transaction, а не active — первое означает «ждём сеть внутри транзакции», второе — «долгий запрос», и лечатся они по-разному.

Refs #3463, PR #3508.

## Гипотеза подтверждена независимым замером В issue я написал предположение: «длинный прогон сбора держит ОДНУ транзакцию на всю свою длительность вместо того, чтобы коммитить по частям», и пометил его как требующее проверки. При работе над #3463 (потолок на запрос и на ожидание блокировки) это вскрылось с другой стороны и независимо. Автор той правки замерял на проде, можно ли ставить `idle_in_transaction_session_timeout`, и нашёл: > живая сессия `idle in transaction` 29 с — свипы держат транзакцию всё время внешнего HTTP; сессионный потолок убивал бы рабочий сбор То есть механизм именно такой, как предполагалось: транзакция открыта, а внутри неё идёт **внешний HTTP к площадке**. Длительность транзакции тогда равна длительности сетевого обхода, а не работы с базой, — отсюда и часы. ## Что из этого следует для обеих задач 1. **#3463 сознательно НЕ ставит `idle_in_transaction_session_timeout`** — и это верное решение в его рамках: сессионный потолок оборвал бы законный сбор. Но он же **консервирует эту задачу**: пока транзакция открыта на время внешнего HTTP, горизонт vacuum держится, сколько бы ни длился обход. 2. Значит чинить надо не потолком, а **коммитом по границам**: транзакция не должна оставаться открытой на время сетевого запроса. Это правка в трактах сбора, а не в настройках БД. 3. `statement_timeout` здесь тоже не поможет по построению: он ограничивает ОДИН statement, а между statement'ами транзакция может жить сколько угодно. ## Уточнение приёмки Прежний критерий («ноль точек `pg_activity_horizon_oldest_xact_age_s > 3600`») остаётся, но к нему добавляется проверка механизма, а не только следствия: в момент срабатывания снять `pg_stat_activity` и убедиться, что самая старая транзакция находится в состоянии `idle in transaction`, а не `active` — первое означает «ждём сеть внутри транзакции», второе — «долгий запрос», и лечатся они по-разному. Refs #3463, PR #3508.

bot-backend commented

2026-09-12 15:29:33 +00:00

Author

Collaborator

Снимаю своё «подтверждение»: виновник назван неверно, это был тг-бот

Час назад я написал здесь, что гипотеза подтверждена независимым замером, и процитировал: «живая сессия idle in transaction 29 с — свипы держат транзакцию всё время внешнего HTTP». Разнёс это как факт.

Это неверно. При ревью PR #3508 сессию проследили до кода: pg_stat_activity снят 15 раз с шагом 8 с, единственная сессия в idle in transaction за всё окно — одна и та же, с запросом

SELECT value FROM tg_support_state WHERE key = CAST($1 AS text)

возраст транзакции циклически идёт 0.2 → 28.8 с и сбрасывается. Это app/services/tgbot/bridge.py:264 внутри run_poll_loop (bridge.py:969): with session_factory() as db: открыт поверх await client.get_updates(...) — long-poll Telegram, около 30 секунд на цикл.

То есть 29 секунд — это тг-бот, а не свипы, и к транзакциям длиннее часа из этой issue отношения не имеет. Я взял чужое число, приписал его своей гипотезе и выдал за подтверждение — ровно то, чего эта issue и требовала не делать («подтвердить, а не принять»).

Что остаётся в силе

Сам факт из issue: 50 точек из 4033 за 14 суток с транзакцией дольше часа по БД tradein, пик 2.2 ч, у двух соседних баз того же кластера — ноль.
Окна 06:13–06:43 UTC, закрывшиеся ровно тогда, когда дрейн завершил три прогона с точностью до секунды. Это по-прежнему указывает на свипы — но именно указывает, а не доказывает.
Вывод про инструменты: statement_timeout тут не поможет (ограничивает ОДИН statement), idle_in_transaction_session_timeout ронял бы long-poll тг-бота каждый цикл гарантированно — и PR #3508 сознательно его не ставит.

Что надо сделать, чтобы назвать виновника

Снять pg_stat_activity в момент срабатывания тревоги (не в произвольный момент, как вышло у меня) и сопоставить pid/application_name/query/xact_start с активным прогоном в scrape_runs. Плюс различать состояние: idle in transaction — «ждём сеть внутри транзакции», active — «долгий запрос». Это разные болезни с разным лечением.

Кандидат «свипы» до этого замера считать неподтверждённым.

Refs #3463, PR #3508.

## Снимаю своё «подтверждение»: виновник назван неверно, это был тг-бот Час назад я написал здесь, что гипотеза подтверждена независимым замером, и процитировал: «живая сессия `idle in transaction` 29 с — свипы держат транзакцию всё время внешнего HTTP». Разнёс это как факт. **Это неверно.** При ревью PR #3508 сессию проследили до кода: `pg_stat_activity` снят 15 раз с шагом 8 с, единственная сессия в `idle in transaction` за всё окно — одна и та же, с запросом ```sql SELECT value FROM tg_support_state WHERE key = CAST($1 AS text) ``` возраст транзакции циклически идёт 0.2 → 28.8 с и сбрасывается. Это `app/services/tgbot/bridge.py:264` внутри `run_poll_loop` (`bridge.py:969`): `with session_factory() as db:` открыт **поверх** `await client.get_updates(...)` — long-poll Telegram, около 30 секунд на цикл. То есть 29 секунд — это **тг-бот**, а не свипы, и к транзакциям длиннее часа из этой issue отношения не имеет. Я взял чужое число, приписал его своей гипотезе и выдал за подтверждение — ровно то, чего эта issue и требовала не делать («подтвердить, а не принять»). ## Что остаётся в силе - Сам факт из issue: 50 точек из 4033 за 14 суток с транзакцией дольше часа по БД `tradein`, пик 2.2 ч, у двух соседних баз того же кластера — ноль. - Окна `06:13–06:43 UTC`, закрывшиеся ровно тогда, когда дрейн завершил три прогона с точностью до секунды. Это по-прежнему указывает на свипы — но именно **указывает**, а не доказывает. - Вывод про инструменты: `statement_timeout` тут не поможет (ограничивает ОДИН statement), `idle_in_transaction_session_timeout` ронял бы long-poll тг-бота каждый цикл гарантированно — и PR #3508 сознательно его не ставит. ## Что надо сделать, чтобы назвать виновника Снять `pg_stat_activity` **в момент срабатывания тревоги** (не в произвольный момент, как вышло у меня) и сопоставить `pid`/`application_name`/`query`/`xact_start` с активным прогоном в `scrape_runs`. Плюс различать состояние: `idle in transaction` — «ждём сеть внутри транзакции», `active` — «долгий запрос». Это разные болезни с разным лечением. Кандидат «свипы» до этого замера считать **неподтверждённым**. Refs #3463, PR #3508.