Received: from localhost (wm.hub.org [200.46.204.128])
	by postgresql.org (Postfix) with ESMTP id 22F5E9F98FA
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Sun, 19 Nov 2006 15:41:39 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024)
	with ESMTP id 37377-06 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Sun, 19 Nov 2006 19:41:34 +0000 (UTC)
X-Greylist: delayed 01:00:12.545141 by SQLgrey-
Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44])
	by postgresql.org (Postfix) with ESMTP id D3D6A9F9425
	for <pgsql-performance@postgresql.org>;
	Sun, 19 Nov 2006 15:41:32 -0400 (AST)
Received: from osgiliath.mathom.us ([71.246.251.8])
	by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01
	(built Apr
	3 2006)) with ESMTPA id <0J8Z00E1VQKLVVF0@vms044.mailsrvcs.net> for
	pgsql-performance@postgresql.org; Sun, 19 Nov 2006 12:41:09 -0600 (CST)
Received: from localhost (localhost [127.0.0.1])
	by osgiliath.mathom.us (Postfix) with ESMTP id 8B7127074F	for
	<pgsql-performance@postgresql.org>;
	Sun, 19 Nov 2006 13:41:08 -0500 (EST)
Received: from osgiliath.mathom.us ([127.0.0.1])
	by localhost (osgiliath.home.mathom.us [127.0.0.1]) (amavisd-new,
	port 10024)
	with LMTP id VAq8tGqROxxF for <pgsql-performance@postgresql.org>; Sun,
	19 Nov 2006 13:41:07 -0500 (EST)
Received: by osgiliath.mathom.us (Postfix, from userid 1000)
	id 8FD187074E; Sun, 19 Nov 2006 13:41:07 -0500 (EST)
Date: Sun, 19 Nov 2006 13:41:07 -0500
From: Michael Stone <mstone+postgres@mathom.us>
Subject: Re: Postgres server crash
In-reply-to: <Pine.LNX.4.33.0611181713170.19262-100000@denzel.in>
To: pgsql-performance@postgresql.org
Mail-followup-to: pgsql-performance@postgresql.org
Message-id: <20061119184105.GC2366@mathom.us>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-disposition: inline
X-Virus-Scanned: Debian amavisd-new at mathom.us
X-Pgp-Fingerprint: 53 FF 38 00 E7 DD 0A 9C  84 52 84 C5 EE DF 7C 88
References: <19583.1163700841@sss.pgh.pa.us>
	<Pine.LNX.4.33.0611181713170.19262-100000@denzel.in>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200611/160
X-Sequence-Number: 21930

On Sat, Nov 18, 2006 at 05:28:46PM -0800, Richard Troy wrote:
>On linux you can use the sysctl utility to muck with vm.overcommit_memory;
>You can disable the "feature."

Be aware that there's are "reasons" the "feature" exists before you 
"cast" "aspersions" and "quote marks" all over the place, and the 
"reasons" are "things" like "shared memory" and "copy on write" 
memory, which are "generally" condsidered "good things".

At one point someone complained about the ability to configure, e.g., 
IRIX to allow memory overcommit. I worked on some large IRIX 
installations where full memory accounting would have required on the 
order of 100s of gigabytes of swap, due to large shared memory 
allocations. If the swap had been configured rather than allowing 
overcommit, sure it might have reduced the chance of an application 
allocating memory that it couldn't use. In practice, if you're 100s of 
gigs into swap the system isn't going to be useable anyway.

>itself any memory. Frankly, if it takes a complete kernel rewrite to fix
>the problem that the damned operating system can't manage its own needs,
>then the kernel needs to be rewritten! </soapbox>
>
>These kernel hackers could learn something from VAX/VMS.

Like how to make a slower system? You can configure a VM to operate 
the way they did 25 years ago, but in general people have preferred to 
get better performance (*much* better performance) instead. It could be 
that they're all idiots, or it could be that in practice the problem 
isn't as bad as you make it out to be. (Maybe other people are just 
better at configuring their memory usage?)

Mike Stone