Базы данных
Connection pooling: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту: процессная модель, режимы PgBouncer, математика размера, exhaustion против idle-in-transaction и выбор пулера.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь в 02:14 под звон пейджера — не определение для заучивания, а компромисс, который надо взвесить, когда пул пуст, а cl_waiting растёт.
Цель
Убедись, что связываешь процессную модель Postgres, режимы PgBouncer, математику размера, hold-time как корневую причину exhaustion и выбор пулера — тот синтез, к которому вели семь уроков.
Викторина
Completed
Команда держит 40 воркеров приложения, у каждого client pool max 20, против Postgres с max_connections = 100. Подключаются напрямую (без PgBouncer) и ловят 'FATAL: sorry, too many clients already'. Каков настоящий фикс?
Heads-up Каждый backend — это OS-процесс ~10 МБ; 800 активных backend пред-аллоцируют сотни МБ shared memory и уводят машину за пик пропускной способности. Поднятие лимита переносит симптом и нелинейно деградирует throughput.
Heads-up Урезание каждого воркера до 2 соединений калечит внутреннюю конкурентность; правильный размер на воркер берётся из формулы конкурентности, а кластерный лимит решается пулером, а не недосайзингом каждого воркера.
Heads-up Это ручка кучи Go, не имеющая отношения к числу backend Postgres. Ограничение тут — max_connections, который server-side pooler и существует, чтобы обойти.
Викторина
Completed
Приложение на PgBouncer session mode переключается в transaction mode ради мультиплексирования. `SET search_path = 'app, public'`, выданный один раз при подключении, тихо перестаёт действовать. Почему и каков правильный фикс?
Heads-up PgBouncer не кэширует и не интерпретирует SET; он лишь маршрутизирует каждую транзакцию на свободный backend. SET при подключении невидим для backend, которые его не выполняли.
Heads-up SET не отклоняется — он успешен на том backend, что его выполнил. Проблема в том, что следующая транзакция уже на другом backend, и эффект не сохраняется.
Heads-up Регистр тут ни при чём; корневая причина — модель аренды backend на транзакцию, ломающая session-state, заданный при подключении.
Викторина
Completed
16-ядерный Postgres (NVMe, рабочий набор в RAM) за PgBouncer. Инженер ставит default_pool_size = 200, чтобы 'покрыть пиковую конкурентность', и p99 ухудшается. Каков оптимальный по throughput pool_size и почему?
Heads-up Больше backend за (cores × 2) снижают throughput: каждая выдача снимка O(active_backends), а context-switch плюс contention shared memory растут суперлинейно. Регрессия p99 и есть симптом оверсайзинга.
Heads-up Это не формула сайзинга — max_connections — жёсткий лимит, не связанный с оптимумом throughput по CPU. pool_size выводится из ядер и параллелизма хранилища, а не из лимита.
Heads-up Чистый ×1 недосайзит для смешанного OLTP, где backend проводят время на I/O и lock-ожиданиях; множитель ×2 плюс запас на всплеск — стандартная стартовая точка. ×1 верен лишь для чисто CPU-bound миксов запросов.
Викторина
Completed
В 02:14 PgBouncer показывает pool = 24, cl_waiting = 180, приложение отдаёт 503. pg_stat_activity показывает 19 backend в состоянии 'idle in transaction' с максимальным возрастом транзакции 8 минут. Утром пул был размечен верно. Что происходит?
Heads-up Поднятие pool_size даёт больше backend, удерживаемых теми же зависшими транзакциями — больше contention proc-array, тот же hold-time. Соединения держатся слишком долго, а не их слишком мало; это маскирует причину.
Heads-up Postgres работает корректно; backend сидят idle-in-transaction в ожидании приложения, а не падают на планировании. База ждёт приложение, а не наоборот.
Heads-up TCP-exhaustion редок на таких масштабах и проявился бы ошибками уровня соединения, а не backend, сидящими idle-in-transaction со старым xact_start. Сигнал прямо указывает на удерживаемые транзакции.
Викторина
Completed
Команда на PgBouncer 1.20 отключила prepared statements драйвера, чтобы избежать ошибок 'prepared statement does not exist' в transaction mode, потеряв ~20% throughput. В 2026 они хотят И мультиплексирование transaction mode, И prepared statements. Что это разблокирует?
Heads-up Такого pool mode нет. Три режима — session, transaction и statement; поддержка prepared statements включается через max_prepared_statements внутри transaction mode.
Heads-up server_reset_query запускает SQL-команду очистки между арендами клиентов (напр. DISCARD ALL); к разрешению prepared statements отношения не имеет.
Heads-up Session mode действительно сохраняет prepared statements, но отбрасывает всё мультиплексирование — ровно тот выигрыш, что они пытаются удержать. PgBouncer 1.21+ даёт оба сразу.
Викторина
Completed
Multi-tenant B2B SaaS: 10 000 баз-арендаторов, ~50 одновременных пользователей в каждой, serverless-функции с cold-start под нагрузкой. PgBouncer на одной ноде упирает одно ядро CPU, а cold-старты вызывают connection storm. Какая архитектура подходит?
Heads-up 10 000 однопоточных PgBouncer — операционный кошмар, и проблема serverless storm всё равно не решена. Scale-out пулер спроектирован именно под этот multi-tenant случай.
Heads-up PgBouncer однопоточный — полмиллиона входящих клиентов через один event loop насытят одно ядро задолго до этого. Лимит — это число входящих, а не значение конфига.
Heads-up 10 000 арендаторов × 50 пользователей — до 500 000 потенциальных соединений; каждый cold-старт форкает backend ~10 МБ, и storm исчерпывают max_connections. Colocated-пулер обязан поглотить всплеск.
Итог
Сквозная линия юнита — одна цепочка: Postgres форкает тяжёлый процесс на соединение, поэтому число backend должно держаться около (cores × 2) — что и обеспечивает пулер, мультиплексируя тысячи дешёвых клиентских соединений в transaction mode. Transaction mode стоит тебе session-state, заданного при подключении (SET, LISTEN, SQL PREPARE, session advisory locks), у каждого есть точная безопасная замена, а PgBouncer 1.21+ наконец делает prepared statements совместимыми. Когда пул пустеет, причина почти всегда hold-time — медленный запрос или внешний вызов внутри транзакции — а не размер; idle_in_transaction_session_timeout — бесплатная страховка. Тянись за пределы PgBouncer лишь когда измерил его однопоточный потолок или столкнулся с serverless/multi-tenant масштабом.