Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 0F4AD9FB63A for ; Thu, 5 Apr 2007 16:56:18 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 86097-05 for ; Thu, 5 Apr 2007 16:56:12 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from mir3-fs.mir3.com (mail.mir3.com [65.208.188.100]) by postgresql.org (Postfix) with ESMTP id DE8869FB636 for ; Thu, 5 Apr 2007 16:56:14 -0300 (ADT) Received: MIR3-FS.mir3.com 172.16.1.11 from 172.16.2.68 172.16.2.68 via HTTP with MS-WebStorage 6.0.6249 Received: from archimedes by MIR3-FS.mir3.com; 05 Apr 2007 12:56:13 -0700 Subject: Re: a question about Direct I/O and double buffering From: Mark Lewis To: Erik Jones Cc: Xiaoning Ding , pgsql-performance@postgresql.org In-Reply-To: <7B476592-606F-46F0-A643-9C4E5D85CE6E@myemma.com> References: <46152D5D.5030602@cse.ohio-state.edu> <4C4C834E-9304-4E23-AD15-1756921500B5@myemma.com> <1175797629.5581.39.camel@archimedes> <7B476592-606F-46F0-A643-9C4E5D85CE6E@myemma.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: MIR3, Inc. Date: Thu, 05 Apr 2007 12:56:12 -0700 Message-Id: <1175802972.5581.56.camel@archimedes> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200704/127 X-Sequence-Number: 24004 ... [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