On Thu, 16 Oct 2008, Roberto Scattini wrote:
It's a old HP Proliant DL580 G3 with three disks (147 GB each).
Currently it has a debian Sarge in a RAID5 hardware array ( with HP
Smart Array 6i, [RAID bus controller: Compaq Computer Corporation Smart
Array 64xx (rev 01)] ).
I think all of the 64xx controllers have a reasonable amount of
battery-backed cache; with 3 disks you have a 6404 maybe? That's got
256MB of cache.
The reason this is so important is that much of the advantage of having a
separate disk for the WAL goes away with a good caching controller. Also,
if you've only got a small number of database disks, you're not going to
have the WAL as a bottleneck anyway.
-is raid5 the worst election in this scenario (three disks)?
-which is the best (and with that i mean secure in first place and
with more perfomance in second) possible configuration achievable with
this three disks?
If I take "secure in the first place" to mean that you must be able to
survive a disk failure, there are only two options here:
-RAID5 with 3 disks
-RAID1 pair with hotspare
If your write load is low (you said OLTP which means it probably isn't)
and you need as much space as possible the RAID5 might be a reasonable
choice, but these are both relatively bad solutions.
-should i ask my boss to buy another disk? (it will be difficult, but
if i can demonstrate It worth it...)
Having 4 disks in a RAID0+1 would be the ideal situation here for
balancing performance and reliability. Just throw them all into one big
volume and let the filesystem and controller balance everything out.
It's unlikely you'll run into the WAL being the bottleneck if there's only
two database disks and you have a caching controller.
i think i will "Separate the Transaction Log from the Database" with
two RAID1 arrays (if they buy the new disk). is this a good way to go?
it would be too bad if i put the logs in a disk without RAID? (only if
i dont get the new disk...)
Do not consider the transaction logs to be an optional component less
important than the database itself; if you lose them, you'll be hard
pressed to recover from that.
our application (running on separate webserver) is of the type "OLTP",
the server will be entirely dedicated to postgresql. i will configure
a warm-standby server, so the WAL files will be forwarded to another
server.
If you're keeping a warm-standby server around, the loss of a database
disk might not be as big of a problem--you can keep that fairly up to
date. Really depends on what the business guarantees required are.
--
* Greg Smith gsmith@xxxxxxxxxxxxx http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
