Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125])
	by mail.postgresql.org (Postfix) with ESMTP id 452122B2868
	for <pgsql-admin@postgresql.org>; Mon, 25 Jun 2012 12:33:01 -0300 (ADT)
Received: from mail-pb0-f46.google.com ([209.85.160.46])
	by makus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <ringerc@ringerc.id.au>) id 1SjBHf-0003zY-KR
	for pgsql-admin@postgresql.org; Mon, 25 Jun 2012 15:33:00 +0000
Received: by pbbrp8 with SMTP id rp8so6701334pbb.19
	for <pgsql-admin@postgresql.org>; Mon, 25 Jun 2012 08:32:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:x-gm-message-state;
	bh=/cg4k38DrX+tNiM7tAbWNlxCFt0ELGwX8S+P30L7jEk=;
	b=OwAu5A6rOyACbFV6FHL6VQp9d4VK6M1ZadmcvGV5/MpC38WLkVhRPkeTAw6AkLTrMI
	rI7tS/rZIvgGHBgU2NcYwKK9vGWxXOqnWdbY+8IUPSefaMBj34YWoezWaOsubUKIrJly
	ADKxTvjPFpgj+nM9nAcGNi0UoJdHDdxhpVS0VvChpPmGFOcHYM48ehbRX/S1MDVm4suy
	obfLnBUULDgnIWjjFOD8B2/byUrCxipe2E9nQHF8jBpW4zVWNIXwsST3LRl38oJHUaqQ
	6EOc9qWN47tyI+mGwbgSF/HBd2BVs3GQzCgK0WWsYenr1Z5bwT0g7Md/IXcBVjKWkGk4
	DWmw==
Received: by 10.68.192.97 with SMTP id hf1mr41153350pbc.132.1340638362262;
	Mon, 25 Jun 2012 08:32:42 -0700 (PDT)
Received: from ayaki.localdomain (124-169-169-118.dyn.iinet.net.au.
	[124.169.169.118])
	by mx.google.com with ESMTPS id vp4sm8813624pbc.61.2012.06.25.08.32.38
	(version=SSLv3 cipher=OTHER); Mon, 25 Jun 2012 08:32:41 -0700 (PDT)
Message-ID: <4FE88492.6040803@ringerc.id.au>
Date: Mon, 25 Jun 2012 23:32:34 +0800
From: Craig Ringer <ringerc@ringerc.id.au>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: Radovan Jablonovsky <radovan.jablonovsky@replicon.com>
CC: Albe Laurenz <laurenz.albe@wien.gv.at>, pgsql-admin@postgresql.org
Subject: Re: terminating autovacuum process due to administrator command
References: 
 <CAJYcdTtRanwpiBbgbOAgAXRBoV8J7R0gNim4PxV4h7eyb_sAuw@mail.gmail.com>
	<D960CB61B694CF459DCFB4B0128514C208126EEC@exadv11.host.magwien.gv.at>
	<CAJYcdTsr++DEra_ttm8yWcKiDHMO7DDO2Lttwp1-e5BN3SmXbg@mail.gmail.com>
In-Reply-To: 
 <CAJYcdTsr++DEra_ttm8yWcKiDHMO7DDO2Lttwp1-e5BN3SmXbg@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------000804020904030209090109"
X-Gm-Message-State: 
 ALoCoQmfgBnl12Q6Iv9PonDCgHlscDGmbZW4p55rO2JUvUniSDlwAsF1AFgBQe7a/Pb75leKyuth
X-Pg-Spam-Score: -1.9 (-)
X-Archive-Number: 201206/117
X-Sequence-Number: 39708

This is a multi-part message in MIME format.
--------------000804020904030209090109
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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

--------------000804020904030209090109
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 06/25/2012 11:00 PM, Radovan
      Jablonovsky wrote:<br>
    </div>
    <blockquote
cite="mid:CAJYcdTsr++DEra_ttm8yWcKiDHMO7DDO2Lttwp1-e5BN3SmXbg@mail.gmail.com"
      type="cite">
      <meta http-equiv="Context-Type" content="text/html;
        charset=ISO-8859-1">
      <div>Thanks for response,</div>
      <div><br>
      </div>
      <div>How were the connections refused (error message)?&nbsp;</div>
      <div>
        <div>2012-06-13 13:45:38.809 MDT [25172]: [1-1] FATAL:
          &nbsp;remaining connection slots are reserved for non-replication
          superuser connections</div>
        <div>2012-06-13 13:45:38.889 MDT [25173]: [1-1] FATAL:
          &nbsp;remaining connection slots are reserved for non-replication
          superuser connections</div>
        <div>2012-06-13 13:45:38.895 MDT [25174]: [1-1] FATAL:
          &nbsp;remaining connection slots are reserved for non-replication
          superuser connections</div>
        <div><br>
        </div>
        Could it be that there are already max_connections
        sessions?&nbsp;max_connection was set to 600, when issue occurred the
        db server had 85 connection and server was under medium load.<br>
      </div>
    </blockquote>
    <br>
    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"&nbsp; but in reality you need to
    benchmark and tune to work out what's best.<br>
    <br>
    pgbouncer is a good light-weight pooling option.<br>
    <br>
    --<br>
    Craig Ringer<br>
  </body>
</html>

--------------000804020904030209090109--