Re: Spread checkpoint sync
От | Heikki Linnakangas |
---|---|
Тема | Re: Spread checkpoint sync |
Дата | |
Msg-id | 4CF60C46.4050601@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Spread checkpoint sync (Greg Smith <greg@2ndquadrant.com>) |
Ответы |
Re: Spread checkpoint sync
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: