Re: Slow restoration question
От | Will Reese |
---|---|
Тема | Re: Slow restoration question |
Дата | |
Msg-id | 758B0591-3C9C-418B-9AF2-E962003C4904@rackspace.com обсуждение исходный текст |
Ответ на | Re: Slow restoration question (Mark Lewis <mark.lewis@mir3.com>) |
Ответы |
Re: Slow restoration question
("Jim C. Nasby" <jnasby@pervasive.com>)
|
Список | pgsql-performance |
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
В списке pgsql-performance по дате отправления:
Предыдущее
От: "Mark Liberman"Дата:
Сообщение: Re: Why is plan (and performance) different on partitioned table?