Poolowanie połączeń PostgreSQL: pool aplikacyjny vs PgBouncer

Dlaczego skoki opóźnień często zaczynają się od połączeń

Połączenie do bazy danych to jak linia telefoniczna między aplikacją a Postgresem. Otwarcie go kosztuje czas i zasoby po obu stronach: nawiązanie TCP/TLS, uwierzytelnianie, pamięć i proces backendu po stronie Postgresa. Pula połączeń utrzymuje mały zestaw tych „linii telefonicznych” otwartych, żeby aplikacja mogła je ponownie wykorzystać zamiast wybierać numer za każdym żądaniem.

Gdy poolowanie jest wyłączone lub źle skalibrowane, rzadko najpierw zobaczysz prosty błąd. Pojawiają się losowe spowolnienia. Żądania, które zwykle trwają 20–50 ms, nagle zajmują 500 ms lub 5 sekund, p95 rośnie. Potem pojawiają się timeouty, a później „too many connections” albo kolejka w aplikacji, która czeka na wolne połączenie.

Limity połączeń mają znaczenie nawet dla małych aplikacji, bo ruch jest skokowy. Mail marketingowy, cron lub kilka wolnych endpointów może spowodować, że dziesiątki żądań uderzą w bazę jednocześnie. Jeśli każde żądanie otwiera nowe połączenie, Postgres może zużywać znaczną część swojej mocy na akceptowanie i zarządzanie połączeniami zamiast wykonywać zapytania. Z drugiej strony, jeśli masz pulę, ale jest zbyt duża, możesz przeciążyć Postgresa zbyt wieloma aktywnymi backendami, co prowadzi do przełączeń kontekstu i presji pamięci.

Szukaj wczesnych symptomów, takich jak:

• skoki p95/p99 podczas gdy średnia wygląda w porządku
• timeouty skupione podczas skoków ruchu
• rosnący czas „waiting for connection” w aplikacji
• częste łączenia/rozłączania lub saturacja połączeń po stronie Postgresa

Poolowanie zmniejsza churn połączeń i pomaga Postgresowi obsłużyć skoki. Nie naprawi wolnych zapytań SQL. Jeśli zapytanie robi pełny skan tabeli lub czeka na blokadę, poolowanie głównie zmienia sposób, w jaki system pada (kolejkowanie wcześniej, timeouty później), a nie to, czy będzie szybki.

Pool w aplikacji vs PgBouncer: jaki problem każdy z nich rozwiązuje

Poolowanie połączeń polega na kontrolowaniu, ile połączeń do bazy istnieje jednocześnie i jak są ponownie używane. Możesz to robić w aplikacji (pool na poziomie aplikacji) lub z osobną usługą przed Postgresem (PgBouncer). Rozwiązują one powiązane, ale różne problemy.

Pool na poziomie aplikacji (w Go zwykle wbudowany database/sql) zarządza połączeniami na proces. Decyduje, kiedy otworzyć nowe połączenie, kiedy je ponownie wykorzystać i kiedy zamknąć nieaktywne. Dzięki temu unikasz kosztu zestawiania połączenia przy każdym żądaniu. Nie potrafi jednak skoordynować się między wieloma instancjami aplikacji. Jeśli uruchomisz 10 replik, masz efektywnie 10 oddzielnych pul.

PgBouncer stoi między aplikacją a Postgresem i pooluje połączenia w imieniu wielu klientów. Jest najbardziej przydatny, gdy masz dużo krótkotrwałych żądań, wiele instancji aplikacji lub skokowy ruch. Ogranicza połączenia po stronie serwera do Postgresa nawet gdy setki połączeń klienckich przychodzą naraz.

Prosty podział odpowiedzialności:

• Pool w aplikacji kształtuje współbieżność w obrębie jednej instancji i unika ponownego łączenia przy każdym żądaniu.
• PgBouncer ogranicza łączną liczbę połączeń do Postgresa we wszystkich instancjach i wygładza skoki.
• Postgres nadal ma twarde limity CPU, IO i pamięci. Poolowanie nie tworzy dodatkowej pojemności.

Mogą współpracować razem bez problemów z „podwójnym poolowaniem”, o ile każda warstwa ma jasny cel: rozsądna pula database/sql na proces Go oraz PgBouncer wymuszający globalny budżet połączeń.

