Jörn Engel wrote:
On Tue, 23 November 2004 19:08:50 +0100, Jörn Engel wrote:
I love it when someone else already did the work. ;)
Except when it's only partial. If implementation matches
documentation, the fixed lower bound is 0 (zero). That's pretty low.
Most people want to say something like "Ssh will always get 5% of cpu,
no matter how many forkbombs explode. And the administrator's shell
will inherit those 5%."
Actually it's the minimum timeslice, every maximum starvation interval.
Which is something like 0.05% of CPU, but its better than nothing; you
can get a lot done in a single slice these days. In extreme situations,
like the load gets above 500 (fewer with realtime processes), then the
anti-starvation system doesn't meet its guarantees (but nothing starves
completely).
So, set maximum process ulimits in your vservers to stop the system
being unusable in the case of a fork bomb.
If you increase the priority of the administrative daemons to -19, then
you will get what people *actually* want ;-) which is CPU time for
administration to come before all normal activity on the system. Even
with a load over 100 you should still be able to log in via ssh if it is
niced that high.
--
Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)
_______________________________________________
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
