Kalkulator rozmiaru puli połączeń

Dobór puli połączeń pod wdrożenie, a nie pod średnią

Pule połączeń rzadko padają przy stabilnym obciążeniu. Padają w trakcie wdrożenia, gdy stare pody jeszcze się nie wyłączyły, a nowe już otworzyły swoje pule i zapotrzebowanie chwilowo się podwaja. To narzędzie wymnaża, o ile naprawdę prosi bazę twoja flota — w spoczynku i w tamtej chwili — i porównuje obie liczby z limitem egzekwowanym przez instancję.

Jak to działa

• Mnoży instancje aplikacji przez rozmiar puli, bo to jest liczba, którą widzi baza — a nie rozmiar puli, który skonfigurowałeś.
• Odejmuje połączenia zarezerwowane na replikację i monitoring, żebyś porównywał się z tym, co faktycznie dostępne.
• Podwaja zapotrzebowanie, modelując wdrożenie kroczące, gdy stare i nowe instancje trzymają pule jednocześnie.
• Sygnalizuje trzy stany: powyżej limitu, na tyle ciasno, że wdrożenie go przekroczy, i komfortowo.

dostępne     = max_connections - zarezerwowane
stabilne     = instancje x pula_na_instancję
podczas_wdrożenia = stabilne x 2

bezpiecznie, gdy podczas_wdrożenia <= dostępne

Przykład z liczbami

Usługa na 40 podach, każdy z pulą 20, wobec instancji z limitem 500 połączeń, z których 15 jest zarezerwowanych.

1. dostępne = 500 - 15 = 485
2. stabilne = 40 x 20 = 800 — już 165% limitu
3. zapas = 485 - 800 = -315, więc połączenia są odrzucane już teraz
4. zmniejszenie puli o połowę, do 10: stabilne = 400, czyli 82% — w spoczynku się mieści
5. ale podczas wdrożenia: 400 x 2 = 800, wciąż 165%, więc wdrożenia dalej padają
6. pula 6: stabilne = 240 (49%), wdrożenie = 480 wobec 485 — mieści się na styk

Pula, która przeżywa wdrożenie, jest trzykrotnie mniejsza od tej, która przeżywa jedynie średnią. Między krokiem drugim a szóstym nic w ruchu się nie zmieniło — tylko ustawienie puli i gotowość, by dobrać ją pod najgorszy moment, a nie typowy.

Jak czytać wynik

• Pula 6 na pod brzmi mało i wcale nie jest. Własne zalecenia HikariCP mówią, że małe pule wypadają lepiej od dużych: puli wystarczy tyle połączeń, by zająć rdzenie bazy, a chwilowe kolejkowanie w aplikacji jest tańsze niż kolejkowanie w bazie. Celem jest kilka połączeń na rdzeń w skali całej floty.
• Mnóż przez każdy proces, który otwiera pulę, nie tylko warstwę webową. Workery w tle, zadania cron, migracje, konsole administracyjne i twoja własna sesja psql czerpią z tego samego sufitu — i to są połączenia, których nikt nie liczy, dopóki sufit nie zostanie osiągnięty.
• Przyjęte tu podwojenie to typowy przypadek wdrożenia kroczącego z bramką gotowości. Wdrożenie wymieniające wszystko naraz może dać wyższy skok; wymieniające pod po podzie prawie żadnego. Jeśli twoja strategia jest inna, zmień liczbę instancji, by ją odwzorować.
• Obciążenia serverless i autoskalujące łamią tę arytmetykę całkowicie, bo liczba instancji nie jest twoją decyzją. To właśnie ten przypadek naprawdę rozwiązuje proxy — RDS Proxy, PgBouncer, Cloud SQL Auth Proxy — multipleksując wiele połączeń klienckich na niewiele bazodanowych.
• Bezczynne połączenia nie są darmowe. W PostgreSQL każde to proces trzymający pamięć, w MySQL każde niesie bufory na wątek. Hojna pula, która przeważnie stoi bezczynnie, wciąż kosztuje cię zarezerwowaną pamięć.

Częste pytania

Dlaczego podwajać zapotrzebowanie na czas wdrożenia?

Bo wdrożenie kroczące celowo się nakłada. Nowa instancja musi wystartować, otworzyć pulę i przejść kontrolę gotowości, zanim stara zostanie wygaszona, więc przez to okno obie trzymają pełne pule. Jeśli twoja platforma wymienia instancje pojedynczo, nakładanie jest mniejsze, ale tryb awarii ten sam i warto go sprawdzić.

Moja pula jest daleko poniżej limitu, a i tak widzę błędy połączeń. Dlaczego?

Zwykle coś spoza puli. Poszukaj workerów, zadań cyklicznych i doraźnych skryptów otwierających własne połączenia, migracji uruchamianej w trakcie wdrożenia oraz połączeń wyciekających z kodu, który ich nie zwraca. Pula to tylko ta część zapotrzebowania, którą skonfigurowałeś.

Czy większa pula jest szybsza?

Powyżej pewnego punktu nie — jest wolniejsza. Gdy każdy rdzeń bazy jest już zajęty, więcej równoczesnych połączeń dokłada przełączeń kontekstu i rywalizacji o blokady, a nie przepustowości. Mierzalnym skutkiem przewymiarowanej puli jest zwykle gorszy ogon opóźnień, a nie lepsza przepustowość.

Gdzie w tym miejsce dla poolera w rodzaju PgBouncera?

Między tymi dwiema liczbami. Pozwala dużej i zmiennej liczbie połączeń klienckich dzielić małą, stałą liczbę połączeń do bazy — dokładnie to, czego według tego narzędzia potrzebujesz, gdy instancji jest dużo albo ich liczba jest nieprzewidywalna. W trybie pulowania transakcji zwalnia też połączenia między zapytaniami, zamiast trzymać je przez całą sesję.