On 01.12.2010 06:25, Greg Smith wrote:
Jeff Janes wrote:
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.
Do you have any idea how to autotune the delay between fsyncs?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
