On Fri, 2005-06-24 at 10:19 -0500, Jim C. Nasby wrote:
> On Fri, Jun 24, 2005 at 09:37:23AM -0400, Tom Lane wrote:
> > ITAGAKI Takahiro <itagaki.takahiro@lab.ntt.co.jp> writes:
> > > ... So I'll post the new results:
> >
> > > checkpoint_ | writeback |
> > > segments | cache | open_sync | fsync=false | O_DIRECT only | fsync_direct | open_direct
> > > ------------+-----------+-----------+---------------+---------------+---------------+--------------
> > > [3] 3 | off | 38.2 tps | 138.8(+263.5%)| 38.6(+ 1.2%) | 38.5(+ 0.9%) | 38.5(+ 0.9%)
> >
> > Yeah, this is about what I was afraid of: if you're actually fsyncing
> > then you get at best one commit per disk revolution, and the negotiation
> > with the OS is down in the noise.
> >
> > At this point I'm inclined to reject the patch on the grounds that it
> > adds complexity and portability issues, without actually buying any
> > useful performance improvement. The write-cache-on numbers are not
> > going to be interesting to any serious user :-(
>
> Is there anyone with a battery-backed RAID controller that could run
> these tests? I suspect that in that case the differences might be closer
> to 1 or 2 rather than 3, which would make the patch much more valuable.
I applied the O_DIRECT patch to 8.0.3 and I tested this on a
battery-backed RAID controller with 128MB of cache and 5 7200RPM SATA
disks. All caches are write-back. The xlog and data are on the same
JFS volume. pgbench was run with a scale factor of 1000 and 100000
total transactions. Clients varied from 10 to 100.
Clients | fsync | open_direct
------------------------------------ 10 | 81 | 98 (+21%) 100 | 100 | 105 ( +5%)
------------------------------------
No problems were experienced. The patch seems to give a useful boost!
-jwb
