Date: Wed, 27 Aug 2008 18:13:38 -0400
From: Andrew Sullivan <ajs@commandprompt.com>
To: pgsql-performance@postgresql.org
Subject: Re: select on 22 GB table causes "An I/O error occured
	while sending to the backend." exception
Message-ID: <20080827221338.GP18946@commandprompt.com>
Mail-Followup-To: Andrew Sullivan <ajs@commandprompt.com>,
	pgsql-performance@postgresql.org
References: <BAY124-W57D3654AF1159CAF8EAC19F5660@phx.gbl>
	<82bpze3ou8.fsf@mid.bfk.de>
	<alpine.DEB.1.10.0808271436210.907@asgard.lang.hm>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.1.10.0808271436210.907@asgard.lang.hm>
User-Agent: Mutt/1.5.17 (2007-11-01)

On Wed, Aug 27, 2008 at 02:45:47PM -0700, david@lang.hm wrote:

> with memory overcommit enabled (the default), the kernel recognises that 
> most programs that fork don't write to all the memory they have
> allocated, 

It doesn't "recognise" it; it "hopes" it.  It happens to hope
correctly in many cases, because you're quite right that many programs
don't actually need all the memory they allocate.  But there's nothing
about the allocation that hints, "By the way, I'm not really planning
to use this."  Also. . .

> seperate copies for the seperate processes (and if at this time it runs of 
> of memory it invokes the OOM killer to free some space),

. . .it kills processes that are using a lot of memory.  Those are not
necessarily the processes that are allocating memory they don't need.

The upshot of this is that postgres tends to be a big target for the
OOM killer, with seriously bad effects to your database.  So for good
Postgres operation, you want to run on a machine with the OOM killer
disabled.

A

-- 
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/