Thread: Re: fsync vs open_sync

> 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

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

The system on which I can get 300 inserts per second is a battery backed
up XEON system with 512M RAM, a Promise PDC DMA ATA card, and some fast
disks with write caching enabled.

(We are not worried about write caching because we have a UPS. Since all
non-redundent systems are evaluated on probability of error, we decided
that the probability of power failure and UPS failure was sufficiently
more rare than system crash with file system corruption or hard disk
failure.)
>
> 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
>

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

    There is also the fact that NTFS is a very slow filesystem, and Linux is
a lot better than Windows for everything disk, caching and IO related. Try
to copy some files in NTFS and in ReiserFS...