Re: Dirty Buffer Writing [was Proposed LogWriter Scheme] - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Dirty Buffer Writing [was Proposed LogWriter Scheme]
Date
Msg-id 200210080308.g9838aG12742@candle.pha.pa.us
Whole thread Raw
In response to Re: Dirty Buffer Writing [was Proposed LogWriter Scheme]  ("Curtis Faith" <curtis@galtair.com>)
Responses Re: Dirty Buffer Writing [was Proposed LogWriter Scheme]  ("Curtis Faith" <curtis@galtair.com>)
List pgsql-hackers
Curtis Faith wrote:
> > This is the trickle syncer.  It prevents bursts of disk activity every
> > 30 seconds.  It is for non-fsync writes, of course, and I assume if the
> > kernel buffers get low, it starts to flush faster.
> 
> AFAICT, the syncer only speeds up when virtual memory paging fills the
> buffers past
> a threshold and even in that event it only speeds it up by a factor of two.
> 
> I can't find any provision for speeding up flushing of the dirty buffers
> when they fill for normal file system writes, so I don't think that
> happens.

So you think if I try to write a 1 gig file, it will write enough to
fill up the buffers, then wait while the sync'er writes out a few blocks
every second, free up some buffers, then write some more?

Take a look at vfs_bio::getnewbuf() on *BSD and you will see that when
it can't get a buffer, it will async write a dirty buffer to disk.

As far as this AIO conversation is concerned, I want to see someone come
up with some performance improvement that we can only do with AIO. 
Unless I see it, I am not interested in pursuing this thread.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: "Curtis Faith"
Date:
Subject: Re: Dirty Buffer Writing [was Proposed LogWriter Scheme]
Next
From: "Shridhar Daithankar"
Date:
Subject: Re: [pgsql-performance] [GENERAL] Large databases, performance