Przykład 1
- 8 rdzeni
- 3 instancje
- limit 100
51
Jaki pool przy 8 rdzeniach i 3 instancjach? 51. Heurystyka, nie live DB.
Pool połączeń DB
Wpisz rdzenie, instancje i opcjonalny limit. 8 i 3 dają 51. 4 i 2 dają 18. 16 i 4 dają 132. To (rdzenie×2+1)×instancje, nie sonda PostgreSQL.
To heurystyka PostgreSQL rdzenie×2+1 na instancję, nie odczyt max_connections. Limit requestów jest na limitach API.
Wynik
Wprowadź dane i kliknij Oblicz.
Jak to działa?
Pool połączeń DB na tej karcie mnoży heurystykę przez instancje. 8 rdzeni i 3 instancje dają 51. 4 i 2 dają 18. 16 i 4 dają 132. Wzór to (rdzenie × 2 + 1) × instancje. Karta nie czyta max_connections z serwera.
Pole db-cores to rdzenie. Pole db-inst to instancje aplikacji. Pole db-max-conn jest opcjonalnym limitem. 8 × 2 + 1 = 17, razy 3 daje 51. 4 × 2 + 1 = 9, razy 2 daje 18. 16 × 2 + 1 = 33, razy 4 daje 132.
51 nie schodzi z pg_settings. 18 nie jest PgBouncer. 132 przy limicie 100 tylko pokazuje, że szkic przekracza wpisany sufit. Karta nie loguje się do bazy.
Cache hit ratio obok liczy requesty. Limity API liczą okno. Tu 8 i 3 zostają 51, sam pool ze wzoru.
Wpisz 8, 3 i 100, potem Oblicz. Wynik to 51. Przecinek nie jest potrzebny, pola są całkowite. Zero w rdzeniach nie daje poolu.
8 i 3 dają 51. 4 i 2 dają 18. 16 i 4 dają 132. Inna liczba instancji przy 8 zmienia 51.
Wzór
pool = (rdzenie × 2 + 1) × instancje. Limit db-max-conn jest wpisanym sufitem, nie sondą.
Jak korzystać
- Wpisz 8 rdzeni, 3 instancje i limit 100.
- Kliknij Oblicz. Wynik to 51.
- 4 i 2 dają 18. 16 i 4 dają 132.
- To heurystyka, nie live max_connections.
- Sąsiednia karta liczy okno API, nie pool.
8 i 3 dają 51
Pool = (rdzenie × 2 + 1) × instancje. 8 i 3 dają 51. To nie live DB.
- Pool
- Wynik karty. 8 rdzeni i 3 instancje zostawiają 51.
- połączeń
- Szkic ze wzoru. 4 i 2 dają 18. Nie pg_settings.
- DB
- Twoje liczby, nie sonda. 16 i 4 dają 132. Nie max_connections.
Przykłady
Przykład 2
- 4 rdzenie
- 2 instancje
- limit 200
18
Jaki pool przy 4 i 2? 18.
Przykład 3
- 16 rdzeni
- 4 instancje
- limit 100
132
Jaki pool przy 16 i 4? 132. Szkic, nie sonda max_connections.
Powiązane kalkulatory
Najczęstsze pytania
Jaki pool przy 8 rdzeniach i 3 instancjach?
51. (8 × 2 + 1) × 3. Heurystyka, nie live DB.
Ile przy 4 i 2?
18. (4 × 2 + 1) × 2.
Ile przy 16 i 4?
132. (16 × 2 + 1) × 4.
Czy to max_connections z PostgreSQL?
Nie. Karta nie łączy się z bazą. Limit wpisujesz sam.
Po co pole limitu 100?
To wpisany sufit. 51 mieści się w 100. 132 przy 100 tylko porównuje szkic.
Czy 51 to PgBouncer?
Nie. Sam wzór rdzenie×2+1 razy instancje.
Czy zero w rdzeniach liczy?
Nie. Rdzenie i instancje muszą być dodatnie.
Czym to różni się od limitów API?
Tam 60 i 15 min dają 900. Tu 8 i 3 dają 51.
Czy przecinek w 8,5 działa?
Pole jest całkowite. Przykłady trzymają 8, 4 i 16.
Czym jest pool połączeń
Pool to zestaw wcześniej otwartych połączeń do bazy, które aplikacja pożycza i oddaje zamiast otwierać TCP + auth przy każdym zapytaniu. Ten kalkulator stosuje heurystykę rdzenie × 2 + 1 na instancję i — jeśli podasz max_connections — sprawdza, czy łączny pool nie wybucha limitu bazy.
Za mały pool: kolejki i timeouty
Gdy równoległych żądań jest więcej niż wolnych połączeń, wątki czekają w kolejce poola. Objawy: rosnąca latencja p95/p99, timeouty „connection acquisition”, spadek RPS mimo wolnego CPU aplikacji.
Przykład: 80 równoległych requestów potrzebujących DB, pool=20 → większość czeka. Podniesienie poola (w granicach limitu bazy) często usuwa timeouty — o ile baza ma IOPS/CPU na obsługę większej równoległości.
Za duży pool: kontencja i max_connections
- Każde połączenie zużywa pamięć po stronie DB.
- Zbyt wiele równoległych zapytań zwiększa blokady i context switch — przepustowość może spaść.
- Przekroczenie
max_connections= błędy „too many connections” dla nowych klientów.
Wzorce: web, API, mikrousługi
- Monolit / kilka instancji — heurystyka per instancja × N zwykle wystarcza; zostaw margines na admin/monitoring.
- API o wysokim RPS — łącz z limitem rate; więcej ruchu ≠ automatycznie większy pool, jeśli zapytania są krótkie i dobrze zindeksowane.
- Mikrousługi / autoscaling — N podów × pool łatwo przebija limit bazy → PgBouncer / ProxySQL lub wspólny pool po stronie proxy.
Przykłady
- 8 rdzeni × 3 instancje → 17 na instancję, pool łączny 51.
- Pool 20, ruch 80 równoległych DB calli → typowe kolejki/timeouty; zwiększenie do ~40 (jeśli max_connections pozwala) zwykle zmniejsza błędy oczekiwania.
- 16 rdzeni × 5 instancji, max_connections=100 → zalecane 165 → za duży; trzeba ciąć pool, mniej replik albo proxy pooling.
FAQ — pool połączeń DB
- Co się dzieje, gdy pool jest za mały?
- Żądania czekają na wolne połączenie: rośnie latencja, pojawiają się timeouty acquisition, spada RPS mimo wolnego CPU aplikacji.
- Co się dzieje, gdy pool jest za duży?
- Baza zużywa więcej RAM, rośnie kontencja zapytań i ryzyko „too many connections”, bez realnego zysku przepustowości.
- Jak powiązać pool z ruchem i rate limitem?
- Peak równoległych żądań DB ≈ ruch × czas trzymania połączenia. Rate limit ogranicza napływ; pool musi obsłużyć szczyt równoległości, nie „średni RPS” w izolacji.
- Czy mogę ustawić max_connections bardzo wysoko?
- Technicznie tak, ale każde połączenie kosztuje pamięć i zwiększa ryzyko przeciążenia. Lepiej trzymać sensowny limit + proxy pooling niż „nieskończony” ceiling.
- Czy rdzenie×2+1 to twarda reguła?
- To heurystyka startowa (PostgreSQL/HikariCP), nie prawo fizyki — dopasuj pod typ zapytań i pomiary.
- Kiedy potrzebuję PgBouncer?
- Gdy wiele instancji/podów mnoży połączenia ponad limit bazy, albo gdy chcesz mieć duży logiczny pool aplikacji przy małym realnym poolu do DB.
- Czy zostawić zapas w max_connections?
- Tak — miejsce na admin, migracje, monitoring i inne usługi dzielące tę samą bazę.
- Czy repliki odczytu zmieniają sizing?
- Tak — licz osobno pool do primary (zapisy) i do replik (odczyty), zamiast jednego sumarycznego limitu.