Thread

1. Re: Tuning PostgreSQL

   Shridhar Daithankar <shridhar_daithankar@persistent.co.in> — 2003-07-21T09:33:14Z

   Hi Alexander ,
   
   On 21 Jul 2003 at 11:23, Alexander Priem wrote:
   > So the memory settings I specified are pretty much OK?
   
   As of now yes, You need to test with these settings and make sure that they 
   perform as per your requirement. That tweaking will always be there...
   
   > What would be good guidelines for setting effective_cache_size, noatime ?
   
   I suggest you look at 
   http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html. 
   
   That should help you.
   
   > I use ext3 filesystem, which probably is not the best performer, is it?
   
   No. You also need to check ext2, reiser and XFS. There is no agreement between 
   users as in what works best. You need to benchmark and decide.
   
   > I will set the WAL on a separate drive. What do I need to change in the conf
   > files to achive this?
   
   No. You need to shutdown postgresql server process and symlink WAL and clog 
   directories in postgresql database cluster to another place. That should do it.
   
   HTH
   
   Bye
    Shridhar
   
   --
   Meade's Maxim:	Always remember that you are absolutely unique, just like everyone else.
   
   
   

2. Re: Tuning PostgreSQL

   Priem, Alexander <ap@cict.nl> — 2003-07-21T09:40:42Z

   Thanks, I will look at the site you sent me and purchase some hardware. Then
   I will run some benchmarks.
   
   Kind regards,
   Alexander.
   
   ----- Original Message -----
   From: "Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>
   To: "Alexander Priem" <ap@cict.nl>
   Cc: <pgsql-performance@postgresql.org>
   Sent: Monday, July 21, 2003 11:33 AM
   Subject: Re: [PERFORM] Tuning PostgreSQL
   
   
   > Hi Alexander ,
   >
   > On 21 Jul 2003 at 11:23, Alexander Priem wrote:
   > > So the memory settings I specified are pretty much OK?
   >
   > As of now yes, You need to test with these settings and make sure that
   they
   > perform as per your requirement. That tweaking will always be there...
   >
   > > What would be good guidelines for setting effective_cache_size, noatime
   ?
   >
   > I suggest you look at
   > http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html.
   >
   > That should help you.
   >
   > > I use ext3 filesystem, which probably is not the best performer, is it?
   >
   > No. You also need to check ext2, reiser and XFS. There is no agreement
   between
   > users as in what works best. You need to benchmark and decide.
   >
   > > I will set the WAL on a separate drive. What do I need to change in the
   conf
   > > files to achive this?
   >
   > No. You need to shutdown postgresql server process and symlink WAL and
   clog
   > directories in postgresql database cluster to another place. That should
   do it.
   >
   > HTH
   >
   > Bye
   >  Shridhar
   >
   > --
   > Meade's Maxim: Always remember that you are absolutely unique, just like
   everyone else.
   >
   
   
   

