Solaris Performance

P.J. "Josh" Rovero wrote:

We've been running equivalent configurations and schema on
HP-UX, Solaris, and x86 Linux, and benchmarking with
pgbench and some application-specific data. All testing
was with 7.2rc2, and all were built natively on each platform.

Performance on Solaris (2.6 and 2.7) seems lackluster, even when
postgres processes are not CPU, memory, or IO bound, and whether
over local Unix or tcpip sockets.

Are there any other Solaris-specific optimizations or configuration
items that we should consider?

Yes, we have heard this report several times. We know process startup
is slower on Solaris that other operating systems. How much of your
testing is related to starting a new process? Other than that, we think
perhaps the sheer weight of Solaris is slowing us down, though we don't
have any hard answers to give you.

Sorry. I would rather have given a better answer. We are willing to
work with you to idenfity the parts that are slowest and see if we can
somehow work around them.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

"P.J. \"Josh\" Rovero" <rovero@sonalysts.com> writes:

We've been running equivalent configurations and schema on
HP-UX, Solaris, and x86 Linux, and benchmarking with
pgbench and some application-specific data. All testing
was with 7.2rc2, and all were built natively on each platform.

Performance on Solaris (2.6 and 2.7) seems lackluster,

Seeing as how those are three different hardware platforms, one must
wonder how sure you are that you are comparing apples to apples.
A difference in CPU speed or disk speed could explain everything.

regards, tom lane

Tom Lane wrote:

"P.J. \"Josh\" Rovero" <rovero@sonalysts.com> writes:

We've been running equivalent configurations and schema on
HP-UX, Solaris, and x86 Linux, and benchmarking with
pgbench and some application-specific data. All testing
was with 7.2rc2, and all were built natively on each platform.

Performance on Solaris (2.6 and 2.7) seems lackluster,

Seeing as how those are three different hardware platforms, one must
wonder how sure you are that you are comparing apples to apples.
A difference in CPU speed or disk speed could explain everything.

Agreed, but if I had to take a guess, my bet is he is going to say the
Solaris box is faster in all ways. We have heard such reports before.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

For non-postgresql applications, the Suns are
typically faster than the HPs. While direct
comparisons are always dangerous, the SPARC
chips are clocked at about 2-3 times what
the PA-RISC chips are.

The postgresql performance on Solaris is
an order of magnitude (10x) slower than
Linux x86 at same CPU clock speed.

Tom Lane wrote:

"P.J. \"Josh\" Rovero" <rovero@sonalysts.com> writes:

We've been running equivalent configurations and schema on
HP-UX, Solaris, and x86 Linux, and benchmarking with
pgbench and some application-specific data. All testing
was with 7.2rc2, and all were built natively on each platform.

Performance on Solaris (2.6 and 2.7) seems lackluster,

Seeing as how those are three different hardware platforms, one must
wonder how sure you are that you are comparing apples to apples.
A difference in CPU speed or disk speed could explain everything.

regards, tom lane

--
P. J. "Josh" Rovero Sonalysts, Inc.
Email: rovero@sonalysts.com www.sonalysts.com 215 Parkway North
Work: (860)326-3671 or 442-4355 Waterford CT 06385
***********************************************************************

"P.J. \"Josh\" Rovero" <rovero@sonalysts.com> writes:

For non-postgresql applications, the Suns are
typically faster than the HPs. While direct
comparisons are always dangerous, the SPARC
chips are clocked at about 2-3 times what
the PA-RISC chips are.

The postgresql performance on Solaris is
an order of magnitude (10x) slower than
Linux x86 at same CPU clock speed.

Hmm. So can you figure out where the time is going? What do you see
with top, iostat, vmstat, ...? Can you recompile with profiling (gmake
clean, gmake PROFILE=-pg all typically works on gcc platforms) and learn
something about where the backend is spending its time?

regards, tom lane

Actually, the first question to ask might be "are you using gcc"?

It looks to me like s_lock.h/s_lock.c don't have a non-gcc
implementation of tas() unless you define NEED_SPARC_TAS_ASM
... which src/include/port/solaris.h doesn't. Ugh.

regards, tom lane

P.J. "Josh" Rovero wrote:

For non-postgresql applications, the Suns are
typically faster than the HPs. While direct
comparisons are always dangerous, the SPARC
chips are clocked at about 2-3 times what
the PA-RISC chips are.

The postgresql performance on Solaris is
an order of magnitude (10x) slower than
Linux x86 at same CPU clock speed.

Wow, that is dramatic.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tom Lane wrote:

Actually, the first question to ask might be "are you using gcc"?

It looks to me like s_lock.h/s_lock.c don't have a non-gcc
implementation of tas() unless you define NEED_SPARC_TAS_ASM
... which src/include/port/solaris.h doesn't. Ugh.

Ouch. Can we throw a message in the server logs when we are using the
non-asm locking code?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Awhile back I said:

Actually, the first question to ask might be "are you using gcc"?
It looks to me like s_lock.h/s_lock.c don't have a non-gcc
implementation of tas() unless you define NEED_SPARC_TAS_ASM
... which src/include/port/solaris.h doesn't. Ugh.

I have to take this back: for non-gcc on Sparc, we use out-of-line
TAS subroutines, see src/backend/port/tas/. So that's not the problem.

regards, tom lane