Недавно разбирала кейс: в pgx пуле резко выросло количество соединений, условно с 10 до 80. Но RPS вырос совсем немного, поэтому объяснение типа "стало больше запросов, значит нужно больше коннектов" не совсем сходилось.
Потому что количество занятых коннектов зависит не только от того, сколько запросов приходит, но и от того, как долго каждый запрос удерживает соединение (находится в состояния acquired) внутри пула:
busy concurrent connections ≈ RPS × connection hold (acquired) time
Например, имея 100 RPS и 100 ms времени удержания коннекта мы получим 10 одновременно занятых коннектов.
А если RPS вырос до 160, но коннект из-за внутренней задержки стал удерживаться 500 ms, то получается: 160 RPS × 500 ms = 80 одновременно занятых коннектов
В итоге пул выглядит так, будто нагрузка выросла в 8 раз, хотя RPS не сильно вырос.
Главное, что нужно запомнить: коннект считается занятым с момента, когда приложение получило его из пула, и до момента, когда вернуло обратно.
Это если воспроизводить цепочку событий:
запросы приходят
↓
старые соединения дольше не освобождаются
↓
idle коннектов почти нет
↓
если idle коннектов нет, pgx еще не дошел до MaxConns и начинает создавать новые
↓
pool доходит до лимита
↓
новые запросы ждут свободный коннект
↓
растет AcquireDuration
↓
растет общий RT приложения
В моем случае pgx коннект мог быть уже получен, но дальше запрос может ждать свободное серверное соединение внутри своего пулера (Odyssey, PGBouncer, etc). Для pgx такой коннект уже занят, поэтому метрика типо AcquiredConns может расти, а IdleConns падать.
При этом AcquireDuration сначала может быть нормальной. Она начнет расти позже, к моменту когда из-за таких долгих удержаний коннектов уже закончится сам pgx пул.
Итого, сам по себе кейс вышел самым банальным: чтобы понять резкое увеличение коннектов при небольшом росте RPS, нужно ответить на вопрос, почему коннект стал удерживаться дольше.
А там уже может быть все разнообразие причин, начиная с ожидания внутри пулера и заканчивая самими запросами.
#db #perf