Thread: Re: Tryint to match Solaris-Oracle performance with directio?

Mischa Sandberg wrote:
> In the meantime, what I gather from browsing mail archives is that
> postgresql on Solaris seems to get hung up on IO rather than CPU.
> Furthermore, I notice that Oracle and now MySQL use directio to bypass
> the system cache, when doing heavy writes to the disk; and Postgresql
> does not.
>
> Not wishing to alter backend/store/file for this test, I figured I could
> get a customer to mount the UFS volume for pg_xlog  with the option
> "forcedirectio".
>
> Any comment on this? No consideration of what the wal_sync_method is at
> this point. Presumably it's defaulting to fdatasync on Solaris.
>
> BTW this is Postgres 7.4.1, and our customers are Solaris 8 and 9.

If you care your data upgrade to more recent 7.4.5

Test your better sync method using /src/tools/fsync  however do some
experiment changing the sync method, you can also avoid to update the
acces time for the inodes mounting the partition with noatime option
( this however have more impact on performance for read activities )


Regards
Gaetano Mendola

I fully agree with Gaetano about testing sync methods.  From testing I've done
on two different Solaris 8 boxes, the O_DSYNC option on Solaris 8 beats fsync
and fdatasync easily.  Test it yourself though.  There's probably some
opportuntiy there for better performance for you.

> > BTW this is Postgres 7.4.1, and our customers are Solaris 8 and 9.
>
> If you care your data upgrade to more recent 7.4.5
>
> Test your better sync method using /src/tools/fsync  however do some
> experiment changing the sync method, you can also avoid to update the
> acces time for the inodes mounting the partition with noatime option
> ( this however have more impact on performance for read activities )
>
>
> Regards
> Gaetano Mendola
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>