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

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 (view raw or flat)
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

pgsql-performance by date

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

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