MIME-Version: 1.0
In-Reply-To: <20160613070056.5789.33953@wrigleys.postgresql.org>
References: <20160613070056.5789.33953@wrigleys.postgresql.org>
From: Kevin Grittner <kgrittn@gmail.com>
Date: Mon, 13 Jun 2016 13:59:31 -0500
Message-ID: 
 <CACjxUsO=mafOYpMm+nf7q7-=rMKMieP6-m0f3wbKui+yPEN05Q@mail.gmail.com>
Subject: Re: Regarding Overcommit
To: jobinau@gmail.com
Cc: "pgsql-docs@postgresql.org" <pgsql-docs@postgresql.org>
Content-Type: text/plain; charset=UTF-8
Precedence: bulk
Sender: pgsql-docs-owner@postgresql.org

On Mon, Jun 13, 2016 at 2:00 AM,  <jobinau@gmail.com> wrote:

> Documentation says:
>
> sysctl -w vm.overcommit_memory=2
>
> &quot;it will lower the chances significantly and will therefore lead to more
> robust system behavior.&quot;
>
> This statement in documentation is Wrong.
>
> This is not recommended for production environments, because if an
> out-of-memory condition does present itself, there could be unexpected
> behavior.

It is wrong for some types of production environments, but for a
server where the only (or primary) service is PostgreSQL it is
absolutely Right.  Without this, an out-of-memory condition which
cancels any database process causes a crash and restart of all
connections without necessarily giving any useful clues as to the
cause of the crash.  With vm.overcommit_memory = 2 it will
generally yield an error on only the one connection causing the
problem, and provide a detailed dump of memory contexts (with
allocated space in each).  Other connections are generally
unaffected and the cause of the problem can be fixed to prevent
recurrence.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs