Postgres Pro
Downloads
Home   >   mailing lists

Thread: Re :Solaris Performance

Re :Solaris Performance

From
Mark kirkwood
Date:
In my experience (on Solaris 8 anyway) whether you use gcc or the
SUNWspro cc seems to make little difference...

The problem area I have experienced is that queries that require a
reasonable sort at some point of the plan (e.g have a GROUP BY) will
consume all one 1 cpu (box had 2 of them) for a _very_ long time (e.g.
30 minutes - using either compiler) whereas the same query on a (single
cpu) Intel/Linux takes about 1 minute.

An example is:

SELECT
       d0.f3,
       count(f.val)
FROM dim0 d0,
     fact0 f
WHERE d0.d0key = f.d0key
AND   d0.f1 between '2000-01-01' AND '2000-06-29'
GROUP BY d0.f3

This groups 200000 rows into about 6 buckets.
The "Solaris killer" configuration is where fact0 has 10000000 rows and
dim0 10000.

In general the Solaris box (a 2x450Mhz E220R) is _much_ faster than any
Intels I have access to....

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

Mark

Re: Re :Solaris Performance

From
Tom Lane
Date:
Mark kirkwood <markir@slingshot.co.nz> writes:
> The problem area I have experienced is that queries that require a
> reasonable sort at some point of the plan (e.g have a GROUP BY) will
> consume all one 1 cpu (box had 2 of them) for a _very_ long time (e.g.
> 30 minutes - using either compiler) whereas the same query on a (single
> cpu) Intel/Linux takes about 1 minute.

[ scratches head ... ]  I didn't think there was anything particularly
system-dependent about the sorting code.  Have you tried profiling, or
anything to determine where the Solaris version is spending its time?

            regards, tom lane

Re: Re :Solaris Performance

From
Bruce Momjian
Date:
Tom Lane wrote:
> Mark kirkwood <markir@slingshot.co.nz> writes:
> > The problem area I have experienced is that queries that require a
> > reasonable sort at some point of the plan (e.g have a GROUP BY) will
> > consume all one 1 cpu (box had 2 of them) for a _very_ long time (e.g.
> > 30 minutes - using either compiler) whereas the same query on a (single
> > cpu) Intel/Linux takes about 1 minute.
>
> [ scratches head ... ]  I didn't think there was anything particularly
> system-dependent about the sorting code.  Have you tried profiling, or
> anything to determine where the Solaris version is spending its time?

The only thing I can think of that would affect the sorting code is
paging to swap during the sort.  But the default sort batch size is
512k, so it is hard to imagine it is paging out at that size.  You would
think it would affect normal backend operation, but maybe not.  Does
Solaris have a working-set concept where it will force to swap even if
no one else is using memory?  When I used VMS, we had that problem where
a process would only use a small amount of memory and force to swap even
though no one else was using the machine.  I just looked through my
Mauro Solaris internals book and I don't see any mention of working set
memory usage.

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