North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Quick question.

  • From: Paul G
  • Date: Wed Aug 04 03:20:24 2004

----- Original Message ----- 
Cc: <[email protected]>From: "Paul Jakma" <[email protected]>
To: "Paul G" <[email protected]>

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