On Wed, Sep 18, 2013 at 10:09 PM, Daniel Farina <dan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers