Re: performance on new linux box

Поиск
Список
Период
Сортировка
От Ben Chobot
Тема Re: performance on new linux box
Дата
Msg-id 5DCE60F5-F741-4B42-8C39-768E23E3025E@silentmedia.com
обсуждение исходный текст
Ответ на Re: performance on new linux box  (Scott Carey <scott@richrelevance.com>)
Список pgsql-performance
On Jul 15, 2010, at 8:16 PM, Scott Carey wrote:

> On Jul 15, 2010, at 12:35 PM, Ben Chobot wrote:
>
>> On Jul 15, 2010, at 9:30 AM, Scott Carey wrote:
>>
>>>> Many raid controllers are smart enough to always turn off write caching on the drives, and also disable the
featureon their own buffer without a BBU. Add a BBU, and the cache on the controller starts getting used, but *not* the
cacheon the drives. 
>>>
>>> This does not make sense.
>>> Write caching on all hard drives in the last decade are safe because they support a write cache flush command
properly. If the card is "smart" it would issue the drive's write cache flush command to fulfill an fsync() or barrier
requestwith no BBU. 
>>
>> You're missing the point. If the power dies suddenly, there's no time to flush any cache anywhere. That's the entire
pointof the BBU - it keeps the RAM powered up on the raid card. It doesn't keep the disks spinning long enough to flush
caches.
>
> If the power dies suddenly, then the data that is in the OS RAM will also be lost.  What about that?
>
> Well it doesn't matter because the DB is only relying on data being persisted to disk that it thinks has been
persistedto disk via fsync(). 

Right, we agree that only what has been fsync()'d has a chance to be safe....

> The data in the disk cache is the same thing as RAM.  As long as fsync() works _properly_ which is true for any file
system+ disk combination with a damn (not HFS+ on OSX, not FAT, not a few other things), then it will tell the drive to
flushits cache _before_ fsync() returns.  There is NO REASON for a raid card to turn off a drive cache unless it does
nottrust the drive cache.  In write-through mode, it should not return to the OS with a fsync, direct write, or other
"theOS thinks this data is persisted now" call until it has flushed the disk cache.  That does not mean it has to turn
offthe disk cache. 

...and here you are also right in that a write-through write cache is safe, with or without a battery. A write-through
cacheis a win for things that don't often fsync, but my understanding is that with a database, you end up fsyncing all
thetime, which makes a write-through cache not worth very much. The only good way to get good *database* performance
outof spinning media is with a write-back cache, and the only way to make that safe is to hook up a BBU. 


В списке pgsql-performance по дате отправления:

Предыдущее
От: Scott Carey
Дата:
Сообщение: Re: performance on new linux box
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: performance on new linux box