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