----- 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
