pgBouncer działa świetnie, ale czasami staje się niedostępny

Korzystam z pgBouncer przed zajętą ​​bazą danych postgres 9. Przez większość czasu działa dobrze. Ale co kilka godzin będę otrzymywać wiadomość e-mail o błędzie z mojej aplikacji z wyjątkiem psycopg2:

OperationalError („nie można połączyć się z serwerem: nie można przypisać żądanego adresu Czy serwer działa na hoście„ neo-hulk ”i akceptuje połączenia TCP / IP na porcie 6432?”)

Jest to aplikacja python z grupą pracowników selera wykonujących zadania. Po pojawieniu się tych błędów sprawdzam db pgbouncera i rozmiar puli mieści się w granicach. Po kilku eksperymentach ustawiłem maksymalny rozmiar puli na 400, a rozmiar puli na 200. Trybem puli jest „sesja” (żądania są w większości automatyczne zatwierdzania, prawie żadnych transakcji).

Co sprawia, że ​​pgBouncer „znika” w ten sposób? jest to tylko przez krótki okres czasu (w sumie mówimy o niewielkiej liczbie żądań w porównaniu do samej liczby wniosków, które są przekazywane), ale te, które się nie powiedzie, są ważne.

Dzięki!

Część „ Nie można przypisać żądanego adresu ” w komunikacie o błędzie pochodzi ze stosu TCP jądra. W przypadku napotkania sporadycznie oznacza to zazwyczaj, że przestrzeń dostępnych gniazd jest wyczerpana z powodu zbyt dużej liczby gniazd w stanie oczekiwania ( TIME_WAITlub mniej prawdopodobne FIN_WAIT_1lub FIN_WAIT_2)

Zakres portów gniazd może być wyprowadzany przez cat /proc/sys/net/ipv4/ip_local_port_range. Domyślna wartość standardowego jądra Linuksa to ogólnie 32768 61000.

Możesz sprawdzić wynik netstat -ton|grep WAITna kliencie (-ach) i na hoście pgBouncerera, gdy system jest zajęty. -oFlag pokaże liczniki czasu oczekiwania związane z państw czekać.

Jeśli łączna liczba gniazd TCP jest bliska, 61000-32768=28232prawdopodobnie wyczerpanie tego zakresu jest prawdopodobnie problemem. Ponieważ zamknięte gniazdo spędza 60 sekund w TIME_WAITstanie w normalnym stanie, jeśli host klienta łączy się więcej niż 28232 razy w ciągu jednej minuty, nowe połączenia zakończą się niepowodzeniem z wymienionym błędem, dopóki porty nie zostaną zwolnione.

Jako pierwsze obejście można rozszerzyć zakres portów TCP:

 # echo "1025 65535" >/proc/sys/net/ipv4/ip_local_port_range

Jeśli nie jest zadowalający, sprawdź flagi tcp_tw_recyclei tcp_tw_reuse, a także przestrajaj przez /proc/sys/net/ipv4i sysctl.

Są one zdefiniowane jako (z man tcp):

       tcp_tw_recycle (Boolean; domyślnie: wyłączone; od Linuksa 2.4)
              Włącz szybki recykling gniazd TIME_WAIT. Włączanie tego
              opcja nie jest zalecana, ponieważ powoduje to problemy podczas pracy
              ing z NAT (Network Address Translation).

       tcp_tw_reuse (Boolean; domyślnie: wyłączone; od Linuksa 2.4.19 / 2.6)
              Pozwól ponownie użyć gniazd TIME_WAIT do nowych połączeń, gdy jest
              bezpieczne z punktu widzenia protokołu. Nie należy tego zmieniać bez
              porady / prośby ekspertów technicznych.

Osobiście odnosiłem sukces, tcp_tw_recyclegdy miałem do czynienia z tym problemem z aplikacją kliencką MySQL, ale nie bierz tego za zalecenie, moje rozumienie TCP jest w najlepszym razie powierzchowne.