Re: Proposal of tunable fix for scalability of 8.4

Scott Carey wrote:
> On 3/13/09 8:55 AM, "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>
> >>> "Jignesh K. Shah" <J(dot)K(dot)Shah(at)Sun(dot)COM> wrote:
> > usr sys wt idl sze
> > 38 11 0 50 64
>
> The fact that you're maxing out at 50% CPU utilization has me
> wondering -- are there really 64 CPUs here, or are there 32 CPUs with
> "hyperthreading" technology (or something conceptually similar)?
>
> -Kevin
>
> Its a sun T1000 or T2000 type box, which are 4 threads per processor
> core IIRC. Its in his first post:
>
> “
> UltraSPARC T2 based 1 socket (64 threads) and 2 socket (128 threads)
> servers that Sun sells.
> “
>
> These processors use an in-order execution engine and fill the bubbles
> in the pipelines with SMT (the non-marketing name for hyperthreading).
> They are rather efficient at it though, moreso than Intel’s first stab
> at it. And Intel’s next generation chips hitting the streets in
> servers in less than a month, have it again.

This are UltraSPARC T2 Plus which is 8 threads per core(ala CMT for us)
.. Though the CPU% reported by vmstat is more based on "scheduled in
execution" rather than what is executed by "computing engine" of the the
core.. So unless you have scheduled in execution 100% on the thread, it
wont be executing ..
So if you want to read mpstat right, you may not be executing everything
that is shown as executing but you are definitely NOT going to execute
anything that is not shown as executing.. My goal is to reach a level
where we can show PostgreSQL can effectively get to 100% CPU in say
vmstat,mpstat first...

-Jignesh

--
Jignesh Shah http://blogs.sun.com/jkshah
The New Sun Microsystems,Inc http://sun.com/postgresql