From: | "Scott Marlowe" <smarlowe(at)qwest(dot)net> |
---|---|
To: | "Jason Coene" <jcoene(at)gotfrag(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Hardware upgrade for a high-traffic database |
Date: | 2004-08-11 00:00:01 |
Message-ID: | 1092182401.27166.348.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, 2004-08-10 at 13:17, Jason Coene wrote:
> Hi All,
>
> We're currently running Postgres 7.4.1 on FreeBSD 5.2, a Dual Xeon 2.4, 2GB
> ECC, 3Ware Serial ATA RAID 5 w/ 4 disks (SLOW!!).
>
> Our database is about 20GB on disk, we have some quite large tables - 2M
> rows with TEXT fields in a sample table, accessed constantly. We average
> about 4,000 - 5,000 queries per second - all from web traffic. As you can
> imagine, we're quite disk limited and checkpoints can be killer.
> Additionally, we see queries and connections getting serialized due to
> queries that take a long time (5 sec or so) while waiting on disk access.
> No fun at all.
>
> We've tweaked everything long and hard, and at the end of the day, the disk
> is killing us.
>
> We're looking to upgrade our server - or rather, replace it as it has no
> upgrade path to SCSI. I'm considering going Opteron (though right now we
> don't need more CPU time), and am looking for suggestions on what an optimal
> RAID configuration may look like (disks, controller, cache setting). We're
> in the market to buy right now - any good vendor suggestions?
I've had very good luck with LSI MegaRAID controllers with battery
backed cache. The amount of cache doesn't seem as important as having
it, and having it set for write back.
After that, 2 gigs or more of memory is the next improvement.
After that, the speed of the memory.
From | Date | Subject | |
---|---|---|---|
Next Message | Jason Coene | 2004-08-11 01:06:37 | Re: Hardware upgrade for a high-traffic database |
Previous Message | Rod Taylor | 2004-08-10 23:06:52 | Re: Hardware upgrade for a high-traffic database |