Postgres max_connections bez modułu puli

Postgres nie używa lekkiej puli wątków do swoich połączeń. Każde połączenie klienta uruchamia pełnoprawny proces systemowy.

Proces postmaster tworzy nowy („fork”) dla każdej próby połączenia, dedykowany tej pojedynczej sesji, aż do jej zamknięcia. Oficjalna dokumentacja projektu opisuje dokładnie ten mechanizm w rozdziale poświęconym podstawom architektury (postgresql.org/docs/current/connect-estab.html, sekcja „Connection Semantics”, dostęp 24 sierpnia 2026).

Wybór ten ma realną zaletę: awaria jednego połączenia nie wpływa na pozostałe, a każdy proces jest odizolowany od reszty serwera. Ma to również bezpośredni koszt: każde dodatkowe połączenie dodaje do harmonogramu cały proces systemu operacyjnego, z własną przestrzenią pamięci i własnym narzutem na przełączanie kontekstu dla jądra.

Na pamięć wpływają dwa różne mechanizmy, a pomieszanie ich prawie zawsze prowadzi do błędnej diagnozy.

Pierwsza jest ustalona. Podczas uruchamiania Postgres rezerwuje struktury pamięci współdzielonej (blokady, tabelę procesów) o rozmiarze dostosowanym do wartości max_connections, niezależnie od tego, czy połączenia te zostaną później otwarte, czy nie. Oficjalna dokumentacja tego ustawienia wyraźnie wskazuje: zwiększenie go może wymagać większej ilości pamięci współdzielonej systemu, niż pozwala na to domyślna konfiguracja systemu operacyjnego (postgresql.org/docs/current/runtime-config-connection.html, dostęp: 24 sierpnia 2026 r.).

Drugi jest zmienny i znacznie bardziej niebezpieczny na dużą skalę: work_mem nie jest przydzielany raz na połączenie, ale raz na operację sortowania lub mieszania w planie zapytań. Oficjalna dokumentacja jasno określa tę kwestię: złożone zapytanie może uruchomić kilka z tych operacji równolegle, a kilka sesji może wykonać to samo jednocześnie, tak że faktycznie używana pamięć może być kilkukrotnie warta work_mem (postgresql.org/docs/current/runtime-config-resource.html, dostęp 24 sierpnia 2026).

Oficjalna wiki projektu PostgreSQL dokumentuje wzór wzorcowy do obliczania liczby aktywnych połączeń, które Twój sprzęt może wydajnie przetwarzać równolegle, a nie liczby otwartych połączeń w sumie (wiki.postgresql.org/wiki/Number_Of_Database_Connections, dostęp 24 sierpnia 2026).

Na serwerze z 8 rdzeniami fizycznymi i pamięcią SSD wzór daje (8 × 2) + 1 = 17 aktywnych połączeń, zanim przepustowość zacznie spadać. Liczba ta często zaskakuje: wydaje się niewielka w porównaniu z setkami połączeń otwieranych przez aplikację w praktyce. Jest to właśnie tematem następnego akapitu.

Liczba obliczona za pomocą wzoru mierzy współbieżność, jaką może wchłonąć procesor i dysk, a nie liczbę połączeń klienckich, które aplikacja musi otworzyć. Flota 20 procesów aplikacyjnych, każdy z własną pulą 10 połączeń, otwiera 200 jednoczesnych połączeń z Postgres, nawet jeśli tylko 17 z nich aktywnie pracuje w danym momencie. Bez modułu pulowego max_connections musi obejmować 200, a nie 17. To właśnie ta luka popycha większość architektur do dodania modułu w trybie transakcyjnym, nawet jeśli oznacza to wybranie którego z nich (zobacz nasze porównanie PgBouncer, Supavisor i PgCat).

max_connections nie podlega wymianie podczas pracy. To jest parametr kontekstu postmaster: Postgres czyta go raz przy uruchomieniu, aby określić rozmiar pamięci współdzielonej. Ponowne załadowanie konfiguracji (pg_reload_conf() lub SIGHUP) nie wystarczy, należy zrestartować serwer.

Najpierw sprawdź bieżącą wartość i jej kontekst, aby potwierdzić, że konieczne będzie ponowne uruchomienie:

SHOW max_connections;

SELECT name, setting, context
FROM pg_settings
WHERE name = 'max_connections';

-- kontekst='postmaster' potwierdza, że ​​wymagane jest ponowne uruchomienie

Następnie zastosuj nową wartość i uruchom ponownie:

ALTER SYSTEM SET max_connections = '300';

-- Napisano w postgresql.auto.conf.
-- Brak efektu, dopóki Postgres nie zostanie ponownie uruchomiony.

# Z systemd
sudo systemctl restart postgresql

# Bez systemd, bezpośrednio z pg_ctl
pg_ctl restart -D $PGDATA -m fast

