From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Ivan Voras <ivoras(at)freebsd(dot)org> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: raid10 write performance |
Date: | 2010-06-23 12:54:27 |
Message-ID: | AANLkTim6yLKRZQ_ursC671XCK0QZb7DX0cg0K76eYRIf@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Wed, Jun 23, 2010 at 8:25 AM, Ivan Voras <ivoras(at)freebsd(dot)org> wrote:
> On 06/23/10 14:00, Florian Weimer wrote:
>> * Ivan Voras:
>>
>>> On the other hand, RAID10 is simple enough that soft-RAID
>>> implementations should be more than adequate - any ideas why a dedicated
>>> card has it "slow"?
>>
>> Barrier support on RAID10 seems to require some smallish amount of
>> non-volatile storage which supports a high number of write operations
>> per second, so a software-only solution might not be available.
>
> If I understand you correctly, this can be said in general for all
> spinning-disk usage and is not specific to RAID10. (And in the case of
> high, constant TPS, no amount of NVRAM will help you).
Not entirely true. Let's say you have enough battery backed cache to
hold 10,000 transaction writes in memory at once. The RAID controller
can now re-order those writes so that they go from one side of the
disk to the other, instead of randomly all over the place. That will
most certainly help improve your throughput.
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2010-06-23 12:56:39 | Re: raid10 write performance |
Previous Message | Matthew Wakeling | 2010-06-23 12:46:13 | Re: raid10 write performance |