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.

Dane

Szybkie przykłady:

Wynik

Wprowadź dane i kliknij Oblicz.

Jak to działa?

Pool połączeń DB w tym kalkulatorze 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. Kalkulator 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. Kalkulator 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ć

  1. Wpisz 8 rdzeni, 3 instancje i limit 100.
  2. Kliknij Oblicz. Wynik to 51.
  3. 4 i 2 dają 18. 16 i 4 dają 132.
  4. To heurystyka, nie live max_connections.
  5. Sąsiednia kalkulator 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 1

  • 8 rdzeni
  • 3 instancje
  • limit 100

51

Jaki pool przy 8 rdzeniach i 3 instancjach? 51. Heurystyka, nie live DB.

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

Kalkulator limitów API (rate limit)

Kalkulator limitów API (rate limit): limit, jednostkę i okno.

Użyj kalkulatora →

Cache hit ratio

Cache hit ratio: trafienia i chybienia.

Użyj kalkulatora →

IOPS i throughput dysku

IOPS i throughput dysku: ms, blok KB i równoległość.

Użyj kalkulatora →

Error budget (SRE)

Error budget (SRE): SLO, dni okresu i zużyte minuty.

Użyj kalkulatora →

Wszystkie kalkulatory IT

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. Kalkulator 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.

Źródła wiedzy

Kalkulator liczy bity, bajty albo przepustowość z Twoich liczb. Poniżej definicje bitu i SI (GUM).

Strona zaktualizowana w 2026.

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.