Re: sync rep & fsync=off

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: sync rep & fsync=off
Дата
Msg-id AANLkTik55aujGMeujWew2D_3sa+qQxR=h30_iS_5Bw=j@mail.gmail.com
обсуждение исходный текст
Ответ на Re: sync rep & fsync=off  (Grzegorz Jaskiewicz <gj@pointblue.com.pl>)
Ответы Re: sync rep & fsync=off
Список pgsql-hackers
On Sat, Mar 19, 2011 at 11:34 AM, Grzegorz Jaskiewicz
<gj@pointblue.com.pl> wrote:
>
> On 18 Mar 2011, at 21:12, Robert Haas wrote:
>
>> While investigating Simon's complaint about my patch of a few days
>> ago, I discovered that synchronous replication appears to slow to a
>> crawl if fsync is turned off on the standby.
>>
>> I'm not sure why this is happening or what the right behavior is in
>> this case, but I think some kind of adjustment is needed because the
>> current behavior is quite surprising.
> We have few servers here running 8.3. And few weeks ago I had to populate one database with quite a number of
entries.
> I have script that does that, but it takes a while. I decided to turn fsck to off. Oddly enough, the server started
tocrawl quite badly, load was very high.
 
> That was 8.3 on rhel 5.4.
>
> My point is, it is sometimes bad combination of disks and controllers that does that. Not necessarily software. fsync
offdoesn't always mean that things are going to fly, it can cause it to expose hardware bottlenecks much quicker.
 

Well, it's possible.  But I think it'd be worth a look at the code to
see if there's some bad interaction there between the no-fsync code
and the sync-rep code - like, if we don't actually fsync, does the
flush pointer ever get updated?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Markus Wanner
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Следующее
От: Tom Lane
Дата:
Сообщение: WIP patch: collation assignment algorithm rewrite