On Wed, 2008-08-27 at 23:23 -0700, [EMAIL PROTECTED] wrote: > there are periodic flamefests on the kernel mailing list over the OOM > killer, if you can propose a better algorithm for it to use than the > current one that doesn't end up being just as bad for some other workload > the kernel policy can be changed. >
Tried that: http://lkml.org/lkml/2007/2/9/275 All they have to do is *not* count shared memory against the process (or at least not count it against the parent of the process), and the system may approximate sanity. > IIRC the reason why it targets the parent process is to deal with a > fork-bomb type of failure where a program doesn't use much memory itself, > but forks off memory hogs as quickly as it can. if the OOM killer only > kills the children the problem never gets solved. But killing a process won't free shared memory. And there is already a system-wide limit on shared memory. So what's the point of such a bad design? Regards, Jeff Davis -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
