Quoth mileskeaton@gmail.com (Miles Keaton):
> I'm sorry if there's a URL out there answering this, but I couldn't
> find it.
>
> For those of us that need the best performance possible out of a
> dedicated dual-CPU PostgreSQL server, what is recommended?
>
> AMD64/Opteron or i386/Xeon?
Xeon sux pretty bad...
> Linux or FreeBSD or _?_
The killer question won't be of what OS is "faster," but rather of
what OS better supports the fastest hardware you can get your hands
on.
We tried doing some FreeBSD benchmarking on a quad-Opteron box, only
to discover that the fibrechannel controller worked in what amounted
to a "PAE-like" mode where it only talked DMA in a 32 bit manner. We
might have found a more suitable controller, given time that was not
available.
A while back I tried to do some FreeBSD benchmarking on a quad-Xeon
box with 8GB of RAM. I couldn't find _any_ RAID controller compatible
with that configuration, so FreeBSD wasn't usable on that hardware
unless I told the box to ignore half the RAM.
There lies the rub of the problem: you need to make sure all the vital
components are able to run "full blast" in order to maximize
performance.
The really high end SCSI controllers may only have supported drivers
for some specific set of OSes, and it seems to be pretty easy to put
together boxes where one or another component leaps into the "That
Doesn't Work!" category.
> I'm assuming hardware RAID 10 on 15k SCSI drives is fastest disk
> performance.
RAID controllers tend to use i960 or StrongARM CPUs that run at speeds
that _aren't_ all that impressive. With software RAID, you can take
advantage of the _enormous_ increases in the speed of the main CPU.
I don't know so much about FreeBSD's handling of this, but on Linux,
there's pretty strong indication that _SOFTWARE_ RAID is faster than
hardware RAID.
It has the further merit that you're not dependent on some disk
formatting scheme that is only compatible with the model of RAID
controller that you've got, where if the controller breaks down, you
likely have to rebuild the whole array from scratch and your data is
toast.
The assumptions change if you're looking at really high end disk
arrays, but that's certainly another story.
--
(format nil "~S@~S" "cbbrowne" "acm.org")
http://linuxfinances.info/info/finances.html
Real Programmers are surprised when the odometers in their cars don't
turn from 99999 to A0000.