Częstym błędnym przekonaniem jest myślenie „więcej pul to więcej pojemności”. Zwykle oznacza odwrotnie. Jeśli każda usługa, worker i replika ma własną dużą pulę, łączna liczba połączeń może eksplodować i spowodować kolejki, przełączanie kontekstu i nagłe skoki opóźnień.

Jak database/sql w Go naprawdę się zachowuje

W Go sql.DB to menedżer puli połączeń, a nie pojedyncze połączenie. Gdy wywołujesz db.Query lub db.Exec, database/sql próbuje ponownie użyć nieaktywnego połączenia. Jeśli nie może, może otworzyć nowe (do ustawionego limitu) lub sprawić, że żądanie poczeka.

To oczekiwanie jest źródłem „tajemniczych opóźnień”. Gdy pula jest zapełniona, żądania kolejkują się wewnątrz aplikacji. Z zewnątrz wygląda to jakby Postgres stał się wolny, ale w rzeczywistości czas jest spędzany na czekaniu na wolne połączenie.

Najważniejsze pokrętła

Większość strojenia sprowadza się do czterech ustawień:

• MaxOpenConns: twardy limit otwartych połączeń (idle + używane). Po jego osiągnięciu wywołujący blokują się.
• MaxIdleConns: ile połączeń może czekać gotowych do ponownego użycia. Zbyt niska wartość powoduje częste ponowne łączenia.
• ConnMaxLifetime: wymusza okresowe odnawianie połączeń. Przydaje się przy load balancerach i timeoutach NAT, ale zbyt niska wartość wywołuje churn.
• ConnMaxIdleTime: zamyka połączenia, które długo stoją nieużywane.

Ponowne użycie połączeń zwykle obniża opóźnienia i zużycie CPU w bazie, bo unikasz powtarzanych ustawiań (TCP/TLS, auth, inicjalizacja sesji). Ale przesadnie duża pula może robić odwrotnie: pozwala na więcej jednoczesnych zapytań niż Postgres potrafi sprawnie obsłużyć, co zwiększa contentię i narzut.

Myśl w kategoriach sumarycznych, nie na proces. Jeżeli każda instancja Go dopuszcza 50 otwartych połączeń, a skaluje się do 20 instancji, efektywnie pozwoliłeś na 1 000 połączeń. Porównaj tę liczbę z tym, co twoja instancja Postgresa może obsłużyć komfortowo.

Praktyczny punkt startowy to powiązać MaxOpenConns z oczekiwaną współbieżnością na instancję, a potem weryfikować to metrykami puli (in-use, idle, wait time) zanim podniesiesz limit.

Podstawy PgBouncer i tryby poolowania

PgBouncer to mały proxy między aplikacją a PostgreSQL. Twoja usługa łączy się z PgBouncerem, a on utrzymuje ograniczoną liczbę prawdziwych połączeń serwera do Postgresa. Podczas szczytów PgBouncer kolejkowuje pracę klientów zamiast natychmiast tworzyć więcej backendów Postgresa. Ta kolejka może decydować o różnicy między kontrolowanym spowolnieniem a przeciążeniem bazy.

Trzy tryby poolowania

PgBouncer ma trzy tryby poolowania:

• Session pooling: klient trzyma to samo połączenie serwera przez cały czas, gdy jest podłączony.
• Transaction pooling: klient „pożycza” połączenie serwera na czas trwania transakcji, potem je zwraca.
• Statement pooling: klient pożycza połączenie serwera na pojedyncze zapytanie.

Session pooling zachowuje się najbardziej podobnie do bezpośrednich połączeń do Postgresa. Jest najmniej zaskakujący, ale oszczędza mniej połączeń serwerowych przy skokowym obciążeniu.

Co zwykle pasuje do API w Go

Dla typowych API HTTP w Go, transaction pooling często jest dobrym domyślnym wyborem. Większość żądań wykonuje krótkie zapytanie lub krótką transakcję, po czym kończy. Transaction pooling pozwala wielu klientom dzielić mniejszy budżet połączeń Postgresa.

Wadą jest stan sesji. W trybie transaction wszystko, co zakłada utrzymanie tego samego połączenia serwera, może się zepsuć lub zachowywać dziwnie, w tym:

• przygotowane zapytania tworzone raz i używane później
• ustawienia sesji, które oczekujesz, że przetrwają (SET, SET ROLE, search_path)
• tymczasowe tabele i advisory locks używane między zapytaniami

