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