Skip site navigation (1) Skip section navigation (2)

Re: SSD + RAID

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Richard Neill <rn214(at)cam(dot)ac(dot)uk>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: SSD + RAID
Date: 2009-11-21 14:25:03
Message-ID: b42b73150911210625u293d9969gfb753d6d18815036@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Fri, Nov 20, 2009 at 7:27 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> Richard Neill wrote:
>>
>> The key issue for short,fast transactions seems to be
>> how fast an fdatasync() call can run, forcing the commit to disk, and
>> allowing the transaction to return to userspace.
>> Attached is a short C program which may be of use.
>
> Right.  I call this the "commit rate" of the storage, and on traditional
> spinning disks it's slightly below the rotation speed of the media (i.e.
> 7200RPM = 120 commits/second).    If you've got a battery-backed cache in
> front of standard disks, you can easily clear 10K commits/second.


...until you overflow the cache.  battery backed cache does not break
the laws of physics...it just provides a higher burst rate (plus what
ever advantages can be gained by peeking into the write queue and
re-arranging/grouping.  I learned the hard way that how your raid
controller behaves in overflow situations can cause catastrophic
performance degradations...

merlin

In response to

pgsql-performance by date

Next:From: afancyDate: 2009-11-21 22:56:51
Subject: Performance degrade running on multicore computer
Previous:From: Greg SmithDate: 2009-11-21 00:27:36
Subject: Re: SSD + RAID

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group