Re: SSD + RAID

From: Laszlo Nagy <gandalf(at)shopzeus(dot)com>
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
Cc: Ivan Voras <ivoras(at)freebsd(dot)org>, pgsql-performance(at)postgresql(dot)org
Subject: Re: SSD + RAID
Date: 2009-11-15 08:15:43
Message-ID: 4AFFB8AF.5050004@shopzeus.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


> - Pg doesn't know the erase block sizes or positions. It can't group
> writes up by erase block except by hoping that, within a given file,
> writing in page order will get the blocks to the disk in roughly
> erase-block order. So your write caching isn't going to do anywhere near
> as good a job as the SSD's can.
>
Okay, I see. We cannot query erase block size from an SSD drive. :-(
>> I don't think that any SSD drive has more than some
>> megabytes of write cache.
>>
>
> The big, lots-of-$$ ones have HUGE battery backed caches for exactly
> this reason.
>
Heh, this is why they are so expensive. :-)
>> The same amount of write cache could easily be
>> implemented in OS memory, and then Pg would always know what hit the disk.
>>
>
> Really? How does Pg know what order the SSD writes things out from its
> cache?
>
I got the point. We cannot implement an efficient write cache without
much more knowledge about how that particular drive works.

So... the only solution that works well is to have much more RAM for
read cache, and much more RAM for write cache inside the RAID controller
(with BBU).

Thank you,

Laszlo

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Craig Ringer 2009-11-15 08:46:56 Re: SSD + RAID
Previous Message Pavel Stehule 2009-11-15 07:42:36 Re: FTS performance with the Polish config