Skip to main content

Kalkulator maksymalnych połączeń bazy

Polski

Ustal, ile połączeń do bazy naprawdę dopuszcza instancja, według reguły opublikowanej przez samego dostawcę.

Dostawca
Silnik
4 vCPU · 32 GiB
db.r7g.xlarge
Domyślne maks. połączeń
3324
Sama formuła daje 3604 — RDS rezerwuje pamięć na system i własne procesy, więc rzeczywista liczba jest niższa.

Ta sama pamięć u każdego dostawcy — 32 GiB, PostgreSQL

AWS RDS
3324
Google Cloud SQL
600
Azure Flexible Server
3437

Opublikowana reguła

LEAST({DBInstanceClassMemory/9531392}, 5000)

Ile połączeń naprawdę da ci zarządzana baza danych

Każda zarządzana baza ma sufit połączeń i żadna z trzech dużych chmur nie wyznacza go tak samo. AWS wyprowadza go ze wzoru na pamięci instancji, Azure publikuje stałą tabelę dla każdego produktu, a Google Cloud SQL używa progów pamięci, które rosną skokowo. To narzędzie stosuje własną, opublikowaną regułę każdego dostawcy, żebyś zobaczył prawdziwy sufit, zanim zaprojektujesz pulę wokół domysłu.

Jak to działa

  • Stosuje udokumentowaną regułę dostawcy do wybranej instancji, a nie regułę kciuka.
  • Pokazuje obok siebie wynik wzoru AWS i wynik realistyczny, bo DBInstanceClassMemory jest mniejsze niż RAM instancji.
  • Porównuje wszystkie trzy chmury przy tej samej pamięci — tam różnice stają się nie do przeoczenia.
  • Odejmuje połączenia, które Azure rezerwuje na replikację i monitoring, więc pokazana liczba to ta, z której skorzysta aplikacja.
AWS RDS, z udokumentowanych parametrów domyślnych
  PostgreSQL   LEAST({DBInstanceClassMemory/9531392}, 5000)
  MySQL        {DBInstanceClassMemory/12582880}
  MariaDB 10.5+ LEAST({DBInstanceClassMemory/25165760}, 12000)

Azure Flexible Server
  opublikowana tabela na produkt, około 107 na GiB, limit 5000
  minus 15 zarezerwowanych na replikację i monitoring

Google Cloud SQL
  opublikowane przedziały pamięci, dolna granica włącznie
  3,75-6 GiB -> 100   6-7,5 -> 200    7,5-15 -> 400
  15-30      -> 500  30-60  -> 600   60-120 -> 800
  120+       -> 1000

Przykład z liczbami

db.r7g.xlarge z PostgreSQL — 4 vCPU i 32 GiB pamięci — oraz co te same 32 GiB kupują gdzie indziej.

  1. 32 GiB = 34 359 738 368 bajtów
  2. 34 359 738 368 / 9 531 392 = 3604 — odpowiedź wzoru
  3. limit 5000 przy tym rozmiarze nie działa, więc zostaje 3604
  4. ale DBInstanceClassMemory to nie RAM instancji: RDS najpierw odejmuje system i własne procesy
  5. po uwzględnieniu narzutu udokumentowanego przez AWS w praktyce wychodzi około 3324
  6. Azure przy 32 GiB: 3437 łącznie, 3422 dostępne po odjęciu 15 zarezerwowanych
  7. Google Cloud SQL przy 32 GiB: 600, bo 32 wpada w przedział 30-60 GiB

Identyczny sprzęt, a Cloud SQL daje jedną piątą tego, co dwie pozostałe. Jeśli przenosisz usługę między chmurami, ta jedna liczba prędzej wywróci migrację niż cokolwiek w twoim schemacie.

Jak czytać wynik

  • DBInstanceClassMemory to nie pamięć z etykiety instancji. RDS rezerwuje pamięć na system operacyjny i własne procesy zarządzające, a wzór liczy z tego, co zostaje. AWS dokumentuje tę różnicę przykładem: instancja 8 GiB daje około 630 połączeń, podczas gdy naiwne dzielenie daje 683. To około 8% mniej i dotyczy każdego rozmiaru.
  • Google Cloud SQL używa opublikowanych przedziałów, a nie wzoru, więc limit nie rośnie płynnie z pamięcią — wewnątrz przedziału nie rośnie wcale. Każda instancja od 30 GiB do tuż poniżej 60 GiB dostaje te same 600 połączeń, więc podwojenie pamięci w obrębie przedziału nie daje nic, a cały przyrost następuje na granicy.
  • Azure traktuje B1ms wyjątkowo, ustalając 50 połączeń poza skądinąd spójnym wzorcem na GiB. Dlatego to narzędzie odtwarza tabelę Azure dosłownie, zamiast dopasowywać do niej prostą.
  • To są wartości domyślne, a nie twarde limity. max_connections jest parametrem modyfikowalnym we wszystkich trzech chmurach. Podnoszenie go zwykle nie jest właściwą naprawą, bo każde połączenie kosztuje pamięć i proces obsługi — właśnie dlatego domyślna wartość zależy od pamięci.
  • Limit połączeń to nie cel współbieżności. Postgres nie przyspiesza wraz ze wzrostem liczby połączeń; powyżej mniej więcej kilkukrotności liczby rdzeni więcej połączeń oznacza więcej przełączeń kontekstu i mniejszą przepustowość. Używaj poolera i trzymaj pulę wyraźnie poniżej sufitu.

Częste pytania

Dlaczego moja instancja raportuje inne max_connections niż to?
Trzy częste powody. Grupa parametrów mogła zostać zmieniona i wtedy twoja wartość całkowicie nadpisuje wzór. Znaczenie ma wersja silnika — MariaDB zmieniła dzielnik w 10.5. A w AWS liczba nieco się przesuwa wraz z dokładną pamięcią raportowaną przez host, dlatego to narzędzie pokazuje i wynik wzoru, i wynik realistyczny.
Czy po prostu podnieść max_connections?
Zwykle nie. Każde połączenie PostgreSQL to osobny proces z własną pamięcią, a każde połączenie MySQL niesie bufory na wątek. Podniesienie sufitu przenosi awarię z odrzucanych połączeń, które są widoczne i odwracalne, na presję pamięciową i OOM killera, które nie są ani jednym, ani drugim. Pooler połączeń to niemal zawsze lepsza odpowiedź.
Czy replika do odczytu ma ten sam limit?
Ma limit wynikający z własnej klasy instancji, często ten sam, bo repliki zwykle odpowiadają instancji głównej. Ale połączenia repliki liczą się osobno, więc kierowanie odczytów na replikę naprawdę kupuje zapas na instancji głównej, a nie tylko przesuwa problem.
Dlaczego Cloud SQL ma tak nisko?
Google dobiera domyślną wartość do tego, co instancja obsłuży dobrze, a nie do tego, co technicznie przyjmie, i zakłada, że obciążenia z wieloma połączeniami siedzą za poolerem. Ta liczba to decyzja projektowa, nie ograniczenie sprzętu — ale jest egzekwowana, więc i tak cię ogranicza.

Źródła