Re: why swap at all?

[John Bradford]

Quote from Nick Piggin <nickpiggin@xxxxxxxxxxxx>:
> John Bradford wrote:
> > Quote from Roger Luethi <rl@xxxxxxxxxxx>:
> > 
> >>On Wed, 26 May 2004 10:23:32 +0100, John Bradford wrote:
> >>
> >>>A run-away process on a server with too much swap can cause it to grind to
> >>>almost a complete halt, and become almost compltely unresponsive to remote
> >>>connections.
> >>>
> >>>If the total amount of storage is just enough for the tasks the server is
> >>>expected to deal with, then a run-away process will likely be terminated
> >>>quickly stopping it from causing the machine to grind to a halt.
> >>
> >>I'm not sure your optimism about the correct (run-away) process being
> >>terminated is justified. Granted, there are definitely scenarios
> >>where swapless operation is preferable, but in most circumstances --
> >>especially workstations as the original poster described -- I'd rather
> >>minimize the risk of losing data.
> > 
> > 
> > Well, I am basing this on experience.  I know an ISP who had their main
> > customer webserver down for hours because of this kind of problem - the whole
> > thing created a lot of work and wasted a lot of time.
> > 
> > In this particular scenario, I think the run-away process was probably using
> > up almost two thirds of the total RAM, so I'm pretty confident the correct
> > process would have been terminated.
> > 
> 
> I think this is somewhat orthogonal to whether swap should be
> used or not.
> 
> What we should be doing here is enforcing the RSS rlimit. I
> have a patch from Rik to do this which needs to be merged.
> 
> Hopefully this would give you the best case situation of
> having only the runaway process really slow down, without
> killing anything until the admin arrives.

Ideally, yes - by the way, this was some time ago, (I think the machine was
running a 2.2 kernel).

John.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/