Re: [PERFORM] Advice configuring ServeRAID 8k for performance
On Thu, 5 Aug 2010, Scott Marlowe wrote: RAID6 is basically RAID5 with a hot spare already built into the array. On Fri, 6 Aug 2010, Pierre C wrote: As others said, RAID6 is RAID5 + a hot spare. No. RAID6 is NOT RAID5 plus a hot spare. RAID5 uses a single parity datum (XOR) to ensure protection against data loss if one drive fails. RAID6 uses two different sets of parity (Reed-Solomon) to ensure protection against data loss if two drives fail simultaneously. If you have a RAID5 set with a hot spare, and you lose two drives, then you have data loss. If the same happens to a RAID6 set, then there is no data loss. Matthew -- And the lexer will say "Oh look, there's a null string. Oooh, there's another. And another.", and will fall over spectacularly when it realises there are actually rather a lot. - Computer Science Lecturer (edited) -- 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 Fri, Aug 6, 2010 at 3:17 AM, Matthew Wakeling wrote: > On Thu, 5 Aug 2010, Scott Marlowe wrote: >> >> RAID6 is basically RAID5 with a hot spare already built into the >> array. > > On Fri, 6 Aug 2010, Pierre C wrote: >> >> As others said, RAID6 is RAID5 + a hot spare. > > No. RAID6 is NOT RAID5 plus a hot spare. The original phrase was that RAID 6 was like RAID 5 with a hot spare ALREADY BUILT IN. -- 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 Fri, Aug 6, 2010 at 11:32 AM, Justin Pitts wrote: As others said, RAID6 is RAID5 + a hot spare. >>> >>> No. RAID6 is NOT RAID5 plus a hot spare. >> >> The original phrase was that RAID 6 was like RAID 5 with a hot spare >> ALREADY BUILT IN. > > Built-in, or not - it is neither. It is more than that, actually. RAID > 6 is like RAID 5 in that it uses parity for redundancy and pays a > write cost for maintaining those parity blocks, but will maintain data > integrity in the face of 2 simultaneous drive failures. Yes, I know that. I am very familiar with how RAID6 works. RAID5 with the hot spare already rebuilt / built in is a good enough answer for management where big words like parity might scare some PHBs. > In terms of storage cost, it IS like paying for RAID5 + a hot spare, > but the protection is better. > > A RAID 5 with a hot spare built in could not survive 2 simultaneous > drive failures. Exactly. Which is why I had said with the hot spare already built in / rebuilt. Geeze, pedant much? -- 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] vacuum performance on insert
hi, thank you for the reply. I ran a number of tests to try to make sense of this. When I ran with or without vacuum, the number of disk io operations, cache operations etc. gathered from pg_stat table for the insertions are pretty much the same. So I don't see vacuum reduce disk io operations. Now from what you mentioned below, do you know what's the cost of postgres requesting new disk space from OS? I'm seeing a big performance difference with vacuum, but I need a proof to show it's the requesting new space operation that was the problem, not disk io, etc. since I would think disk could be expensive as well. Thanks, Sean On Thu, Aug 5, 2010 at 2:11 PM, Tom Lane wrote: > "Kevin Grittner" writes: >> Sean Chen wrote: >>> 1, delete records ... >>> 2, insert records ... >>> >>> if I add "vacuum analyze" in-between this two steps, will it help >>> on the performance on the insert? > >> Assuming there are no long-running transactions which would still be >> able to see the deleted rows, a VACUUM between those statements >> would allow the INSERT to re-use the space previously occupied by >> the deleted rows, rather than possibly needing to allocate new space >> from the OS. > > But on the other side of the coin, the ANALYZE step is probably not very > helpful there. Better to do that after you've loaded the new data. > > regards, tom lane > -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
