The program read from one very large file and wrote the input out to two other large files.
The totaly throughput on a single partition was close to the maximum theoretical for that logical drive, even though the process was reading and writing to three seperate places on the disk. I don't know what this means for postgresql setups directly, but I would postulate that the benefit from splitting pg_xlog onto a seperate spindle is not as great as it might once have been for large bulk transactions. I am therefore going to be going to a single 6 drive RAID 5 for my data wharehouse application because I want the read speed to be availalbe. I can benefit from fast reads when I want to do large data scans at the expense of slightly slower insert speed.
Alex.
On 12/5/06, Alexandru Coseru <alexandru.coseru@xxxxxxxxxxxxxxx> wrote:
Hello..
Thanks for the advices..
Actually , i'm waiting for the clovertown to show up on the market...
Regards
Alex
----- Original Message -----
From: "Sven Geisler" <sgeisler@xxxxxxxxxx>
To: "Alexandru Coseru" < alexandru.coseru@xxxxxxxxxxxxxxx>
Cc: <pgsql-performance@xxxxxxxxxxxxxx>
Sent: Tuesday, December 05, 2006 11:57 AM
Subject: Re: [PERFORM] Hardware advice
> Hi Alexandru,
>
> Alexandru Coseru schrieb:
>> [...]
>> Question 1:
>> The RAID layout should be:
>> a) 2 hdd in raid 1 for system and pg_xlog and 6 hdd in
>> raid10 for data ?
>> b) 8 hdd in raid10 for all ?
>> c) 2 hdd in raid1 for system , 2 hdd in raid1 for pg_xlog ,
>> 4 hdd in raid10 for data ?
>> Obs: I'm going for setup a) , but i want to hear your thoughts as
>> well.
>
> This depends on you data size. I think, option a and c are good.
> The potential bottleneck may the RAID 1 for pg_xlog if you have huge
> amount of updates and insert.
> What is about another setup
>
> 4 hdd in RAID 10 for System and pg_xlog - System partitions are normally
> not in heavy use and pg_xlog should be fast for writing.
> 4 hdd in RAID 10 for data.
>
>>
>>
>> Question 2: (Don't want to start a flame here..... but here is goes)
>> What filesystem should i run for data ? ext3 or xfs ?
>> The tables have ~ 15.000 rel_pages each. The biggest table has
>> now over 30.000 pages.
>
> We have a database running with 60,000+ tables. The tables size is
> between a few kByte for the small tables and up to 30 GB for the largest
> one. We had no issue with ext3 in the past.
>
>>
>> Question 3:
>> The block size in postgresql is 8kb. The strip size in the
>> raid ctrl is 64k.
>> Should i increase the pgsql block size to 16 or 32 or even 64k ?
>
> You should keep in mind that the file system has also a block size. Ext3
> has as maximum 4k.
> I would set up the partitions aligned to the stripe size to prevent
> unaligned reads. I guess, you can imagine that a larger block size of
> postgresql may also end up in unaligned reads because the file system
> has a smaller block size.
>
> RAID Volume and File system set up
> 1. Make all partitions aligned to the RAID strip size.
> The first partition should be start at 128 kByte.
> You can do this with fdisk. after you created the partition switch
> to the expert mode (type x) and modify the begin of the partition
> (type b). You should change this value to 128 (default is 63).
> All other partition should also start on a multiple of 128 kByte.
>
> 2. Give the file system a hint that you work with larger block sizes.
> Ext3: mke2fs -b 4096 -j -R stride=2 /dev/sda1 -L LABEL
> I made a I/O test with PostgreSQL on a RAID system with stripe size
> of 64kByte and block size of 8 kByte in the RAID system.
> Stride=2 was the best value.
>
>
> PS: You should have a second XEON in your budget plan.
>
> Sven.
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.409 / Virus Database: 268.15.7/569 - Release Date: 12/5/2006
>
>
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
