Re: Slow restoration question - Mailing list pgsql-performance
From | Brendan Duddridge |
---|---|
Subject | Re: Slow restoration question |
Date | |
Msg-id | 4A7F9950-65E0-4FA5-9FEC-BA1A93E615E5@clickspace.com Whole thread Raw |
In response to | Re: Slow restoration question ("Jim C. Nasby" <jnasby@pervasive.com>) |
Responses |
Re: Slow restoration question
|
List | pgsql-performance |
Hi Jim, The output from bonnie on my boot drive is: File './Bonnie.27964', size: 0 Writing with putc()...done Rewriting...done Writing intelligently...done Reading with getc()...done Reading intelligently...done Seeker 2...Seeker 1...Seeker 3...start 'em...done...done...done... -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec % CPU /sec %CPU 0 36325 98.1 66207 22.9 60663 16.2 50553 99.9 710972 100.0 44659.8 191.3 And the output from the RAID drive is: File './Bonnie.27978', size: 0 Writing with putc()...done Rewriting...done Writing intelligently...done Reading with getc()...done Reading intelligently...done Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done... -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec % CPU /sec %CPU 0 40365 99.4 211625 61.4 212425 57.0 50740 99.9 730515 100.0 45897.9 190.1 Each drive in the RAID 5 is a 400 GB serial ATA drive. I'm not sure the manufacturer or the model number as it was all in a packaged box when we received it and I didn't check. Do these numbers seem decent enough for a Postgres database? Thanks, ____________________________________________________________________ Brendan Duddridge | CTO | 403-277-5591 x24 | brendan@clickspace.com ClickSpace Interactive Inc. Suite L100, 239 - 10th Ave. SE Calgary, AB T2G 0V9 http://www.clickspace.com On May 2, 2006, at 3:53 PM, Jim C. Nasby wrote: > BTW, you should be able to check to see what the controller is > actually > doing by pulling one of the drives from a running array. If it only > hammers 2 drives during the rebuild, it's RAID10. If it hammers all > the > drives, it's 0+1. > > As for Xserve raid, it is possible to eliminate most (or maybe even > all) > of the overhead associated with RAID5, depending on how tricky the > controller wants to be. I believe many large storage appliances > actually > use RAID5 internally, but they perform a bunch of 'magic' behind the > scenes to get good performance from it. So, it is possible that the > XServe RAID performs quite well on RAID5. If you provided the results > from bonnie as well as info about the drives I suspect someone here > could tell you if you're getting close to RAID10 performance or not. > > On Tue, May 02, 2006 at 02:34:16PM -0500, Will Reese wrote: >> RAID 10 is better than RAID 0+1. There is a lot of information on >> the net about this, but here is the first one that popped up on >> google for me. >> >> http://www.pcguide.com/ref/hdd/perf/raid/levels/multLevel01-c.html >> >> The quick summary is that performance is about the same between the >> two, but RAID 10 gives better fault tolerance and rebuild >> performance. I have seen docs for RAID cards that have confused >> these two RAID levels. In addition, some cards claim to support RAID >> 10, when they actually support RAID 0+1 or even RAID 0+1 with >> concatenation (lame, some of the Dell PERCs have this). >> >> RAID 10 with 6 drives would stripe across 3 mirrored pairs. RAID 0+1 >> with 6 drives is a mirror of two striped arrays (3 disks each). RAID >> 0+1 (with concatenation) using 6 drives is a mirror of two volumes >> (kind of like JBOD) each consisting of 3 drives concatenated together >> (it's a cheap implementation, and it gives about the same performance >> as RAID 1 but with increased storage capacity and less fault >> tolerance). RAID 10 is better than RAID 5 (especially with 6 or less >> disks) because you don't have the performance hit for parity (which >> dramatically affects rebuild performance and write performance) and >> you get better fault tolerance (up to 3 disks can fail in a 6 disk >> RAID 10 and you can still be online, with RAID 5 you can only lose 1 >> drive). All of this comes with a higher cost (more drives and higher >> end cards). >> >> -- Will Reese http://blog.rezra.com >> >> >> On May 2, 2006, at 1:49 PM, Mark Lewis wrote: >> >>> They are not equivalent. As I understand it, RAID 0+1 performs >>> about >>> the same as RAID 10 when everything is working, but degrades much >>> less >>> nicely in the presence of a single failed drive, and is more >>> likely to >>> suffer catastrophic data loss if multiple drives fail. >>> >>> -- Mark >>> >>> On Tue, 2006-05-02 at 12:40 -0600, Brendan Duddridge wrote: >>>> Everyone here always says that RAID 5 isn't good for Postgres. We >>>> have an Apple Xserve RAID configured with RAID 5. We chose RAID 5 >>>> because Apple said their Xserve RAID was "optimized" for RAID 5. >>>> Not >>>> sure if we made the right decision though. They give an option for >>>> formatting as RAID 0+1. Is that the same as RAID 10 that everyone >>>> talks about? Or is it the reverse? >>>> >>>> Thanks, >>>> >>>> ___________________________________________________________________ >>>> _ >>>> Brendan Duddridge | CTO | 403-277-5591 x24 | >>>> brendan@clickspace.com >>>> >>>> ClickSpace Interactive Inc. >>>> Suite L100, 239 - 10th Ave. SE >>>> Calgary, AB T2G 0V9 >>>> >>>> http://www.clickspace.com >>>> >>>> On May 2, 2006, at 11:16 AM, Jim C. Nasby wrote: >>>> >>>>> On Wed, Apr 26, 2006 at 05:14:41PM +0930, Eric Lam wrote: >>>>>> all dumpfiles total about 17Gb. It has been running for 50ish hrs >>>>>> and up >>>>>> to about the fourth file (5-6 ish Gb) and this is on a raid 5 >>>>>> server. >>>>> >>>>> RAID5 generally doesn't bode too well for performance; that >>>>> could be >>>>> part of the issue. >>>>> -- >>>>> Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com >>>>> Pervasive Software http://pervasive.com work: 512-231-6117 >>>>> vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 >>>>> >>>>> ---------------------------(end of >>>>> broadcast)--------------------------- >>>>> TIP 4: Have you searched our list archives? >>>>> >>>>> http://archives.postgresql.org >>>>> >>>> >>>> >>>> >>>> ---------------------------(end of >>>> broadcast)--------------------------- >>>> TIP 9: In versions below 8.0, the planner will ignore your >>>> desire to >>>> choose an index scan if your joining column's datatypes do >>>> not >>>> match >>> >>> ---------------------------(end of >>> broadcast)--------------------------- >>> TIP 6: explain analyze is your friend >> >> >> ---------------------------(end of >> broadcast)--------------------------- >> TIP 5: don't forget to increase your free space map settings >> > > -- > Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com > Pervasive Software http://pervasive.com work: 512-231-6117 > vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 > > ---------------------------(end of > broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match >
pgsql-performance by date: