From: | Mischa Sandberg <ischamay(dot)andbergsay(at)activestateway(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Tryint to match Solaris-Oracle performance with directio? |
Date: | 2004-09-17 19:23:08 |
Message-ID: | wQG2d.66386$XP3.65429@edtnps84 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Our product (Sophos PureMessage) runs on a Postgres database.
Some of our Solaris customers have Oracle licenses, and they've
commented on the performance difference between Oracle and Postgresql
on such boxes. In-house, we've noticed the 2:1 (sometimes 5:1)
performance difference in inserting rows (mostly 2-4K), between
Postgresql on Solaris 8 and on Linux, for machines with comparable
CPU's and RAM.
These (big) customers are starting to ask, why don't we just port our
dataserver to Oracle for them? I'd like to avoid that, if possible :-)
What we can test on, in-house are leetle Sun workstations, while some of
our customers have BIG Sun iron --- so I have no means to-date to
reproduce what their bottleneck is :-( Yes, it has been recommended that
we talk to Sun about their iForce test lab ... that's in the pipe.
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Manfred Koizar | 2004-09-17 20:44:05 | Re: Large # of rows in query extremely slow, not using |
Previous Message | Josh Berkus | 2004-09-17 17:40:18 | Re: Large # of rows in query extremely slow, not using |