Re: fsync vs open_sync

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Josh Berkus" <josh(at)agliodbs(dot)com>
Cc: <pgsql(at)mohawksoft(dot)com>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: fsync vs open_sync
Date: 2004-08-11 16:37:10
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB3412A744B@Herge.rcsinc.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

> OSDL did some testing and found Ext3 to be perhaps the worst FS for
> PostgreSQL
> -- although this testing was with the default options. Ext3 involved
an
> almost 40% write performance penalty compared with Ext2, whereas the
> penalty
> for ReiserFS and JFS was less than 10%.
>
> This concurs with my personal experience.

I'm really curious to see if you guys have compared insert performance
results between 7.4 and 8.0. As you probably know the system sync()
call was replaced with a looping fsync on open file handles. This may
have some interesting interactions with the WAL sync method.

What caught my attention initially was the 300+/sec insert performance.
On 8.0/NTFS/fsync=on, I can't break 100/sec on a 10k rpm ATA disk. My
hardware seems to be more or less in the same league as psql's, so I was
naturally curious if this was a NT/Unix issue, a 7.4/8.0 issue, or a
combination of both.

A 5ms seek time disk would be limited to 200 transaction commits/sec if
each transaction commit has at least 1 seek. Are there some
circumstances where a transaction commit does not generate a physical
seek?

Maybe ext3 is not the worst filesystem after all!

Merlin

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Merlin Moncure 2004-08-11 17:04:00 Re: Hardware upgrade for a high-traffic database
Previous Message Jesper Krogh 2004-08-11 16:29:33 Re: Storing binary data.