Re: understanding postgres issues/bottlenecks

Поиск
Список
Период
Сортировка
От david@lang.hm
Тема Re: understanding postgres issues/bottlenecks
Дата
Msg-id alpine.DEB.1.10.0901101140370.31038@asgard.lang.hm
обсуждение исходный текст
Ответ на Re: understanding postgres issues/bottlenecks  (Gregory Stark <stark@enterprisedb.com>)
Ответы Re: understanding postgres issues/bottlenecks  (Markus Wanner <markus@bluegap.ch>)
Список pgsql-performance
On Sat, 10 Jan 2009, Gregory Stark wrote:

>>> ...and of course, those lucky few with bigger budgets can use SSD's and not
>>> care what fsync is set to.
>>
>> Would that prevent any corruption if the writes got out of order
>> because of lack of fsync?  Or partial writes?  Or wouldn't fsync still
>> need to be turned on to keep the data safe.
>
> I think the idea is that with SSDs or a RAID with a battery backed cache you
> can leave fsync on and not have any significant performance hit since the seek
> times are very fast for SSD. They have limited bandwidth but bandwidth to the
> WAL is rarely an issue -- just latency.

I don't think that this is true, even if your SSD is battery backed RAM
(as opposed to the flash based devices that have slower writes than
high-end hard drives) you can complete 'writes' to the system RAM faster
than the OS can get the data to the drive, so if you don't do a fsync you
can still loose a lot in a power outage.

raid controllers with battery backed ram cache will make the fsyncs very
cheap (until the cache fills up anyway)

with SSDs having extremely good read speeds, but poor (at least by
comparison) write speeds I wonder if any of the RAID controllers are going
to get a mode where they cache writes, but don't cache reads, leaving all
ofyour cache to handle writes.

David Lang

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

Предыдущее
От: Markus Wanner
Дата:
Сообщение: block device benchmarking
Следующее
От: Markus Wanner
Дата:
Сообщение: Re: understanding postgres issues/bottlenecks