3. Re: Tuning PostgreSQL

   Ang Chin Han <angch@bytecraft.com.my> — 2003-07-21T10:09:23Z

   Shridhar Daithankar wrote:
   > On 21 Jul 2003 at 11:23, Alexander Priem wrote:
   
   >>I use ext3 filesystem, which probably is not the best performer, is it?
   > 
   > No. You also need to check ext2, reiser and XFS. There is no agreement between 
   > users as in what works best. You need to benchmark and decide.
   
   Need? Maybe I'm a bit disillusioned, but are the performances between 
   the filesystems differ so much as to warrant the additional effort? 
   (e.g. XFS doesn't come with Red Hat 9 -- you'll have to patch the 
   source, and compile it yourself).
   
   Benchmarking it properly before deployment is tough: are the test load 
   on the db/fs representative of actual load? Is 0.5% reduction in CPU 
   usage worth it? Did you test for catastrophic failure by pulling the 
   plug during write operations (ext2) to test if the fs can handle it? Is 
   the code base for the particular fs stable enough? Obscure bugs in the fs?
   
   For the record, we tried several filesystems, but stuck with 2.4.9's 
   ext3 (Red Hat Advanced Server). Didn't hit a load high enough for the 
   filesystem choices to matter after all. :(
   
   -- 
   Linux homer 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 
   GNU/Linux
      5:30pm  up 207 days,  8:35,  5 users,  load average: 5.33, 5.16, 5.21
   

4. Re: Tuning PostgreSQL

   Shridhar Daithankar <shridhar_daithankar@persistent.co.in> — 2003-07-21T10:31:41Z

   On 21 Jul 2003 at 18:09, Ang Chin Han wrote:
   
   > Shridhar Daithankar wrote:
   > > On 21 Jul 2003 at 11:23, Alexander Priem wrote:
   > 
   > >>I use ext3 filesystem, which probably is not the best performer, is it?
   > > 
   > > No. You also need to check ext2, reiser and XFS. There is no agreement between 
   > > users as in what works best. You need to benchmark and decide.
   > 
   > Need? Maybe I'm a bit disillusioned, but are the performances between 
   > the filesystems differ so much as to warrant the additional effort? 
   > (e.g. XFS doesn't come with Red Hat 9 -- you'll have to patch the 
   > source, and compile it yourself).
   
   Well, the benchmarking is not to prove which filesystem is fastest and feature 
   rich but to find out which one suits your needs best.
    
   > Benchmarking it properly before deployment is tough: are the test load 
   > on the db/fs representative of actual load? Is 0.5% reduction in CPU 
   > usage worth it? Did you test for catastrophic failure by pulling the 
   > plug during write operations (ext2) to test if the fs can handle it? Is 
   > the code base for the particular fs stable enough? Obscure bugs in the fs?
   
   Well, that is what that 'benchmark' is supposed to find out. Call it pre-
   deployment testing or whatever other fancy name one sees fit. But it is a must 
   in almost all serious usage.
    
   > For the record, we tried several filesystems, but stuck with 2.4.9's 
   > ext3 (Red Hat Advanced Server). Didn't hit a load high enough for the 
   > filesystem choices to matter after all. :(
   
   Good for you. You have time at hand to find out which one suits you best. Do 
   the testing before you have load that needs another FS..:-)
   
   Bye
    Shridhar
   
   --
   It would be illogical to assume that all conditions remain stable.		-- Spock, "The Enterprise" Incident", stardate 5027.3
   
   
   

5. Re: Tuning PostgreSQL

   Ang Chin Han <angch@bytecraft.com.my> — 2003-07-21T11:27:54Z

   Shridhar Daithankar wrote:
   
   > Good for you. You have time at hand to find out which one suits you best. Do 
   > the testing before you have load that needs another FS..:-)
   
   Kinda my point is that when we've more load, we'd be using RAID-0 over 
   RAID-5, or getting faster SCSI drives, or even turn fsync off if that's 
   a bottleneck, because the different filesystems do not have that much 
   performance difference[1] -- the filesystem is not a bottleneck. Just 
   need to tweak most of them a bit, like noatime,data=writeback.
   
   [1] That is, AFAIK, from our testing. Please, please correct me if I'm 
   wrong: has anyone found that different filesystems produces wildly 
   different performance for postgresql, FreeBSD's filesystems not included?
   
   -- 
   Linux homer 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 
   GNU/Linux
      7:00pm  up 207 days, 10:05,  5 users,  load average: 5.00, 5.03, 5.06
   

6. Re: Tuning PostgreSQL

   Shridhar Daithankar <shridhar_daithankar@persistent.co.in> — 2003-07-21T11:39:30Z

   On 21 Jul 2003 at 19:27, Ang Chin Han wrote:
   > [1] That is, AFAIK, from our testing. Please, please correct me if I'm 
   > wrong: has anyone found that different filesystems produces wildly 
   > different performance for postgresql, FreeBSD's filesystems not included?
   
   well, when postgresql starts splitting table files after a gig, filesystem sure 
   makes difference. IIRC, frommy last test XFS was at least 10-15% faster than 
   reiserfs for such databases. That was around an year back, with mandrake 8.0.
   
   
   Bye
    Shridhar
   
   --
   modesty, n.:	Being comfortable that others will discover your greatness.
   
   
   

