Re: How to make a REALLY FAST db server?

>> - Hardware:  dual / quad Intel class
>
>Fairly easy to obtain.  If all you want is a dual, you can use
>desktop-class motherboards from such makers as Asus, Abit, and
>IWill.  If you're going for speed, stick to the DDR or SDRAM
>capable boards.

I'm not sure how much a 2+ way system will help.  Most of the db work
will be done in one long serialized processes and those can't be spread
out over multiple processors (with current day postgresql).

>> - Disk:  SCSI Raid 1+0
>
>To really eek out as much speed as possible here, you'll want 10k RPM
>Ultra-160 Fibre Channel SCSI drives with a dedicated hardware raid
>controller.  If have more reads than writes, you may want to use Raid 5
>instead.

Why 5?  1+0 is far better and faster.  I was planning on doing a
hardware RAID controller (just need to find the one that FBSD likes the
best).

>Postgres won't let you separate indexes from the database they represent,
>so you can't make separate raid clusters for indexes and data; no
>optimization there.  Maybe in the next version that implements
>schemas?  What you can do if you use multiple DB's in your app design,
>is put different DB's on different raid clusters.  That'll help parallel
>execution times.  If you do this, make sure template1 and template0 are
>separated from the rest of the databases, this will allow fast responses
>from the system tables and make sure no application database IO affects
>them adversely.

Interesting thoughts..

>No reason not to go 2GB.  Ram is cheap these days, and you can always
>increase shared buffers and caches to actually fill the server memory
>up with as much quick-fetch info as possible.

But then why not 4G?  I would love some real numbers rather than 'a
lot'.  With oracle,  you can plug in some numbers and a real extimate
will be spit out.  I've worked with DB servers w/ 14G of ram that were
killing that,  so "get a lot" isn't really good enough.

>All in all, if you're making a DB machine, do whatever you can to get
>rid of hits caused by disk IO.  Parallelize as much as possible between
>your databases, and if you have a DB capable of separating indexes from

Regretfully,  it's only one database and the data model won't really
let me split it up much.

>the mix, do that too.  Don't run any other services on it, and make
>sure it has a nice wide 100MBit or 1GBit pipe so it doesn't saturate when
>servicing multiple hosts.

- Brandon

----------------------------------------------------------------------------
 b. palmer,  bpalmer@crimelabs.net            pgp:crimelabs.net/bpalmer.pgp5