Skip site navigation (1) Skip section navigation (2)

Re: terminating autovacuum process due to administrator command

From: Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>
To: Radovan Jablonovsky <radovan(dot)jablonovsky(at)replicon(dot)com>
Cc: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, pgsql-admin(at)postgresql(dot)org
Subject: Re: terminating autovacuum process due to administrator command
Date: 2012-06-25 15:32:34
Message-ID: 4FE88492.6040803@ringerc.id.au (view raw or flat)
Thread:
Lists: pgsql-admin
On 06/25/2012 11:00 PM, Radovan Jablonovsky wrote:
> Thanks for response,
>
> How were the connections refused (error message)?
> 2012-06-13 13:45:38.809 MDT [25172]: [1-1] FATAL:  remaining 
> connection slots are reserved for non-replication superuser connections
> 2012-06-13 13:45:38.889 MDT [25173]: [1-1] FATAL:  remaining 
> connection slots are reserved for non-replication superuser connections
> 2012-06-13 13:45:38.895 MDT [25174]: [1-1] FATAL:  remaining 
> connection slots are reserved for non-replication superuser connections
>
> Could it be that there are already max_connections 
> sessions? max_connection was set to 600, when issue occurred the db 
> server had 85 connection and server was under medium load.

I can't explain why it was topping out at 85 when it was set to 600, but 
- I strongly recommend that you switch to a connection pool and lower 
your max_connections considerably. You'll likely get much better 
performance with max connections at 20 or less - the usual rule of thumb 
is "num_hdds + num_cpus"  but in reality you need to benchmark and tune 
to work out what's best.

pgbouncer is a good light-weight pooling option.

--
Craig Ringer

In response to

pgsql-admin by date

Next:From: Rob CowellDate: 2012-06-25 15:40:48
Subject: replication recovery/startup question
Previous:From: Kevin GrittnerDate: 2012-06-25 15:19:28
Subject: Re: starting postgres with an empty px_xlog folder

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group