On Wed, May 23, 2007 at 01:07:55AM +0200, Attila Csipa wrote:
> A question - is it possible to have something like the CPU token
> mechanism, but for IO operations (f.e. hdd-s) ?
there is, but the main problem here is that most of
the I/O is done asynchronous, i.e. it is not done
by the context itself, but by the kernel in general
> I have a problem where one of the contexts is really heavy on IO and
> I'd try to limit that.
the question here is, _why_ .. maybe your service
really has a high I/O demand, maybe the service is
just badly configured ...
> The scheduler is CFQ, but that does not help much on itself, it's
> not the scheduling itself that is the problem - if the HDD activity
> is high, an another context, running apaches will slow down serving
> files. Running out of children bc of the slowdown apache will start
> forking new processes to fullfill the incoming demands, this however
> triggers swapping after running out of ram which in turn makes
> everything even slower, starting a nasty IO bound load spiral.
well, IMHO the configuration needs some adjustments
here, for example, apache should not spawn more
workers than the memory can handle (note that workers
can serve more than one request)
> To make things (maybe) even harder, the IO intensive context is not
> actually reading/writing all that much data but rather seeking among
> small blocks of it.
hmm, maybe it would be possible to keep th relevant
parts in memory, or at least use an index?
> Is there a recommended/usual way of solving IO bound problems among
> vservers ?
really depends on the problem, my general advice is
to separate I/O bound guests and put them on a really
fast I/O system ...
> Putting in CPU limits or tokens does not help as the CPU-s are
> spending their time on idle or waiting even now so they are always
> full of tokens.
not unusual ... we thought about adding (or in this
case substracting) a penalty for I/O operations, maybe
that would be a viable solution for this kind of cases,
but I think that still needs some testing ...
HTC,
Herbert
>
>
> _______________________________________________
> Vserver mailing list
> Vserver@list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
_______________________________________________
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Received on Thu May 31 12:12:40 2007