Postgresql: No connection could be made because the target machine actively refused it

Question

Running Postgresql 9.5 on a windows server 2012 R2 in Azure

While running some loadtests on my application, I get errors on not being able to connect to the postgres server. In the logs of postgres I get the following message:

could not receive data from client: No connection could be made because the target machine actively refused it.

This only happens when the loadtest goes to the next scenario, hitting a different part of the code. So new connections to the database are required. But after 10-20 seconds the rest of the scenario works flawlessly without hitting any other hiccups. So the problem seems to be the tcp connections. (My code retries a couple of times but it is not feasible to let it retry for 20 seconds)

I'm using the following settings in the config files

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

I know, I know.. It is not save to accept connections from everyone, but this is just for testing purposes and to make sure these settings are not blocking any connection. So this answer is void

I've been monitoring the number of connection on the server and under the load it is stable at 75. Postgres is using around 350mb of RAM. So given the config and the vm specs (7gb ram) there should be plenty of space to create more connections. However when the next scenario is spinning up the number of connections does not increase, it stays level and starts giving these log messages about no connection could be made.

What could be the problem here?

Answer 1

It does sound like this isn't really a Postgres problem (hence no changes in DB stats you're checking), rather that the traffic is being stopped by the server. Possibly because traffic on that port is saturated while handling your load testing queries?

It doesn't sound like you're hitting any of the Azure resource limits (including the database limits if that applies to your setup?), but without more detail on your load tests it's hard to say exactly what is needed.

Solutions from around the web and other SO answers suggest:

• Disable TCP autotuning and tweak the TCP/IP registry keys on the server, e.g. set TcpAckFrequency - see this article for details
• Make TCP setting adjustments (like WinsockListenBacklog) - which may be affected by whether connection pooling is in use or not - see this MS support article, which is for SQL Server 2005 but has some great tips on troubleshooting rejected TCP/IP connections (using Network Monitor, but applies to newer tools)
• Faster request processing if you have enough control of the server - source
• Disabling network proxying (in your load testing app): <defaultProxy> <proxy usesystemdefault="False"/> </defaultProxy> - source