Jeśli aplikacja polega na takim stanie, bezpieczniejszy jest session pooling. Statement pooling jest najbardziej restrykcyjny i rzadko pasuje do aplikacji webowych.

Przydatna zasada: jeśli każde żądanie może ustawić, czego potrzebuje, wewnątrz jednej transakcji, transaction pooling utrzyma opóźnienia bardziej stabilne przy obciążeniu. Jeśli potrzebujesz długotrwałego zachowania sesji, użyj session pooling i skup się na ścisłych limitach w aplikacji.

Jak wybrać właściwą strategię dla backendu Go

Jeśli uruchamiasz usługę Go z database/sql, to już masz pool po stronie aplikacji. Dla wielu zespołów to wystarcza: kilka instancji, stabilny ruch i zapytania, które nie są ekstremalnie skokowe. W takim scenariuszu najprostszy i najbezpieczniejszy wybór to dopracować pulę Go, utrzymać realistyczny limit połączeń i na tym poprzestać.

PgBouncer pomaga najbardziej, gdy baza jest uderzana przez zbyt wiele połączeń klienckich naraz. Objawia się to wieloma instancjami aplikacji (lub skalowaniem serverless), skokowym ruchem i dużą liczbą krótkich zapytań.

PgBouncer może też zaszkodzić, jeśli użyjesz go w złym trybie. Jeśli twój kod polega na stanie sesji (tymczasowe tabele, przygotowane zapytania wykorzystywane między żądaniami, advisory locks trzymane między wywołaniami, ustawienia na poziomie sesji), transaction pooling może powodować mylące błędy. Jeśli naprawdę potrzebujesz zachowania sesji, użyj session pooling lub pomiń PgBouncer i starannie dobierz rozmiary pul aplikacyjnych.

Prosta reguła decyzyjna

Użyj tej reguły:

• Jeśli masz 1–3 instancje aplikacji i łączne otwarte połączenia mieszczą się z zapasem w limicie bazy, używaj tylko poolowania w aplikacji.
• Jeśli masz wiele instancji lub autoskalowanie, a suma maksymalnych otwartych połączeń może przekroczyć to, co Postgres obsłuży, dodaj PgBouncer.
• Jeśli większość żądań jest krótka (szybkie odczyty, małe zapisy), PgBouncer zwykle się opłaca.
• Jeśli żądania trzymają połączenia długo (wolne raporty, długie transakcje), najpierw napraw zapytania i bądź ostrożny z rozmiarami puli.

Krok po kroku: jak bezpiecznie dobrać rozmiary i wdrażać poolowanie

Limity połączeń to budżet. Jeśli wydasz go wszystko naraz, każde nowe żądanie będzie czekać i ogonowe opóźnienia skoczą. Celem jest ograniczyć współbieżność w kontrolowany sposób, przy zachowaniu stałego przepływu.

Praktyczna sekwencja wdrożenia

1. Zmierz dzisiejsze szczyty i opóźnienia ogonowe. Zarejestruj maksymalne aktywne połączenia (nie średnie), oraz p50/p95/p99 dla żądań i kluczowych zapytań. Zauważ błędy połączeń i timeouty.

2. Ustal bezpieczny budżet połączeń Postgresa dla aplikacji. Zacznij od max_connections i odejmij miejsce na dostęp administracyjny, migracje, zadania tła i skoki. Jeśli wiele usług dzieli bazę, celowo podziel budżet.

3. Mapuj budżet na limity Go na instancję. Podziel budżet aplikacji przez liczbę instancji i ustaw MaxOpenConns na tę wartość (lub nieco niższą). Ustaw MaxIdleConns wystarczająco wysoko, by unikać ciągłych ponownych połączeń, a czasy życia tak, by połączenia były okresowo odnawiane bez churnu.

4. Dodaj PgBouncer tylko jeśli jest potrzebny i wybierz tryb. Użyj session pooling, jeśli potrzebujesz stanu sesji. Wybierz transaction pooling, gdy chcesz największego zmniejszenia połączeń serwera i gdy aplikacja jest kompatybilna.

5. Wdrażaj stopniowo i porównuj przed i po. Zmieniaj pojedyncze elementy, stosuj canary i porównuj opóźnienia ogonowe, czas oczekiwania w puli oraz CPU bazy.

Przykład: jeśli Postgres może bezpiecznie przydzielić twojej usłudze 200 połączeń, a masz 10 instancji Go, zacznij od MaxOpenConns=15-18 na instancję. To zostawia zapas na skoki i zmniejsza szansę, że każda instancja jednocześnie osiągnie limit.