7. Re: Tuning PostgreSQL

   Priem, Alexander <ap@cict.nl> — 2003-07-21T11:45:06Z

   So where can I set the noatime & data=writeback variables? They are not
   PostgreSQL settings, but rather Linux settings, right? Where can I find
   these?
   
   Kind regards,
   Alexander Priem.
   
   
   ----- Original Message -----
   From: "Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>
   To: <pgsql-performance@postgresql.org>
   Sent: Monday, July 21, 2003 12:31 PM
   Subject: Re: [PERFORM] Tuning PostgreSQL
   
   
   > On 21 Jul 2003 at 18:09, Ang Chin Han wrote:
   >
   > > Shridhar Daithankar wrote:
   > > > On 21 Jul 2003 at 11:23, Alexander Priem wrote:
   > >
   > > >>I use ext3 filesystem, which probably is not the best performer, is
   it?
   > > >
   > > > No. You also need to check ext2, reiser and XFS. There is no agreement
   between
   > > > users as in what works best. You need to benchmark and decide.
   > >
   > > Need? Maybe I'm a bit disillusioned, but are the performances between
   > > the filesystems differ so much as to warrant the additional effort?
   > > (e.g. XFS doesn't come with Red Hat 9 -- you'll have to patch the
   > > source, and compile it yourself).
   >
   > Well, the benchmarking is not to prove which filesystem is fastest and
   feature
   > rich but to find out which one suits your needs best.
   >
   > > Benchmarking it properly before deployment is tough: are the test load
   > > on the db/fs representative of actual load? Is 0.5% reduction in CPU
   > > usage worth it? Did you test for catastrophic failure by pulling the
   > > plug during write operations (ext2) to test if the fs can handle it? Is
   > > the code base for the particular fs stable enough? Obscure bugs in the
   fs?
   >
   > Well, that is what that 'benchmark' is supposed to find out. Call it pre-
   > deployment testing or whatever other fancy name one sees fit. But it is a
   must
   > in almost all serious usage.
   >
   > > For the record, we tried several filesystems, but stuck with 2.4.9's
   > > ext3 (Red Hat Advanced Server). Didn't hit a load high enough for the
   > > filesystem choices to matter after all. :(
   >
   > Good for you. You have time at hand to find out which one suits you best.
   Do
   > the testing before you have load that needs another FS..:-)
   >
   > Bye
   >  Shridhar
   >
   > --
   > It would be illogical to assume that all conditions remain stable. --
   Spock, "The Enterprise" Incident", stardate 5027.3
   >
   >
   > ---------------------------(end of broadcast)---------------------------
   > TIP 9: the planner will ignore your desire to choose an index scan if your
   >       joining column's datatypes do not match
   
   
   

8. Re: Tuning PostgreSQL

   Shridhar Daithankar <shridhar_daithankar@persistent.co.in> — 2003-07-21T12:05:03Z

   On 21 Jul 2003 at 13:45, Alexander Priem wrote:
   
   > So where can I set the noatime & data=writeback variables? They are not
   > PostgreSQL settings, but rather Linux settings, right? Where can I find
   > these?
   
   These are typicaly set in /etc/fstab.conf. These are mount settings. man mount 
   for more details. 
   
   The second setting data=writeback is ext3 specific, IIRC.
   
   HTH
   
   Bye
    Shridhar
   
   --
   History tends to exaggerate.		-- Col. Green, "The Savage Curtain", stardate 
   5906.4
   
   
   

9. Re: Tuning PostgreSQL

   Priem, Alexander <ap@cict.nl> — 2003-07-21T12:43:22Z

   Thanks, i'll look further into these mount setting.
   
   I was just thinking, the server will have a (RAID) controller containing
   128Mb of battery-backed cache memory. This would really speed up inserts to
   the disk and would prevent data loss in case of a power-down also.
   
   What would you guys think of not using RAID5 in that case, but just a really
   fast 15.000 rpm SCSI-320 disk?
   
   Kind regards,
   Alexander.
   
   
   ----- Original Message -----
   From: "Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>
   To: <pgsql-performance@postgresql.org>
   Sent: Monday, July 21, 2003 2:05 PM
   Subject: Re: [PERFORM] Tuning PostgreSQL
   
   
   > On 21 Jul 2003 at 13:45, Alexander Priem wrote:
   >
   > > So where can I set the noatime & data=writeback variables? They are not
   > > PostgreSQL settings, but rather Linux settings, right? Where can I find
   > > these?
   >
   > These are typicaly set in /etc/fstab.conf. These are mount settings. man
   mount
   > for more details.
   >
   > The second setting data=writeback is ext3 specific, IIRC.
   >
   > HTH
   >
   > Bye
   >  Shridhar
   >
   > --
   > History tends to exaggerate. -- Col. Green, "The Savage Curtain", stardate
   > 5906.4
   >
   >
   > ---------------------------(end of broadcast)---------------------------
   > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
   
   
   

10. Re: Tuning PostgreSQL

    Ron Johnson <ron.l.johnson@cox.net> — 2003-07-22T09:52:56Z

    On Mon, 2003-07-21 at 04:33, Shridhar Daithankar wrote:
    > Hi Alexander ,
    > 
    > On 21 Jul 2003 at 11:23, Alexander Priem wrote:
    [snip]
    > > I use ext3 filesystem, which probably is not the best performer, is it?
    > 
    > No. You also need to check ext2, reiser and XFS. There is no agreement between 
    > users as in what works best. You need to benchmark and decide.
    
    According to Jeremy Allison of SAMBA, ""They used ext3, which is one
    of the slowest filesystems on Linux," Allison said. "In a real
    comparative test, you would use XFS".
    http://www.linuxworld.com/story/32673.htm
    
    -- 
    +-----------------------------------------------------------------+
    | Ron Johnson, Jr.        Home: ron.l.johnson@cox.net             |
    | Jefferson, LA  USA                                              |
    |                                                                 |
    | "I'm not a vegetarian because I love animals, I'm a vegetarian  |
    |  because I hate vegetables!"                                    |
    |    unknown                                                      |
    +-----------------------------------------------------------------+
    
    
    
    

11. Re: Tuning PostgreSQL

    Priem, Alexander <ap@cict.nl> — 2003-07-22T12:53:58Z

    Wow, I never figured how many different RAID configurations one could think
    of   :)
    
    After reading lots of material, forums and of course, this mailing-list, I
    think I am going for a RAID5 configuration of 6 disks (18Gb, 15.000 rpm
    each), one of those six disks will be a 'hot spare'. I will just put the OS,
    the WAL and the data one one volume. RAID10 is way to expensive   :)
    
    If I understand correctly, this will give great read-performance, but less
    write-performance. But since this server will be equipped with an embedded
    RAID controller featuring 128Mb of battery-backed cache, I figure that this
    controller will negate that (at least somewhat). I will need to find out
    whether this cache can be configured so that it will ONLY cache WRITES, not
    READS....
    
    Also because of this battery backed cache controller, I will go for the ext2
    file system, mounted with 'noatime'. I will use a UPS, so I don't think I
    need the journaling of ext3. XFS is not natively supported by RedHat and I
    will go for the easy way here   :)
    
    1 Gb of RAM should be enough, I think. That is about the only point that
    almost everyone agrees on   :)   Do you think ECC is very important? The
    server I have in mind does not support it. Another one does, but is is about
    1.000 euros more expensive   :(
    
    One CPU should also be enough.
    
    As for postgresql.conf settings, I think I will start with the following :
    
    max_connections = 128
    superuser_reserved_connections = 1
    shared_buffers = 8192
    max_fsm_relations = 1000
    max_fsm_pages = 100000
    wal_buffers = 32
    sort_mem = 2048
    vacuum_mem = 32768
    effective_cache_size = 28672 (this one I'm not sure about, maybe this one
    needs to be higher)
    random_page_cost = 2
    geq0_threshold = 20
    
    This pretty much sums it up. What do you think about this config? It may not
    be the fastest, but a server like this will cost about 4750 euros, and that
    is including an Intel Xeon 2.4GHz cpu, redundant power supply, WITHOUT the
    UPS. Seems very reasonable to me...
    
    Kind regards,
    Alexander Priem.
    
    
    

12. Re: Tuning PostgreSQL

    Ron Johnson <ron.l.johnson@cox.net> — 2003-07-22T14:37:45Z

    On Tue, 2003-07-22 at 07:53, Alexander Priem wrote:
    > Wow, I never figured how many different RAID configurations one could think
    [snip]
    > Also because of this battery backed cache controller, I will go for the ext2
    > file system, mounted with 'noatime'. I will use a UPS, so I don't think I
    > need the journaling of ext3.
    
    Oooooo, I don't think I'd do that!!!!!  It's akin to saying, "I
    don't need to make backups, because I have RAID[1,5,10,1+0]
    
    If the power is out for 26 minutes and your UPS only lasts for 25
    minutes, you could be in be in for a long, painful boot process if
    the box crashes.  (For example, the UPS auto-shutdown daemon doesn't
    work properly, and no one can get to the console to shut it down
    properly before the batteries die.)
    
    
    -- 
    +-----------------------------------------------------------------+
    | Ron Johnson, Jr.        Home: ron.l.johnson@cox.net             |
    | Jefferson, LA  USA                                              |
    |                                                                 |
    | "I'm not a vegetarian because I love animals, I'm a vegetarian  |
    |  because I hate vegetables!"                                    |
    |    unknown                                                      |
    +-----------------------------------------------------------------+
    
    
    
    

13. Re: Tuning PostgreSQL

    Andrew McMillan <andrew@catalyst.net.nz> — 2003-07-25T10:45:38Z

    On Wed, 2003-07-23 at 00:53, Alexander Priem wrote:
    > Wow, I never figured how many different RAID configurations one could think
    > of   :)
    > 
    > After reading lots of material, forums and of course, this mailing-list, I
    > think I am going for a RAID5 configuration of 6 disks (18Gb, 15.000 rpm
    > each), one of those six disks will be a 'hot spare'. I will just put the OS,
    > the WAL and the data one one volume. RAID10 is way to expensive   :)
    
    The general heuristic is that RAID-5 is not the way to deal with
    databases.  Now surely someone will disagree with me, but as I
    understand it RAID-5 has a bottleneck on a single disk for the
    (checksum) information.  Bottleneck is not the word you want to hear in
    the context of "database server".
    
    RAID-1 (mirroring) or RAID-10 (sort-of-mirrored-RAID-5) is the best
    choice.
    
    As far as FS performance goes, a year or two ago I remember someone
    doing an evaluation of FS performance for PostgreSQL and they found that
    the best performance was...
    
    FAT
    
    Yep: FAT
    
    The reason is that a lot of what the database is doing, especially
    guaranteeing writes (WAL) and so forth is best handled through a
    filesystem that does not get in the way.  The fundamentals will not have
    changed.
    
    It is for this reason that ext2 is very much likely to be better than
    ext3.  XFS is possibly (maybe, perhaps) OK, because there are
    optimisations in there for databases, but the best optimisation is to
    not be there at all.  That's why Oracle want direct IO to disk
    partitions so they can implement their own "filesystem" (i.e. record
    system... table system...) on a raw partition.
    
    Personally I don't plan to reboot my DB server more than once a year (if
    that (even my_laptop currently has 37 days uptime, not including
    suspend).  On our DB servers I use ext2 (rather than ext3) mounted with
    noatime, and I bite the 15 minutes to fsck (once a year) rather than
    screw general performance with journalling database on top of
    journalling FS.  I split pg_xlog onto a separate physical disk, if
    performance requirements are extreme. 
    
    Catalyst's last significant project was to write the Domain Name
    registration system for .nz (using PostgreSQL).  Currently we are
    developing the electoral roll for the same country (2.8 million electors
    living at 1.4 million addresses).  We use Oracle (or Progress, or MySQL)
    if a client demands them, but we use PostgreSQL if we get to choose.
    Increasingly we get to choose.  Good.
    
    Regards,
    					Andrew.
    -- 
    ---------------------------------------------------------------------
    Andrew @ Catalyst .Net.NZ Ltd, PO Box 11-053, Manners St,  Wellington
    WEB: http://catalyst.net.nz/         PHYS: Level 2, 150-154 Willis St
    DDI: +64(4)916-7201     MOB: +64(21)635-694    OFFICE: +64(4)499-2267
               Survey for nothing with http://survey.net.nz/ 
    ---------------------------------------------------------------------
    
    
    

