Databáza odmieta spojenia. Ako nastaviť aplikačné pooly?
Prečo viac backendových procesov môže vyčerpať databázové spojenia. Rozpočet poolov, čakajúce požiadavky a bezpečný postup pri PostgreSQL.
Pri rozšírení backendu môže pribudnúť problém, ktorý graf CPU nevysvetlí: aplikácia čaká na databázové spojenie alebo PostgreSQL nové spojenia odmieta. Každý proces môže spravovať vlastný pool, teda zásobu spojení na opakované použitie. Jeho limit treba posúdiť spolu so všetkými ostatnými klientmi databázy. Nasledujúci postup vychádza z PostgreSQL 18; príklady klientskych metrík používajú node-postgres.
Zistite, kde požiadavka čaká
Rozlíšte čakanie v aplikačnom poole od chyby pri vytváraní nového spojenia na server. V node-postgres sledujte waitingCount spolu s totalCount a idleCount. Rastúci počet čakajúcich požiadaviek je dôvod preveriť, kto spojenia drží a ako dlho. Čas dotazu merajte oddelene od času potrebného na získanie spojenia.
V PostgreSQL overte nastavenie cez SHOW max_connections; a skontrolujte rezervované spojenia. Zvýšenie tohto limitu vyžaduje reštart servera a zvyšuje nároky niektorých zdrojov vrátane zdieľanej pamäte. Počas incidentu preto najprv zistite skutočný zdroj tlaku a možnosti riadeného zásahu.
Spočítajte pooly všetkých procesov
Pri priamom pripojení k databáze zostavte súčet maximálnych veľkostí poolov všetkých procesov. Pridajte workery, plánované úlohy aj ďalšie služby. Ilustračný príklad: štyri procesy s limitom 20 spojení môžu spolu otvoriť až 80 spojení. Ide o výpočet kapacity, nie meranie konkrétneho systému ani odporúčanú veľkosť poolu.
Do rozpočtu zahrňte dočasný súbeh starej a novej verzie počas nasadenia a hornú hranicu automatického škálovania. Ponechajte priestor na správu a diagnostiku. Limit jedného procesu zvoľte podľa tohto rozpočtu a merania záťaže; rovnaké nastavenie nemusí vyhovovať webu aj dávkovému spracovaniu.
Preskúmajte dlho držané spojenia
V pg_stat_activity porovnajte application_name, stav a začiatok transakcie. Stav idle označuje čakanie na nový príkaz. Idle in transaction znamená otvorenú transakciu bez práve bežiaceho dotazu a zaslúži si kontrolu. Niektoré diagnostické údaje o cudzích reláciách sú dostupné iba s príslušnými oprávneniami; chýbajúci údaj nie je dôkazom, že problém neexistuje.
Pri ručnom získaní klienta v node-postgres zabezpečte jeho vrátenie do poolu aj po chybe, napríklad cez finally. Nastavte aj konečné čakanie na získanie spojenia. Ak treba ukončiť konkrétnu databázovú reláciu, najprv zistite jej vlastníka a dopad; pg_terminate_backend ukončuje celú reláciu. Plošné ukončenie spojení bez rozboru nie je rozumný prvý zásah.
Zmenu overte s reálnym súbehom
Ak používate PgBouncer, odlíšte klientské spojenia od spojení smerujúcich do PostgreSQL. Parameter default_pool_size je predvolený limit pre dvojicu používateľ a databáza; pri viacerých dvojiciach a inštanciách treba posúdiť ich súčet. Transaction pooling vracia serverové spojenie po transakcii, ale vyžaduje overenie kompatibility aplikácie, napríklad pri LISTEN alebo zámkoch viazaných na reláciu.
V oddelenom prostredí skúste špičkovú záťaž aj súbeh pri nasadení. Porovnajte čakanie na spojenie, počet chýb a odozvu používateľskej operácie. Po produkčnej zmene sledujte rovnaké údaje a pripravte návrat konfigurácie. Samotné zníženie počtu spojení ešte neukáže, či klienti dostávajú výsledok v prijateľnom čase.
- Rozlíšte čakanie v poole od odmietnutia databázou.
- Zahrňte všetky procesy a súbeh počas nasadenia.
- Overte vrátenie klientov a dlho otvorené transakcie.
- Zmerajte chyby aj odozvu po zmene konfigurácie.
Čo si odniesť
Aplikačné pooly nastavujte ako spoločný rozpočet databázových spojení. Pri vyčerpaní kapacity nájdite procesy a operácie, ktoré spojenia držia, potom overte zmenu pri očakávanom súbehu.