Metryki, które warto obserwować, żeby złapać problem wcześnie

Problemy z poolowaniem rzadko zaczynają się od „za dużo połączeń”. Częściej widzisz powolny wzrost czasu oczekiwania, a potem nagły skok p95 i p99.

Zacznij od tego, co raportuje twoja aplikacja Go. W database/sql monitoruj: open connections, in-use, idle, wait count i wait time. Jeśli rośnie wait count przy stałym ruchu, pula jest za mała lub połączenia są trzymane zbyt długo.

Po stronie bazy śledź aktywne połączenia vs max, CPU i aktywność blokad. Jeśli CPU jest niskie, a opóźnienia wysokie, często jest to kolejka lub blokady, a nie surowa moc obliczeniowa.

Jeśli masz PgBouncer, dodaj trzeci widok: połączenia klienta, połączenia serwera do Postgresa i głębokość kolejki. Rosnąca kolejka przy stabilnej liczbie połączeń serwera to jasny sygnał, że budżet jest nasycony.

Dobre sygnały alarmowe:

• p95/p99 rośnie, podczas gdy p50 zostaje normalne
• czas oczekiwania na połączenie rośnie (po stronie aplikacji), szczególnie przed timeoutami
• kolejka w PgBouncer rośnie szybciej niż się opróżnia
• liczba błędów i timeoutów rośnie razem
• wzrost blokad wraz z długotrwałymi zapytaniami

Typowe błędy konfiguracji, które powodują skoki

Problemy z poolowaniem często pojawiają się podczas skoków: żądania gromadzą się czekając na połączenie, potem wszystko znów wygląda dobrze. Przyczyną jest często ustawienie, które jest rozsądne na jednej instancji, ale niebezpieczne przy wielu kopiach usługi.

Typowe przyczyny:

• MaxOpenConns ustawione na instancję bez globalnego budżetu. 100 połączeń na instancję * 20 instancji = 2000 potencjalnych połączeń.
• Zbyt dużo połączeń idle. Nawet nieaktywne backendy zużywają pamięć i mogą wyprzeć inną pracę.
• ConnMaxLifetime / ConnMaxIdleTime ustawione zbyt nisko. To może wywołać burzę ponownych połączeń, gdy wiele połączeń się jednocześnie odnawia.
• PgBouncer w trybie transaction przy kodzie zależnym od sesji. Tymczasowe tabele, advisory locks i ustawienia sesji mogą się psuć subtelnie.
• Zadania tła i health checki generujące skoki. Pingi w bardzo krótkim interwale lub wzorzec „otwórz i zamknij na żądanie” mogą tworzyć fale nowych połączeń.

Prosty sposób na zmniejszenie skoków to traktować poolowanie jako limit współdzielony, a nie domyślny lokalny: ogranicz łączne połączenia we wszystkich instancjach, trzymaj umiarkowaną pulę idle i używaj czasów życia dostatecznie długich, by uniknąć zsynchronizowanych reconnectów.

Co robić, gdy zapotrzebowanie przekracza budżet połączeń

Gdy ruch rośnie, zwykle widzisz jedno z trzech: żądania kolejkują się czekając na wolne połączenie, żądania timeoutują lub wszystko zwalnia tak bardzo, że retry-e się kumulują.

Kolejkowanie jest podstępne. Twój handler nadal działa, ale jest zatrzymany, czekając na połączenie. Ten czas oczekiwania staje się częścią czasu odpowiedzi, więc mała pula może zamienić zapytanie 50 ms w wielosekundowe opóźnienie pod obciążeniem.

Przydatny model mentalny: jeśli pula ma 30 użytecznych połączeń, a nagle masz 300 równoczesnych żądań potrzebujących bazy, 270 z nich musi czekać. Jeśli każde żądanie trzyma połączenie przez 100 ms, opóźnienia ogonowe szybko skoczą do sekund.

Ustal jasny budżet timeoutów i trzymaj się go. Timeout aplikacji powinien być nieco krótszy niż timeout bazy, żebyś szybko porzucał pracę i zmniejszał presję, zamiast pozwalać jej wisieć.

• Aplikacja: deadline żądania oraz krótszy deadline wokół wywołania DB
• Baza: statement_timeout, żeby jedno złe zapytanie nie blokowało połączeń
• Pooler (jeśli użyty): timeout oczekiwania w puli, aby otrzymać odmowę zamiast nieskończonego kolejkowania

