public inbox for [email protected]
help / color / mirror / Atom feedRegarding Overcommit
2+ messages / 2 participants
[nested] [flat]
* Regarding Overcommit
@ 2016-06-13 07:00 [email protected]
0 siblings, 1 reply; 2+ messages in thread
From: [email protected] @ 2016-06-13 07:00 UTC (permalink / raw)
To: pgsql-docs
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/9.2/static/kernel-resources.html
Description:
Documentation says:
sysctl -w vm.overcommit_memory=2
"it will lower the chances significantly and will therefore lead to more
robust system behavior."
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.
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Regarding Overcommit
@ 2016-06-13 18:59 Kevin Grittner <[email protected]>
parent: [email protected]
0 siblings, 0 replies; 2+ messages in thread
From: Kevin Grittner @ 2016-06-13 18:59 UTC (permalink / raw)
To: [email protected]; +Cc: pgsql-docs
On Mon, Jun 13, 2016 at 2:00 AM, <[email protected]> wrote:
> Documentation says:
>
> sysctl -w vm.overcommit_memory=2
>
> "it will lower the chances significantly and will therefore lead to more
> robust system behavior."
>
> 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 ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2016-06-13 18:59 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2016-06-13 07:00 Regarding Overcommit [email protected]
2016-06-13 18:59 ` Kevin Grittner <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox