Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 351326502F5 for ; Thu, 28 Aug 2008 15:14:10 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 18828-06-4 for ; Thu, 28 Aug 2008 15:13:56 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from relay-2.mail.nethere.net (relay-2.mail.nethere.net [66.63.128.162]) by postgresql.org (Postfix) with ESMTP id 697DD650319 for ; Thu, 28 Aug 2008 15:12:25 -0300 (ADT) Received: from scan-2.mail.nethere.net (scan-2.mail.nethere.net [66.63.128.133]) by relay-2.mail.nethere.net (Postfix) with ESMTP id 13A6D12C4A2; Thu, 28 Aug 2008 11:12:22 -0700 (PDT) Received: from mta-2.mail.nethere.net by scan-2.mail.nethere.net with LMTP id vJj1f2R8dSsd; Thu, 28 Aug 2008 11:12:22 -0700 (PDT) Received: from lisa-james-computer.local (wsip-68-224-174-233.sd.sd.cox.net [68.224.174.233]) by mta-2.mail.nethere.net (Postfix) with ESMTP id DEFB5130C22; Thu, 28 Aug 2008 11:12:21 -0700 (PDT) Message-ID: <48B6EA7E.2090707@emolecules.com> Date: Thu, 28 Aug 2008 11:12:14 -0700 From: Craig James User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: PostgreSQL Performance CC: Matthew Wakeling Subject: Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception References: <82bpze3ou8.fsf@mid.bfk.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200808/379 X-Sequence-Number: 31260 Matthew Wakeling wrote: > On Thu, 28 Aug 2008, Steve Atkins wrote: >>> Probably the best solution is to just tell the kernel somehow to >>> never kill the postmaster. >> >> Or configure adequate swap space? > > Oh yes, that's very important. However, that gives the machine the > opportunity to thrash. No, that's where the whole argument for allowing overcommitted memory falls flat. The entire argument for allowing overcommitted memory hinges on the fact that processes *won't use the memory*. If they use it, then overcommitting causes problems everywhere, such as a Postmaster getting arbitrarily killed. If a process *doesn't* use the memory, then there's no problem with thrashing, right? So it never makes sense to enable overcommitted memory when Postgres, or any server, is running. Allocating a big, fat terabyte swap disk is ALWAYS better than allowing overcommitted memory. If your usage is such that overcommitted memory would never be used, then the swap disk will never be used either. If your processes do use the memory, then your performance goes into the toilet, and you know it's time to buy more memory or a second server, but in the mean time your server processes at least keep running while you kill the rogue processes. Craig