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

O_DIRECT setting

From: Guy Thornley <guy(at)esphion(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: O_DIRECT setting
Date: 2004-09-20 07:57:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
A recent comment on this (or perhaps another?) mailing list about Sun boxen
and the directio mount option has prompted me to read about O_DIRECT on the
open() manpage.

Has anybody tried this option? Ever taken any performance measurements?
I assume the way postgres manages its buffer memory (dealing with 8kB pages)
would be compatible with the restrictions:

        Under  Linux  2.4 transfer  sizes,  and the alignment of user buffer
        and file offset must all be multiples of the logical block size of
        the file system.

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.

At the moment I am fairly interested in trying this, and I would spend some
time with it, but I have my hands full with other projects. I'd imagine this
is more use with the revamped buffer manager in PG8.0 than the 7.x line, but
we are not using PG8.0 here yet.

Would people be interested in a performance benchmark? I need some benchmark
tips :)

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. Has anybody else suffered this?

Guy Thornley


pgsql-performance by date

Next:From: Patrick HatcherDate: 2004-09-21 04:01:26
Subject: vacuum full & max_fsm_pages question
Previous:From: Manfred KoizarDate: 2004-09-20 07:31:11
Subject: Re: Large # of rows in query extremely slow, not using

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