Jeff Janes wrote:
> Have you tested out this "absorb during syncing phase" code without
> the sleep between the syncs?
> I.e. so that it still a tight loop, but the loop alternates between
> sync and absorb, with no intentional pause?
>
Yes; that's how it was developed. It helped to have just the extra
absorb work without the pauses, but that alone wasn't enough to really
improve things on the server we ran into this problem badly on.
> I ask because I don't have a mental model of how the pause can help.
> Given that this dirty data has been hanging around for many minutes
> already, what is a 3 second pause going to heal?
>
The difference is that once an fsync call is made, dirty data is much
more likely to be forced out. It's the one thing that bypasses all
other ways the kernel might try to avoid writing the data--both the
dirty ratio guidelines and the congestion control logic--and forces
those writes to happen as soon as they can be scheduled. If you graph
the amount of data shown "Dirty:" by /proc/meminfo over time, once the
sync calls start happening it's like a descending staircase pattern,
dropping a little bit as each sync fires.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books