Re: O_DIRECT for WAL writes

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Neil Conway <neilc(at)samurai(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: O_DIRECT for WAL writes
Date: 2005-06-04 16:52:55
Message-ID: 200506041652.j54Gqtq04034@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


I think the conclusion from the discussion is that O_DIRECT is in
addition to the sync method, rather than in place of it, because
O_DIRECT doesn't have the same media write guarantees as fsync(). Would
you update the patch to do O_DIRECT in addition to O_SYNC or fsync() and
see if there is a performance win?

Thanks.

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

ITAGAKI Takahiro wrote:
> Neil Conway <neilc(at)samurai(dot)com> wrote:
>
> > > The patch adds a new choice "open_direct" to wal_sync_method.
> > Have you looked at what the performance difference of this option is?
>
> Yes, I've tested pgbench and dbt2 and their performances have improved.
> The two results are as follows:
>
> 1. pgbench -s 100 on one Pentium4, 1GB mem, 2 ATA disks, Linux 2.6.8
> (attached image)
> tps | wal_sync_method
> -------+-------------------------------------------------------
> 147.0 | open_direct + write multipage (previous patch)
> 147.2 | open_direct (this patch)
> 109.9 | open_sync
>
> 2. dbt2 100WH on two opterons, 8GB mem, 12 SATA-RAID disks, Linux 2.4.20
> tpm | wal_sync_method
> --------+------------------------------------------------------
> 1183.9 | open_direct (this patch)
> 911.3 | fsync
>
>
>
> > http://www.mail-archive.com/pgsql-patches(at)postgresql(dot)org/msg07186.html
> > Is this data still applicable to the revised patch?
>
> Direct-IO might be good on some machines, and bad on others.
> This data is another reason that I revised the patch;
> If you don't use open_direct, WAL writer behaves quite similarly to former.
>
> However, the performances did not go down at least on my benchmarks.
> I have no idea why the above data was bad...
>
> ---
> ITAGAKI Takahiro
> NTT Cyber Space Laboratories
>

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org

--
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

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2005-06-04 17:52:16 Re: ARRAY() returning NULL instead of ARRAY[] resp. {}
Previous Message Tom Lane 2005-06-04 16:23:27 Re: Precedence of %

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2005-06-04 17:52:16 Re: ARRAY() returning NULL instead of ARRAY[] resp. {}
Previous Message Magnus Hagander 2005-06-04 16:29:05 Re: Simplify Win32 Signaling code