Re: Vacuum, Freeze and Analyze: the big picture - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Vacuum, Freeze and Analyze: the big picture
Date
Msg-id 20130604000459.GB12323@alap2.anarazel.de
Whole thread Raw
In response to Re: Vacuum, Freeze and Analyze: the big picture  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
On 2013-06-03 16:41:32 -0700, Peter Geoghegan wrote:
> On Mon, Jun 3, 2013 at 3:16 PM, Kevin Grittner <kgrittn@ymail.com> wrote:
> >> But it seems like the kernel is disposed to cache large amounts
> >> of dirty data for an unbounded period of time even if the I/O
> >> system is completely idle,
> >
> > It's not unbounded time.  Last I heard, the default was 30 seconds.
> 
> I'm pretty sure it is unbounded. The VM documentation is a bit vague
> on what dirty_expire_centisecs actually means, which is I presume
> where this number comes from. It says:
> 
> "This tunable is used to define when dirty data is old enough to be eligible
> for writeout by the pdflush daemons.  It is expressed in 100'ths of a second.
> Data which has been dirty in-memory for longer than this interval will be
> written out next time a pdflush daemon wakes up."
> 
> So I think the a pdflush daemon won't necessarily wake up until
> dirty_background_bytes or dirty_background_ratio have been exceeded,
> regardless of this threshold. Am I mistaken?

Without having it checked again, afair it should wakeup every
dirty_writeback_centisecs which is something like 5seconds.

All that has pretty significantly changed - and imo improved! - in the
last year or so of kernel development. Unfortunately it will take a
while till we commonly see those kernels being used :(

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Vacuum, Freeze and Analyze: the big picture
Next
From: Josh Berkus
Date:
Subject: Re: Vacuum, Freeze and Analyze: the big picture