On Wed, Sep 25, 2013 at 8:00 AM, Greg Stark <st...@mit.edu> wrote: > > On Wed, Sep 25, 2013 at 12:15 AM, Daniel Farina <dan...@heroku.com> wrote: >> >> Enable the memcg OOM killer only for user faults, where it's really the >> only option available. > > > Is this really a big deal? I would expect most faults to be user faults. > > It's certainly a big deal that we need to ensure we can handle ENOMEM from > syscalls and library functions we weren't expecting to return it. But I > don't expect it to actually reduce the OOM killing sprees by much.
Hmm, I see what you mean. I have been reading through the mechanism: I got too excited about 'allocations by system calls', because I thought that might mean brk and friends, except that's not much of an allocation at all, just reservation. I think. There is some interesting stuff coming in along with these patches in bringing the user-space memcg OOM handlers up to snuff that may make it profitable to issue SIGTERM to backends when a safety margin is crossed (too bad the error messages will be confusing in that case). I was rather hoping that a regular ENOMEM could be injected by this mechanism the next time a syscall is touched (unknown), but I'm not confident if this is made easier or not, one way or another. One could imagine the kernel injecting such a fault when the amount of memory being consumed starts to look hairy, but I surmise part of the impetus for userspace handling of that is to avoid getting into that particular heuristics game. Anyway, I did do some extensive study of cgroups and memcg's implementation in particular and found it not really practical for Postgres use unless one was happy with lots and lots of database restarts, and this work still gives me some hope to try again, even if smaller modifications still seem necessary. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
