Messages in this thread | | | Date | Wed, 26 May 2004 11:48:11 +0100 | From | John Bradford <> | Subject | Re: why swap at all? |
| |
Quote from Nick Piggin <nickpiggin@yahoo.com.au>: > John Bradford wrote: > > Quote from Roger Luethi <rl@hellgate.ch>: > > > >>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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |