Re: Slow restoration question

From: Brendan Duddridge <brendan(at)clickspace(dot)com>
To: Jim C(dot) Nasby <jnasby(at)pervasive(dot)com>
Cc: Will Reese <wreese(at)rackspace(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Slow restoration question
Date: 2006-05-03 02:09:52
Message-ID: 4A7F9950-65E0-4FA5-9FEC-BA1A93E615E5@clickspace.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)clickspace(dot)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(at)clickspace(dot)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(at)pervasive(dot)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(at)pervasive(dot)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
>

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2006-05-03 03:03:57 Re: Nested loop join and date range query
Previous Message Will Reese 2006-05-03 02:09:14 Re: Killing long-running queries