Rozmiar max_connections to nie tylko ćwiczenie teoretyczne. Oto jak Aurabase budżetuje je w zarządzanych klastrach Postgres:

Klastry dedykowane: jeden klaster Postgres na projekt

Na tym poziomie (zobacz nasze porównanie dedykowana i współdzielona baza) każdy projekt otrzymuje własny klaster CloudNativePG i własny budżet max_connections, dostosowany do rozmiaru instancji:

Klastry współdzielone: ​​kilka projektów organizacji, wspólny budżet

Na tej drugiej ścieżce wszystkie projekty tej samej organizacji łączą się za pośrednictwem modułu puli CNPG (PgBouncer, tryb transaction) przed współdzielonym serwerem podstawowym:

Wszystkie projekty w organizacji łączą się za pośrednictwem udostępnionej roli aplikacji. Dlatego samo max_user_connections ogranicza całkowitą liczbę połączeń z serwerem, które ta rola może otworzyć w całym klastrze: jest to prawdziwe zabezpieczenie globalne dla klastra, a nie max_client_conn, które ogranicza jedynie połączenia klientów z samym modułem puli.

Jednak ten moduł puli obsługuje tylko ruch aplikacji SDK. Ze swojej strony PostgREST pozostaje bezpośrednio podłączony do usługi podstawowej (usługa-rw): łączenie w trybie transakcyjnym przerwałoby mechanizm przeładowywania schematu, który nasłuchuje dedykowanego kanału LISTEN o nazwie pgrst. Jego własne połączenia (2 na replikę na poziomie współdzielonym, 10 na replikę na poziomie dedykowanym) wliczają się zatem bezpośrednio do budżetu max_connections podstawowego, poza jakimkolwiek basenem, dokładnie tego rodzaju „zapomniane” połączenie, które musi obejmować krok 1 poniższej procedury.

Ta procedura nie jest zależna od żadnego konkretnego narzędzia: dotyczy dowolnego serwera Postgres, zarządzanego lub hostowanego samodzielnie.

1. Zlicz rzeczywiste połączenia klientów. Liczba procesów aplikacji pomnożona przez wielkość ich wewnętrznej puli plus narzędzia administracyjne, replikacja i monitorowanie. To właśnie ta liczba, a nie formuła, określa minimalną wartość max_connections.
2. Oblicz idealną współbieżność swojego sprzętu za pomocą wzoru z wiki PostgreSQL: (rdzenie fizyczne × 2) + wydajne dyski. Liczba ta wskazuje, ile z tych połączeń może faktycznie pracować równolegle bez pogarszania przepustowości.
3. Ustaw max_connections powyżej rzeczywistej potrzeby kroku 1, z marginesem na superuser_reserved_connections i wszelkie narzędzia administracyjne, które otwierają własne połączenia poza aplikacją.
4. Zastosuj zmianę za pomocą opcji ALTER SYSTEM SET, a następnie zrestartuj serwer. To jest parametr postmastera: proste przeładowanie nie wystarczy, jak opisano powyżej.
5. Monitoruj pg_stat_activity w czasie. Jeśli liczba bezczynnych połączeń znacznie przekracza liczbę aktywnych połączeń, nie jest to problem max_connections: jest to sygnał, że potrzebny jest Pooler przed serwerem, a nie większa liczba.

Żądanie monitorowania z kroku 5, bezpośrednio przydatne:

SELECT state, count(*)
FROM pg_stat_activity
GROUP BY state
ORDER BY count(*) DESC;

Trzy sygnały systematycznie powracają, gdy samo max_connections nie wystarcza, niezależnie od jego wartości.

1. Błąd FATAL: sorry, too many clients already pojawia się w czasie szczytowego obciążenia, natomiast większość połączeń wyświetlanych przez pg_stat_activity jest w stanie bezczynności.
2. Aplikacja działa w środowisku bezserwerowym lub z tymczasowymi procesami roboczymi (funkcje brzegowe, krótkie zadania), które otwierają i zamykają połączenia znacznie szybciej, niż został zaprojektowany w modelu przetwarzania na połączenie Postgres.
3. Powyższa formuła i procedura zostały już zastosowane, a rzeczywiste zapotrzebowanie na połączenia klientów w dalszym ciągu przekracza to, co może przydzielić dostępna pamięć bez narażania work_mem lubshared_buffers.

W tych trzech przypadkach poprawną odpowiedzią jest prawie zawsze moduł basenowy umieszczony pomiędzy aplikacją a Postgres, a nie wyższy parametr max_connections. Nasze porównanie PgBouncer, Supavisor i PgCat szczegółowo opisuje trzy opcje, a nasz przewodnik po trybie transakcyjnym wyjaśnia najczęstszy kompromis po wprowadzeniu puli. Informacje na temat strojenia Postgres poza połączeniami można znaleźć w naszej produkcyjnej liście kontrolnej strojenia Postgres.