14. Re: Tuning PostgreSQL

    Arjen van der Meijden <acmmailing@vulcanus.its.tudelft.nl> — 2003-07-26T10:18:37Z

    > Andrew McMillan wrote:
    >
    > The general heuristic is that RAID-5 is not the way to deal 
    > with databases.  Now surely someone will disagree with me, 
    > but as I understand it RAID-5 has a bottleneck on a single 
    > disk for the
    > (checksum) information.  Bottleneck is not the word you want 
    > to hear in the context of "database server".
    That's indeed incorrect. There is no single disk "special" in a Raid-5,
    you might be mistaking it for Raid-3/4 (where a single disk holds the
    checksum). In raid-5 the checksums are scattered around on all the
    harddisks.
    Raid-5's problem is the write-performance, but with a decent
    raid-controller it outperforms a less-decent raid-controller (with the
    same harddisks) on both read- and writeperformance which is running a
    raid-10.
    With a decent raid-controller you end up with "about the same" write
    performance as with raid-1, but slightly lower read performance.
    
    At least, that's what I was able to gather from some tests of a
    colleague of mine with different raid-setups.
    
    > RAID-1 (mirroring) or RAID-10 (sort-of-mirrored-RAID-5) is 
    > the best choice.
    Raid-10 is _not_ similar to raid-5, it is raid1+0 i.e. a mirroring set
    of stripes (raid-0 is more-or-less a stripe).
    
    For databases, raid-10 is supposed to be the fastest, since you have the
    advantage of the striping for both reading and writing. While you also
    have the advantage of the mirroring for reading.
    
    The main disadvantage of raid-1 (and also of raid-10) is the heavy waste
    of harddisk space. Another advantage of raid-5 over raid-10 is that when
    you don't care about space, raid-5 is more save with four harddrives
    than raid-10 (i.e. set it up with a 3-disk+1spare).
    
    > As far as FS performance goes, a year or two ago I remember 
    > someone doing an evaluation of FS performance for PostgreSQL 
    > and they found that the best performance was...
    > 
    > FAT
    > 
    > Yep: FAT
    FAT has a few disadvantages afaik, I wouldn't use it for my database at
    least.
    
    > Personally I don't plan to reboot my DB server more than once 
    > a year (if that (even my_laptop currently has 37 days uptime, 
    > not including suspend).  On our DB servers I use ext2 (rather 
    > than ext3) mounted with noatime, and I bite the 15 minutes to 
    > fsck (once a year) rather than screw general performance with 
    > journalling database on top of journalling FS.  I split 
    > pg_xlog onto a separate physical disk, if performance 
    > requirements are extreme. 
    Well, reboting is not a problem with ext2, but crashing might be... And
    normally you don't plan a systemcrash ;)
    Ext3 and xfs handle that much better.
    
    Regards,
    
    Arjen
    
    
    
    
    

15. Re: Tuning PostgreSQL

    Tom Lane <tgl@sss.pgh.pa.us> — 2003-07-26T14:12:35Z

    "Arjen van der Meijden" <acmmailing@vulcanus.its.tudelft.nl> writes:
    > Well, reboting is not a problem with ext2, but crashing might be... And
    > normally you don't plan a systemcrash ;)
    > Ext3 and xfs handle that much better.
    
    A journaling filesystem is good to use if you can set it to journal
    metadata but not file contents.  PG's WAL logic can recover lost file
    contents, but we have no way to help out the filesystem if it's lost
    metadata.
    
    			regards, tom lane
    
    

16. Re: Tuning PostgreSQL

    Balazs Wellisch <balazs@neusolutions.com> — 2003-07-26T21:08:34Z

    Since there seem to be a lot of different opinions regarding the various
    different RAID configurations I thought I'd post this link to the list:
    http://www.storagereview.com/guide2000/ref/hdd/perf/raid/index.html
    
    This is the best resource for information on RAID and hard drive
    performance I found online.
    
    I hope this helps.
    
    Balazs
    
    
    
    
    
    

17. Re: Tuning PostgreSQL

    Josh Berkus <josh@agliodbs.com> — 2003-07-28T17:10:02Z

    Balasz,
    
    > Since there seem to be a lot of different opinions regarding the various
    > different RAID configurations I thought I'd post this link to the list:
    > http://www.storagereview.com/guide2000/ref/hdd/perf/raid/index.html
    
    Yeah ... this is  a really good article.  Made me realize why "stripey" RAID 
    sucks for OLTP databases, unless you throw a lot of platters at them.
    
    -- 
    Josh Berkus
    Aglio Database Solutions
    San Francisco