Connection pooling: тест на припоминание
Промпты на свободное припоминание по всему юниту пулинга. Сначала ответь своими словами, затем раскрой модельный ответ и сравни.
Припоминание бьёт перечитывание. На каждый промпт скажи или напиши полный ответ по памяти, прежде чем открыть модельный — именно усилие припоминания закрепляет механизм так, чтобы он был под рукой в инциденте.
Восстанови по памяти позвоночник юнита — почему backend тяжёлые, что отдаёт transaction mode, как сайзить оба слоя пула, почему exhaustion — это hold-time, и чем idle-in-transaction вредит за пределами пула.
- 01Почему соединение Postgres дорогое и какие два слоя пула поглощают эту стоимость?
- 02Что даёт transaction mode PgBouncer, что он ломает и какова безопасная замена для каждой поломки?
- 03Как сайзить два слоя пула и почему pool_size — это НЕ число клиентов?
- 04Почему pool exhaustion почти всегда проблема hold-time и почему поднятие pool_size обычно не помогает?
- 05Помимо занятого слота пула, чем ещё вредит backend в idle-in-transaction и почему?
- 06Когда тянуться за пределы PgBouncer и каков фикс serverless connection storm?
Если ты смог восстановить каждый ответ по памяти — ты держишь позвоночник юнита: backend — тяжёлые процессы, поэтому существуют два слоя пула: client pool на воркер, чтобы убить per-request setup, и server pooler, чтобы мультиплексировать тысячи клиентов на число backend, размеченное под CPU через (cores × 2) + spindles. Transaction mode — дефолт мультиплексирования и торгует session-state, заданным при подключении, у каждой поломки точная замена, а PgBouncer 1.21+ возвращает prepared statements. Exhaustion — это hold-time, а не размер; idle-in-transaction вдобавок пиннит MVCC-снимок и блокирует VACUUM; и ты перерастаешь PgBouncer лишь когда измерил его однопоточный потолок или столкнулся с serverless/multi-tenant масштабом.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.