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.

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

Search Discussions

  • Grzegorz Jaskiewicz at Mar 19, 2011 at 3:34 pm

    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 to crawl 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 off doesn't always mean that things are going to fly, it can cause it to expose hardware bottlenecks much quicker.
  • Robert Haas at Mar 19, 2011 at 8:31 pm

    On Sat, Mar 19, 2011 at 11:34 AM, Grzegorz Jaskiewicz 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 to crawl 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 off doesn'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
  • Fujii Masao at Mar 24, 2011 at 1:45 pm

    On Sun, Mar 20, 2011 at 5:31 AM, Robert Haas wrote:
    On Sat, Mar 19, 2011 at 11:34 AM, Grzegorz Jaskiewicz
    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 to crawl 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 off doesn'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?
    No, as far as I read the code. Disabling fsync increases the time taken
    to close the WAL file?

    Regards,

    --
    Fujii Masao
    NIPPON TELEGRAPH AND TELEPHONE CORPORATION
    NTT Open Source Software Center

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMar 18, '11 at 9:12p
activeMar 24, '11 at 1:45p
posts4
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase