On Wed, Sep 18, 2013 at 10:09 PM, Daniel Farina <daniel@heroku.com> wrote:
> I'm not sure how many of you have been tracking this but courtesy of
> lwn.net I have learned that it seems that the OOM killer behavior in
> Linux 3.12 will be significantly different. And by description, it
> sounds like an improvement. I thought some people reading -hackers
> might be interested.
>
> Based on the description at lwn, excerpted below, it sounds like the
> news might be that systems with overcommit on might return OOM when a
> non-outlandish request for memory is made from the kernel.
>
> """
> Johannes Weiner has posted a set of patches aimed at improving this
> situation. Following a bunch of cleanup work, these patches make two
> fundamental changes to how OOM conditions are handled in the kernel.
> The first of those is perhaps the most visible: it causes the kernel
> to avoid calling the OOM killer altogether for most memory allocation
> failures. In particular, if the allocation is being made in response
> to a system call, the kernel will just cause the system call to fail
> with an ENOMEMerror rather than trying to find a process to kill. That
> may cause system call failures to happen more often and in different
> contexts than they used to. But, naturally, that will not be a problem
> since all user-space code diligently checks the return status of every
> system call and responds with well-tested error-handling code when
> things go wrong.
> """
>
> Subject to experiment, this may be some good news, as many programs,
> libraries, and runtime environments that may run parallel to Postgres
> on a machine are pretty lackadaisical about limiting the amount of
> virtual memory charged to them, and overcommit off is somewhat
> punishing in those situations if one really needed a large hash table
> from Postgres or whatever. I've seen some cases here where a good
> amount of VM has been reserved and caused apparent memory pressure
> that cut throughput short of what should ought to be possible.
Yes, that does sound good.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company