Re: Hardware advice - Mailing list pgsql-performance

If your data is valuable I'd recommend against RAID5 ... see <http://www.miracleas.com/BAARF/RAID5_versus_RAID10.txt>

performance aside, I'd advise against RAID5 in almost all circumstances. Why take chances ?

Greg Williamson
DBA
GlobeXplorer LLC

-----Original Message-----
From:    pgsql-performance-owner@postgresql.org on behalf of Sven Geisler
Sent:    Wed 12/6/2006 1:09 AM
To:    Alex Turner
Cc:    Alexandru Coseru; pgsql-performance@postgresql.org
Subject:    Re: [PERFORM] Hardware advice

Hi Alex,

Please check out <http://www.powerpostgresql.com/PerfList> before you
use RAID 5 for PostgreSQL.

Anyhow, In a larger scale you end up in the response time of the I/O
system for an read or write. The read is in modern RAID and SAN
environments the part where you have to focus when you want to tune your
system because most RAID and SAN system can buffer write.
PostgreSQL does use the Linux file system cache which is normally much
larger then the RAID or SAN cache for reading. This means whenever a
PostgreSQL read goes to the RAID or SAN sub system the response time of
the hard disk will become interesting.
I guess you can imagine that multiple reads to the same spins are
causing an delay in the response time.


Alexandru,

You should have two XEONs, what every your core count is.
This would use the full benefit of the memory architecture.
You know two FSBs and two memory channels.

Cheers
Sven

Alex Turner schrieb:
> The test that I did - which was somewhat limited, showed no benefit
> splitting disks into seperate partitions for large bulk loads.
>
> 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@totaltelecom.ro
> <mailto:alexandru.coseru@totaltelecom.ro>> 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@aeccom.com <mailto:sgeisler@aeccom.com>>
>     To: "Alexandru Coseru" < alexandru.coseru@totaltelecom.ro
>     <mailto:alexandru.coseru@totaltelecom.ro>>
>     Cc: <pgsql-performance@postgresql.org
>     <mailto:pgsql-performance@postgresql.org>>
>     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
>     <http://archives.postgresql.org>
>
>

--
/This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you are not the intended recipient, you should not
copy it, re-transmit it, use it or disclose its contents, but should
return it to the sender immediately and delete your copy from your
system. Thank you for your cooperation./

Sven Geisler <sgeisler@aeccom.com> Tel +49.30.5362.1627 Fax .1638
Senior Developer,    AEC/communications GmbH    Berlin,   Germany

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

               http://archives.postgresql.org


-------------------------------------------------------
Click link below if it is SPAM gsw@globexplorer.com

"https://mailscanner.globexplorer.com/dspam/dspam.cgi?signatureID=4576889b113104295495211&user=gsw@globexplorer.com&retrain=spam&template=history&history_page=1"
!DSPAM:4576889b113104295495211!
-------------------------------------------------------