Re: a question about Direct I/O and double buffering

From: Erik Jones <erik(at)myemma(dot)com>
To: Mark Lewis <mark(dot)lewis(at)mir3(dot)com>
Cc: Xiaoning Ding <dingxn(at)cse(dot)ohio-state(dot)edu>, pgsql-performance(at)postgresql(dot)org
Subject: Re: a question about Direct I/O and double buffering
Date: 2007-04-05 20:10:43
Message-ID: CE3B7895-88D9-4CEC-A9EC-506AD4533300@myemma.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)myemma(dot)com>
software developer
615-296-0838
emma(r)

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message david 2007-04-05 20:11:56 Re: SCSI vs SATA
Previous Message Dave Cramer 2007-04-05 20:00:39 Re: High Load on Postgres 7.4.16 Server