Postgresql: Nie można nawiązać połączenia, ponieważ komputer docelowy aktywnie odmawia ona

Question

Running PostgreSQL 9.5 na serwerze Windows 2012 R2 w Azure

Podczas pracy niektóre loadtests na mojej aplikacji, otrzymuję błędy nie są w stanie połączyć się z serwer postgres. W dziennikach o PostgreSQL pojawia się następujący komunikat:

nie mógł odbierać dane z klientem: Nie można nawiązać połączenia ponieważ komputer docelowy aktywnie go odmawia.

Dzieje się tak tylko wtedy, gdy loadtest przechodzi do następnego scenariusza, trafiając w inną część kodu. Dlatego wymagane są nowe połączenia z bazą danych. Ale po 10-20 sekundach reszta scenariusza działa bezbłędnie, nie uderzając w żadną inną czkawkę. Problemem wydają się być połączenia TCP. (Mój kod ponawia kilka razy, ale to nie jest możliwe, aby pozwolić jej ponownie na 20 sekund)

Używam następujące ustawienia w plikach konfiguracyjnych

postgresql.conf

listen_addresses = '*' 
max_connections = 500 
shared_buffers = 1024MB  
temp_buffers = 2MB 
work_mem = 2MB 
maintenance_work_mem = 128MB   

pg_hba.conf

host all    all    0.0.0.0/0    trust 
host all    all    ::/0     trust 

wiem, wiem .. to nie jest zapisać do przyjmowania połączeń z każdym, ale to tylko w celach testowych i upewnić się, ustawienia te nie blokują żadnej con nekcja. So this answer is void

Monitorowałem numer połączenia na serwerze i pod obciążeniem jest stabilny w 75. Postgres wykorzystuje około 350 MB pamięci RAM. Tak więc, biorąc pod uwagę konfigurację i specyfikacje vm (7GB pamięci RAM), powinno być dużo miejsca, aby utworzyć więcej połączeń. Jednak gdy następny scenariusz się kręci, liczba połączeń nie rośnie, pozostaje na tym samym poziomie i zaczyna wyświetlać komunikaty dziennika o braku połączenia.

Co może być problemem?

Answer 1

To brzmi jak to naprawdę nie jest problem Postgres (stąd żadne zmiany w statystykach DB masz kontroli), raczej, że ruch jest zatrzymywany przez serwer. Być może dlatego, że ruch na tym porcie jest przesycony podczas obsługi zapytań o testowanie obciążenia?

To nie brzmi tak, jakbyś uderzał w jeden z Azure resource limits (w tym database limits, jeśli to dotyczy konfiguracji?), Ale bez większej ilości szczegółów na temat testów obciążenia trudno jest dokładnie określić, co jest potrzebne.

Solutions w całym Internecie i innych odpowiedzi tak sugerują:

• Wyłącz TCP autodostrajanie i dostosować klucze rejestru TCP/IP na serwerze, na przykład ustawić TcpAckFrequency - patrz this article szczegółowe informacje
• dokonanie zmian ustawień TCP (jak WinsockListenBacklog) - które mogą być dotknięte czy buforowanie połączeń jest w użyciu lub nie - patrz this MS support article, co jest dla SQL Server 2005, ale ma kilka cennych wskazówek na temat rozwiązywania problemów odrzuconych połączenia TCP/IP (przy użyciu monitora sieci, ale odnosi się do nowszych narzędzi)
• szybsze przetwarzanie zapytania, jeśli masz wystarczającą kontrolę nad serwerem - source
• Wyłączenie serwerów proxy sieci (w testowej aplikacji obciążenia): <defaultProxy> <proxy usesystemdefault="False"/> </defaultProxy> - source

Answer 2

Większość Możliwą przyczyną jest firewall/Anti-virus:

• Software/osobiste ustawienia zapory
• Multiple Software/firewalli
• Antywirusowe
• LSP warstwy
• (Wirtualny) Oprogramowanie układowe routera

Czy Twoja obecna infrastruktura Azure zawiera Firewall lub Anti-Virus?

Dodatkowo podczas wykonywania dodatkowych wyszukiwań wygląda na to, że jest to standardowy komunikat odmowy połączenia Windows, który sugeruje, że PostgreSQL próbuje się połączyć z czymś i odmawia.

Możliwe również, że jeden element sieci w twojej sieci - zakładając, że wciąż jesteś podłączony do serwera - opóźni lub upuści somy DB sieciowe pakiety uwierzytelniające/uwierzytelniające (uważane na przykład za fałszywy auth.replay) ...

Możesz również użyć analizatora pakietów (np. Wireshark) do nagrywania/sprawdzania przepływu w sieci, gdy pojawi się błąd.

Pozdrowienia