Re: kernel killing processes when out of swap

On Wed, 13 Apr 2005, Jim C. Nasby wrote: > It's extremely disappointing that you can't turn this off. I've been > bashing linux for months now about how they think it's OK to kill random > processes. But at least they'll let you turn it off. It's extremely disappointing that you haven't submitted

Re: kernel killing processes when out of swap

On Wed, Apr 13, 2005 at 12:07:11AM +0200, Matthias Buelow wrote: > Nick Barnes <[EMAIL PROTECTED]> writes: > > >> This stuff has been discussed in the past. > >Indeed. For a couple of examples from the days before BSD systems got > >overcommit, see these threads from 1990 and 1991: > > > >

Re: kernel killing processes when out of swap

Nick Barnes <[EMAIL PROTECTED]> writes: >> This stuff has been discussed in the past. >Indeed. For a couple of examples from the days before BSD systems got >overcommit, see these threads from 1990 and 1991: > >b658465

Re: kernel killing processes when out of swap

At 2005-04-12 18:17:32+, Matthias Buelow writes: > This stuff has been discussed in the past. Indeed. For a couple of examples from the days before BSD systems got overcommit, see these threads from 1990 and 1991:

Re: kernel killing processes when out of swap

On 12 Apr, Dan Nelson wrote: > In the last episode (Apr 12), Nick Barnes said: >> This is the well-known problem with my fantasy world in which the OS >> doesn't overcommit any resources. All those programs are broken, but >> it's too costly to fix them. If overcommit had been resisted more >> ef

Re: kernel killing processes when out of swap

Dan Nelson <[EMAIL PROTECTED]> writes: >Another issue is things like shared libraries; without overcommit you >need to reserve the file size * the number of processes mapping it, >since you can't guarantee they won't touch every COW page handed to >them. I think you can design a shlib scheme wher

Re: kernel killing processes when out of swap

In the last episode (Apr 12), Nick Barnes said: > This is the well-known problem with my fantasy world in which the OS > doesn't overcommit any resources. All those programs are broken, but > it's too costly to fix them. If overcommit had been resisted more > effectively in the first place, those

Re: kernel killing processes when out of swap

At 2005-04-12 14:26:40+, Marc Olzheim writes: > On Tue, Apr 12, 2005 at 03:06:41PM +0100, Nick Barnes wrote: > > The right choice is for mmap() to return ENOMEM, and then for malloc() > > to return NULL, but almost no operating systems make this choice any > > more. > > No, the problem occurs

Re: kernel killing processes when out of swap

On Tue, Apr 12, 2005 at 03:06:41PM +0100, Nick Barnes wrote: > The right choice is for mmap() to return ENOMEM, and then for malloc() > to return NULL, but almost no operating systems make this choice any > more. No, the problem occurs only when previously allocated / mmap()d blocks are actually u

Re: kernel killing processes when out of swap

At 2005-04-12 13:52:59+, Vivek Khera writes: > > of swap? Which leads to the question would it not be more sensible to > > kill off the largest process first as its more than likely that it is > > responsible > > for the problem? > > > > so when this largest process is your production databa

Re: kernel killing processes when out of swap

On Apr 11, 2005, at 12:01 PM, Steven Hartland wrote: of swap? Which leads to the question would it not be more sensible to kill off the largest process first as its more than likely that it is responsible for the problem? so when this largest process is your production database server for your e

kernel killing processes when out of swap

Just had a problem with a box where it looks like it ran out of swap due to a problem process, not a problem. The problem was that it seems the kernel on detecting this starts killing off seeming random processes, the first one being sshd hence making the machine inaccessible. So the question is: D