Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD
> > On Sat, Aug 7, 2010 at 5:47 PM, Michael March wrote: > > If anyone is interested I just completed a series of benchmarks of stock > > Postgresql running on a normal HDD vs a SSD. > > If you don't want to read the post, the summary is that SSDs are 5 to 7 > > times faster than a 7200RPM HDD drive under a pgbench load. > > > http://it-blog.5amsolutions.com/2010/08/performance-of-postgresql-ssd-vs.html > > > > Is this what everyone else is seeing? > > Thanks! > > It's a good first swing, but I'd be interested in seeing how it runs > with various numbers of clients, and how it runs as the number of > clients goes past optimal. I.e. a nice smooth downward trend or a > horrible drop-off for whichever drives. > > Yeah. I was thinking the same thing.. I need to automate the tests so I can incrementally increase the scaling of the seed tables and increase of number simultaneous clients over time. Put another way,I need to do A LOT more tests that will gently increment all the testable factors one small step at a time.
Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD
On Sun, Aug 8, 2010 at 12:49 AM, Michael March wrote: > >> SSD's actually vary quite a bit with typical postgres benchmark workloads. > > You mean various SSDs from different vendors? Or are you saying the same SSD > model might vary in performance from drive to drive? > >> >> Many of them also do not guarantee data that has been sync'd will not be >> lost if power fails (most hard drives with a sane OS and file system do). > > What feature does an SSD need to have to insure that sync'd data is indeed > written to the SSD in the case of power loss? A big freaking capacitor and the ability to notice power's been cut and start writing out the cache. There are a few that have it that are coming out right about now. There was a post about one such drive a few days ago, it was like 50G and $450 or so, so not cheap, but not that bad compared to the $7000 drive bays with 16 15k6 drives I've used in to the past to get good performance (3 to 4k tps) -- To understand recursion, one must first understand recursion. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Advice configuring ServeRAID 8k for performance
On Sun, Aug 8, 2010 at 12:46 AM, Scott Carey wrote: > > On Aug 5, 2010, at 4:09 PM, Scott Marlowe wrote: > >> On Thu, Aug 5, 2010 at 4:27 PM, Pierre C wrote: >>> 1) Should I switch to RAID 10 for performance? I see things like "RAID 5 is bad for a DB" and "RAID 5 is slow with <= 6 drives" but I see little on RAID 6. >>> >>> As others said, RAID6 is RAID5 + a hot spare. >>> >>> Basically when you UPDATE a row, at some point postgres will write the page >>> which contains that row. >>> >>> RAID10 : write the page to all mirrors. >>> RAID5/6 : write the page to the relevant disk. Read the corresponding page >>> from all disks (minus one), compute parity, write parity. >> >> Actually it's not quite that bad. You only have to read from two >> disks, the data disk and the parity disk, then compute new parity and >> write to both disks. Still 2 reads / 2 writes for every write. >> >>> As you can see one small write will need to hog all drives in the array. >>> RAID5/6 performance for small random writes is really, really bad. >>> >>> Databases like RAID10 for reads too because when you need some random data >>> you can get it from any of the mirrors, so you get increased parallelism on >>> reads too. >> >> Also for sequential access RAID-10 can read both drives in a pair >> interleaved so you get 50% of the data you need from each drive and >> double the read rate there. This is even true for linux software md >> RAID. > > > My experience is that it is ONLY true for software RAID and ZFS. Most > hardware raid controllers read both mirrors and validate that the data is > equal, and thus writing is about as fast as read. Tested with Adaptec, > 3Ware, Dell PERC 4/5/6, and LSI MegaRaid hardware wise. In all cases it was > clear that the hardware raid was not using data from the two mirrors to > improve read performance for sequential or random I/O. Interesting. I'm using an Areca, I'll have to run some tests and see if a mirror is reading at > 100% read speed of a single drive or not. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD
Michael March wrote: If anyone is interested I just completed a series of benchmarks of stock Postgresql running on a normal HDD vs a SSD. If you don't want to read the post, the summary is that SSDs are 5 to 7 times faster than a 7200RPM HDD drive under a pgbench load. http://it-blog.5amsolutions.com/2010/08/performance-of-postgresql-ssd-vs.html Is this what everyone else is seeing? I tested a SSD with a capacitor and posted conclusions here http://archives.postgresql.org/pgsql-performance/2010-07/msg00449.php regards, Yeb Havinga -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
