Subject: Re: select on 22 GB table causes "An I/O error occured
	while sending to the backend." exception
From: Jeff Davis <pgsql@j-davis.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: david@lang.hm, Andrew Sullivan <ajs@commandprompt.com>,
	pgsql-performance@postgresql.org
In-Reply-To: <659.1219899383@sss.pgh.pa.us>
References: <BAY124-W57D3654AF1159CAF8EAC19F5660@phx.gbl>
	<82bpze3ou8.fsf@mid.bfk.de>
	<alpine.DEB.1.10.0808271436210.907@asgard.lang.hm>
	<20080827221338.GP18946@commandprompt.com>
	<alpine.DEB.1.10.0808271516300.907@asgard.lang.hm>
	<659.1219899383@sss.pgh.pa.us>
Content-Type: text/plain
Date: Thu, 28 Aug 2008 10:51:16 -0700
Message-Id: <1219945876.22237.15.camel@jdavis>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Thu, 2008-08-28 at 00:56 -0400, Tom Lane wrote:
> Actually, the problem with Linux' OOM killer is that it
> *disproportionately targets the PG postmaster*, on the basis not of
> memory that the postmaster is using but of memory its child processes
> are using.  This was discussed in the PG archives a few months ago;
> I'm too lazy to search for the link right now, but the details and links
> to confirming kernel documentation are in our archives.
> 

http://archives.postgresql.org/pgsql-hackers/2008-02/msg00101.php

It's not so much that the OOM Killer targets the parent process for a
fraction of the memory consumed by the child. It may not be a great
design, but it's not what's causing the problem for the postmaster.

The problem for the postmaster is that the OOM killer counts the
children's total vmsize -- including *shared* memory -- against the
parent, which is such a bad idea I don't know where to start. If you
have shared_buffers set to 1GB and 25 connections, the postmaster will
be penalized as though it was using 13.5 GB of memory, even though all
the processes together are only using about 1GB! 

Not only that, killing a process doesn't free shared memory, so it's
just flat out broken.

Regards,
	Jeff Davis