Message-ID: <3F450486.50907@dunslane.net>
Date: Thu, 21 Aug 2003 13:42:30 -0400
From: Andrew Dunstan <andrew@dunslane.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Re: Can't find thread on Linux memory overcommit
References: <200308201102.37559.josh@agliodbs.com>
	<200308210919.48463.josh@agliodbs.com>
	<3F44F6A1.8090900@dunslane.net>
	<200308211013.26737.josh@agliodbs.com>
In-Reply-To: <200308211013.26737.josh@agliodbs.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

(er, that's "Andrew" :-)

It depends how important your data is to you. A modest server probably 
costs a few thousand dollars. How much does an expert to install a 
custom kernel cost? Probably about the same.

I believe paranoid mode is supposed to prevent any overcommiting that 
can't later be honoured when the process comes to map the memory, and 
strict mode is supposed to do the same in most normal circumstances. 
Maybe someone more expert in kernel hackery than I am can give a better 
answer.

BTW, Alan Cox is going on sabbatical from RH very soon - so there will 
be no more -ac patches. By the time he returns 2.6 should have been 
released and bedded down, with any luck.

andrew

Josh Berkus wrote:

>Alan,
>
>  
>
>>You need to be careful using Alan's patch. The reason RH stopped using
>>this part of it in their errata kernels is that it had conflicts with
>>other stuff, specifically the rmap stuff (he told me that himself in
>>email).
>>    
>>
>
>Hmmm ... that leaves us without a workaround for this problem, then, yes?  
>Because even parnoid-mode kernels you can discourage, but not prevent, 
>overcommitting.
>
>  
>
>>For mission critical apps I would advise running the postmaster on a
>>dedicated machine, with no X or other nasty stuff running.
>>    
>>
>
>Unfortunately, this is frequently not an option ... PostgreSQL is often 
>together on a server with Apache, a JVM, and other server software.   As 
>happened in the one case of possible (diagnosis pending) failure that we are 
>looking into.  Of course, it could be something else ....
>
>  
>