Dodaj też mechanizmy backpressure, żeby nie przeciążać puli. Wybierz 1–2 przewidywalne mechanizmy: ograniczenie współbieżności na endpoint, odrzucanie nadmiaru (429) lub wydzielenie zadań tła.

Na koniec: najpierw napraw wolne zapytania. Pod presją poolowania wolne zapytania trzymają połączenia dłużej, co zwiększa czasy oczekiwania, timeouty i retry-e. Ten sprzężony pętli napędza „trochę wolno” w „wszystko wolne”.

Testy obciążeniowe i planowanie pojemności bez zgadywania

Traktuj testy obciążeniowe jako sposób na weryfikację budżetu połączeń, nie tylko przepustowości. Cel to potwierdzić, że poolowanie zachowuje się pod obciążeniem tak jak w staging.

Testuj realistyczny ruch: ten sam miks żądań, wzorce skokowe i taką samą liczbę instancji aplikacji jak w produkcji. Benchmarkowanie jednego endpointu często ukrywa problemy z pulą aż do dnia uruchomienia.

Uwzględnij rozgrzewkę, żeby nie mierzyć cold cache i efektów ramp-up. Pozwól pulom osiągnąć normalny rozmiar, a potem zacznij zapisywać wyniki.

Jeśli porównujesz strategie, trzymaj obciążenie identyczne i uruchom:

• tylko poolowanie aplikacyjne (tuned database/sql, bez PgBouncer)
• PgBouncer przed bazą (aplikacje trzymają małe pule, PgBouncer ogranicza połączenia serwera)
• oba razem (małe pule aplikacyjne + PgBouncer)

Po każdym teście zapisz krótką kartę wyników, której będziesz używać po kolejnych wydaniach:

• p95 i p99 latencji żądań podczas stanu ustalonego i podczas skoku
• maksymalna łączna liczba połączeń (po stronie klienta i serwera)
• sygnały czasu kolejki (waiting for a free connection)
• wskaźnik błędów i liczba timeoutów
• przepustowość w punkcie, gdy latencja zaczyna szybko rosnąć

Z czasem to zamienia planowanie pojemności w proces powtarzalny zamiast zgadywania.

Szybka lista kontrolna i następne kroki

Zanim zmienisz rozmiary puli, zapisz jedną liczbę: swój budżet połączeń. To maksymalna bezpieczna liczba aktywnych połączeń Postgresa dla tego środowiska (dev, staging, prod), wliczając zadania tła i dostęp administracyjny. Jeśli nie potrafisz jej podać, zgadujesz.

Krótka lista kontrolna:

• Ustaw wyraźny max w Go i upewnij się, że (instances x MaxOpenConns) mieści się w budżecie (lub w limicie PgBouncer).
• Ustaw time-outy, by „wieczne oczekiwanie” nie ukrywało problemów aż do skoku.
• Jeśli używasz PgBouncer, wybierz tryb poolowania zgodny z użyciem stanu sesji.
• Unikaj bardzo krótkich czasów życia połączeń, które powodują ciągłe ponowne łączenia.
• Potwierdź, że max_connections i wszelkie zarezerwowane połączenia zgadzają się z twoim planem.

Plan wdrożenia z łatwym rollbackem:

1. Zastosuj zmiany w staging pod obciążeniem, które odpowiada produkcyjnej współbieżności i miksowi odczyt/zapis.
2. Wdrażaj do produkcji w małych krokach (podzbiór instancji lub jedna usługa na raz).
3. Obserwuj p95, czas oczekiwania w puli, błędy i liczbę połączeń Postgresa przez co najmniej jeden szczyt ruchu.
4. Jeśli p95 skoczy lub wait time w puli wzrośnie, wycofaj zmiany i zmniejsz współbieżność lub limity puli.

Jeśli budujesz i hostujesz aplikację Go + PostgreSQL na Koder.ai (koder.ai), Planning Mode może pomóc wymodelować zmianę i co będziesz mierzyć, a snapshoty i rollback ułatwią wycofanie, jeśli ogonowe opóźnienia się pogorszą.

Następny krok: dodaj jedno pomiar przed kolejnym skokiem ruchu. „Czas spędzony na czekaniu na połączenie” w aplikacji często jest najbardziej przydatny, bo pokazuje presję na pulę zanim użytkownicy ją odczują.