Quick question.
Paul Jakma
paul at clubi.ie
Wed Aug 4 06:39:13 UTC 2004
On Tue, 3 Aug 2004, Alexei Roudnev wrote:
> It is not mad idea - 2 CPU servers are not sugnificantly more
> expansive as 1CPU (and notice, we count P-IV MMultiThread as 2 CPU)
Well, you have to compare like for like, so system with multiple CPUs
versus exact system without. No diffference in cost, other than for
the CPUs.
And if you want reliability, you're not going to be buying your
machines from the nearest Lidl (unless your application is engineered
to take advantage of dozens of cheap throwaway PCs).
> but increases system redundancy to the run-away processes. Of
> course, it is not hardware redundancy, but it REALLY works.
Not really.. this is a resource exhaustion problem, and you can not
cure this, given buggy apps, by throwing more CPUs at it.
Let's say you have some multi-process or multi-threaded application
which regularly spawns/forks new processes/threads, but it is buggy
and prone to having individual processes/threads spin.
So one spins, but you still have plenty of CPU time left cause you
have two CPUs. Another spins, and the machine starts to crawl. So you
solve this problem by upgrading to a quad-SMP machine. And guess what
happens? :)
Sure, there are some application bugs you can mask a wee bit with
SMP, but it's not much cop, its not a solution, and you need
an infinite-SMP machine to guarantee that a bad application
can never hog all CPU time.
What you really want is a good OS with:
- a good scheduler (to prevent spinning tasks from starving other
tasks)
- ability to set resource limits, ie per-task and/or per-user (if
your apps run under dedicated user accounts) limits on cpu time,
resident memory, etc..
Both of these will allow you to constrain the impact bad tasks can
have on the system, whether your machine is 1, 2, ... or n CPUs.
The real solution though is to fix the buggy application.
regards,
--
Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A
Fortune:
The life which is unexamined is not worth living.
-- Plato
More information about the NANOG
mailing list