Well, there are quite a few more variables to consider, including:
a) speed of the drives
b) battery backed caching controller or not
c) throughput of the controller channels
d) your particular use
Point d is kind of the most important. We've got about 250 customers talking to the same back-end database server with an IBM ServeRaid card. Our O/S is on a RAID 1 while our pgdata (including logs, in our case) is on an external FC array with 14 drives (12 online, 2 HSP, RAID 10). Our performance is pretty good, though we're a bit CPU bound (not I/O bound at this time) due to an older server system.
What sort of data/usage you're going to have in that database is pretty important. Heavy SELECT databases have different implications than heavy INSERT databases.
So far as the RAID controller goes, so long as it's got 2 or more channels, and the sustained throughput of the card is 100% on each channel, you're fine there.
We _did_ find a significant performance increase splitting our O/S and our PostgreSQL data, but *** in our case, at the time of testing *** we did not see an appreciable difference in splitting the logs off to their own volume.
----- "Renato Oliveira" <renato.oliveira@xxxxxxxxxxx> wrote:
>
a) speed of the drives
b) battery backed caching controller or not
c) throughput of the controller channels
d) your particular use
Point d is kind of the most important. We've got about 250 customers talking to the same back-end database server with an IBM ServeRaid card. Our O/S is on a RAID 1 while our pgdata (including logs, in our case) is on an external FC array with 14 drives (12 online, 2 HSP, RAID 10). Our performance is pretty good, though we're a bit CPU bound (not I/O bound at this time) due to an older server system.
What sort of data/usage you're going to have in that database is pretty important. Heavy SELECT databases have different implications than heavy INSERT databases.
So far as the RAID controller goes, so long as it's got 2 or more channels, and the sustained throughput of the card is 100% on each channel, you're fine there.
We _did_ find a significant performance increase splitting our O/S and our PostgreSQL data, but *** in our case, at the time of testing *** we did not see an appreciable difference in splitting the logs off to their own volume.
----- "Renato Oliveira" <renato.oliveira@xxxxxxxxxxx> wrote:
>
>
>
Good afternoon Guys,
I have been reading about RAID for PostgreSQL and some suggestions are:
6 SCSI Disks RAID10 for OS and DB
Or
2 SCSI Disks RAID 1 for OS + 4 SCSI RAID 10 for DB
I know the more spindles you have the better, but if you are going to be reading and writing to the same volume with a single controller, how good that will be?
How do you guys have your RAIDS setup?
Thank you
Renato
Renato Oliveira
> Systems Administrator
> e-mail: renato.oliveira@xxxxxxxxxxx
> Systems Administrator
> e-mail: renato.oliveira@xxxxxxxxxxx
Grant Instruments (Cambridge) Ltd
>
> Company registered in England, registration number 658133
>
> Registered office address:
> 29 Station Road,
> Shepreth,
> CAMBS SG8 6GB
> UK
>
> Company registered in England, registration number 658133
>
> Registered office address:
> 29 Station Road,
> Shepreth,
> CAMBS SG8 6GB
> UK
P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies.
VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s).
OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit our website
