Re: a question about Direct I/O and double buffering - Mailing list pgsql-performance

From Erik Jones
Subject Re: a question about Direct I/O and double buffering
Date
Msg-id CE3B7895-88D9-4CEC-A9EC-506AD4533300@myemma.com
Whole thread Raw
In response to Re: a question about Direct I/O and double buffering  (Mark Lewis <mark.lewis@mir3.com>)
Responses Re: a question about Direct I/O and double buffering  ("Jim C. Nasby" <jim@nasby.net>)
List pgsql-performance
On Apr 5, 2007, at 2:56 PM, Mark Lewis wrote:

...
[snipped for brevity]
...

Not to hijack this thread, but has anybody here tested the behavior
of
PG on a file system with OS-level caching disabled via forcedirectio
or
by using an inherently non-caching file system such as ocfs2?


I've been thinking about trying this setup to avoid double-caching
now
that the 8.x series scales shared buffers better, but I figured I'd
ask
first if anybody here had experience with similar configurations.


-- Mark


Rather than repeat everything that was said just last week, I'll point
out that we just had a pretty decent discusson on this last week that
I started, so check the archives.  In summary though, if you have a
high io transaction load with a db where the average size of your
"working set" of data doesn't fit in memory with room to spare, then
direct io can be a huge plus, otherwise you probably won't see much of
a difference.  I have yet to hear of anybody actually seeing any
degradation in the db performance from it.  In addition, while it
doesn't bother me, I'd watch the top posting as some people get pretty
religious about (I moved your comments down).

I saw the thread, but my understanding from reading through it was that
you never fully tracked down the cause of the factor of 10 write volume
mismatch, so I pretty much wrote it off as a data point for
forcedirectio because of the unknowns.  Did you ever figure out the
cause of that?

-- Mark Lewis

Nope.  What we never tracked down was the factor of 10 drop in database transactions, not disk transactions.  The write volume was most definitely due to the direct io setting -- writes are now being done in terms of the system's block size where as before they were being done in terms of the the filesystem's cache page size (as it's in virtual memory).  Basically, we do so many write transactions that the fs cache was constantly paging.

erik jones <erik@myemma.com>
software developer
615-296-0838
emma(r)



pgsql-performance by date:

Previous
From: david@lang.hm
Date:
Subject: Re: SCSI vs SATA
Next
From: "John Allgood"
Date:
Subject: Re: High Load on Postgres 7.4.16 Server