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

From Curtis Faith
Subject Re: Dirty Buffer Writing [was Proposed LogWriter Scheme]
Date
Msg-id DMEEJMCDOJAKPPFACMPMEEGBCEAA.curtis@galtair.com
Whole thread Raw
In response to Re: Dirty Buffer Writing [was Proposed LogWriter Scheme]  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Dirty Buffer Writing [was Proposed LogWriter Scheme]  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> 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.

We've addressed this scenario before, if I recall, the point Greg made
earlier is that buffers getting full means writes become synchronous.

I was trying to point out was that it was very likely that the buffers will
fill even for large buffers and that the writes are going to be driven out
not by efficient ganging but by something approaching LRU flushing, with an
occasional once a second slightly more efficient write of 1/32nd of the
buffers.

Once the buffers get full, all subsequent writes turn into synchronous
writes, since even if the kernel writes asynchronously (meaning it can do
other work), the writing process can't complete, it has to wait until the
buffer has been flushed and is free for the copy. So the relatively poor
implementation (for database inserts at least) of the syncer mechanism will
cost a lot of performance if we get to this synchronous write mode due to a
full buffer. It appears this scenario is much more likely than I had
thought.

Do you not think this is a potential performance problem to be explored?

I'm only pursuing this as hard as I am because I feel like it's deja vu all
over again. I've done this before and found a huge improvement (12X to 20X
for bulk inserts). I'm not necessarily expecting that level of improvement
here but my gut tells me there is more here than seems obvious on the
surface.

> 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.

If I come up with something via aio that helps I'd be more than happy if
someone else points out a non-aio way to accomplish the same thing. I'm by
no means married to any particular solutions, I care about getting problems
solved. And I'll stop trying to sell anyone on aio.

- Curtis



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Analysis of ganged WAL writes
Next
From: "Curtis Faith"
Date:
Subject: Re: Analysis of ganged WAL writes