From: Craig Ringer <craig@postnewspapers.com.au>
To: Erik Jones <erik@myemma.com>
Cc: Bryan Buecking <buecking@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: CPU bound at 99%
Date: Wed, 23 Apr 2008 00:36:35 +0800
Message-ID: <480E1413.1060906@postnewspapers.com.au> (raw)
In-Reply-To: <DCD21583-38AA-4E01-BA29-39A7078259FE@myemma.com>
References: <20080422153045.GB5961@starling-software.com>
<DCD21583-38AA-4E01-BA29-39A7078259FE@myemma.com>
Erik Jones wrote:
>> max_connections = 2400
>
> That is WAY too high. Get a real pooler, such as pgpool, and drop that
> down to 1000 and test from there. I see you mentioned 500 concurrent
> connections. Are each of those connections actually doing something?
> My guess that once you cut down on the number actual connections you'll
> find that each connection can get it's work done faster and you'll see
> that number drop significantly.
It's not an issue for me - I'm expecting *never* to top 100 concurrent
connections, and many of those will be idle, with the usual load being
closer to 30 connections. Big stuff ;-)
However, I'm curious about what an idle backend really costs.
On my system each backend has an RSS of about 3.8MB, and a psql process
tends to be about 3.0MB. However, much of that will be shared library
bindings etc. The real cost per psql instance and associated backend
appears to be 1.5MB (measured with 10 connections using system free RAM
change) . If I use a little Python program to generate 50 connections
free system RAM drops by ~45MB and rises by the same amount when the
Python process exists and the backends die, so the backends presumably
use less than 1MB each of real unshared RAM.
Presumably the backends will grow if they perform some significant
queries and are then left idle. I haven't checked that.
At 1MB of RAM per backend that's not a trivial cost, but it's far from
earth shattering, especially allowing for the OS swapping out backends
that're idle for extended periods.
So ... what else does an idle backend cost? Is it reducing the amount of
shared memory available for use on complex queries? Are there some lists
PostgreSQL must scan for queries that get more expensive to examine as
the number of backends rise? Are there locking costs?
--
Craig Ringer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: craig@postnewspapers.com.au, erik@myemma.com, buecking@gmail.com
Subject: Re: CPU bound at 99%
In-Reply-To: <480E1413.1060906@postnewspapers.com.au>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox