Re: Quick question.

["Paul G" <paul () rusko us>]

----- Original Message ----- 
Cc: <nanog () merit edu>From: "Paul Jakma" <paul () clubi ie>
To: "Paul G" <paul () rusko us>

Sent: Wednesday, August 04, 2004 3:09 AM
Subject: Re: Quick question.


> On Wed, 4 Aug 2004, Paul G wrote:
>
> > the second cpu buys you time - it is unlikely you're going to be
> > able to react in time on a busy single cpu box with a runaway
> > process (it launches into a death sprial almost immediately), but
> > you would usually have 10-15 mins on a dual cpu box at a minimum or
> > maybe infinity if you enforce cpu affinity for apps that tend to
> > misbehave.
>
> Why do you have 10-15 mins? If the application is multi-threaded and
> has a reasonable workload, there are plenty of types of bugs that
> will result in one spinning thread after the other, you need far
> more than just 2 CPUs! Or maybe your application vendor has "at least
> 10minutes between hitting bugs!" on it's feature list? ;)

these are observations, pertaining to software products we use a lot -
apache, mysql, apache/suexec, various mtas etc. your point is well taken in
general, but at least When Done Here(tm), dual cpu helps significantly
empirically speaking.

> Really, what you to need do is (in the face of such buggy apps) is to
> set per-task CPU time resource limits appropriate to how much
> cpu-time a task needs and how much you can afford - be it a 1, 2 or n
> CPU system.

agreed. however, this degrades performance in certain situations, is not
practical in others and introduces additional complexity (always a bad
thing). the tradeoff is significantly in favor of reactive measures (be they
automatic or human intervantion), at least in most of our installations.

paul