Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2008-08-27 at 23:23 -0700, david@xxxxxxx 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



[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux