Skip site navigation (1) Skip section navigation (2)

Re: O_DIRECT setting

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Guy Thornley <guy(at)esphion(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: O_DIRECT setting
Date: 2004-09-23 13:35:45
Message-ID: 200409231335.i8NDZjR21993@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
TODO has:

	* Consider use of open/fcntl(O_DIRECT) to minimize OS caching

Should the item be removed?

---------------------------------------------------------------------------

Neil Conway wrote:
> On Mon, 2004-09-20 at 17:57, Guy Thornley wrote:
> > According to the manpage, O_DIRECT implies O_SYNC:
> > 
> >         File I/O is done directly to/from user space buffers.  The I/O is
> >         synchronous, i.e., at the completion of the read(2) or write(2)
> >         system call, data is guaranteed to have been transferred.
> 
> This seems like it would be a rather large net loss. PostgreSQL already
> structures writes so that the writes we need to hit disk immediately
> (WAL records) are fsync()'ed -- the kernel is given more freedom to
> schedule how other writes are flushed from the cache. Also, my
> recollection is that O_DIRECT also disables readahead -- if that's
> correct, that's not what we want either.
> 
> BTW, using O_DIRECT has been discussed a few times in the past. Have you
> checked the list archives? (for both -performance and -hackers)
> 
> > Would people be interested in a performance benchmark?
> 
> Sure -- I'd definitely be curious, although as I said I'm skeptical it's
> a win.
> 
> > I need some benchmark tips :)
> 
> Some people have noted that it can be difficult to use contrib/pgbench
> to get reproducible results -- you might want to look at Jan's TPC-W
> implementation or the OSDL database benchmarks:
> 
> http://pgfoundry.org/projects/tpc-w-php/
> http://www.osdl.org/lab_activities/kernel_testing/osdl_database_test_suite/
> 
> > Incidentally, postgres heap files suffer really, really bad fragmentation,
> > which affects sequential scan operations (VACUUM, ANALYZE, REINDEX ...)
> > quite drastically. We have in-house patches that somewhat alleiviate this,
> > but they are not release quality.
> 
> Can you elaborate on these "in-house patches"?
> 
> -Neil
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

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

In response to

Responses

pgsql-performance by date

Next:From: Gaetano MendolaDate: 2004-09-23 14:04:20
Subject: Re: 7.4 vs 7.3 ( hash join issue )
Previous:From: Gaetano MendolaDate: 2004-09-23 08:52:21
Subject: Re: Caching of Queries

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group