On Mon, 23 Feb 1998, Lyle Seaman wrote:
> David Rankin wrote:
> > If the machines were strictly database machines or strictly fileservers,
> > the extra CPU probably would not matter, since the server processes aren't
> > multi-threaded. However, dual CPUs would allow the machine to (practically)
> > dedicate a CPU for file service and the second for database work.
> >
> > That said, you might consider taking the money for 3 dual-CPU machines and
> > cost out 6 "smaller" boxes, three for database work strictly, and the other
> > three strictly for file service. This will help lessen memory and I/O
> > bottlenecks, which are more likely than CPU bottlenecks anyway.
>
> I have seen file servers get CPU bound, though not lately. In this
> example, the extra CPU will be able to run the various other processes
> -- databases, volserver, bos, backup, as well as the operating system
> and miscellany. I think the critical factors in this decision are
> (1) the volume of volume operations
> (2) Price of 3x2 servers vs price of 3x1 servers + 3 castoff old pieces
> of junk to use for database servers.
I'd generally agree with this. On a particularly heavily-used server,
you may benefit from having multiple CPU's, if the OS uses them
effectively - remember that the fileserver spends most of its time
doing I/O, and most of the work involved in I/O actually happens in
the kernel. So on an OS like Solaris, which has a multithreaded kernel
with reasonably fine-grained locking, you can win.
On the other hand, database servers really can be, as Lyle puts it,
"castoffs old pieces of junk". We run ours Sparc 1's, with a couple
of other services (NTP, DNS, temperature monitoring) on the same
machines, and we've not seen any performance problems caused by this.
-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]>
Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
