On 2015-09-09 10:46:47 -0400, Robert Haas wrote: > Well, if you're filling ~1 clog page per second, you're doing ~1 fsync > per second too. Or if you are not, then you are thrashing the > progressively smaller and smaller number of clean slots ever-harder > until no clean pages remain and you're forced to fsync something - > probably, a bunch of things all at once.
And you're also triggering a lot of other fsyncs. At the very least you're pretty constantly flushing the WAL, even with synchronous_commit = off. > > Like Andres, I'd want to see a more realistic problem case before > > expending a lot of work here. > > I think the question here isn't whether the problem case is realistic > - I am quite sure that a pgbench workload is - but rather how much of > a problem it actually causes. I'm very sure that individual pgbench > backends experience multi-second stallls as a result of this. The fsync causes that? That seems odd. I mean we release the slru control lock for writing out pages, don't we? To me it seems the fsyncs are a red herring here, and the problems are, uh, much bigger. ISTM that cache replacement locking granularity et al have a much bigger effect than a fsync every now and then. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers