Discussion:
max native threads per engine
(too old to reply)
unknown
2009-09-09 13:16:30 UTC
Permalink
I have a question about "max native threads per engine" on a
"Sun T5240
UltraSPARC-T2+"
Since the native thread and the LWP have a 1:1 relationship,
should the
"max native threads per engine" be set to the number of
engines, rather
than the default of 50/engine?

My host: Sun T5240 UltraSPARC-T2+ with (2) 8 core processors
with 128
thread
My Version: Solaris 10

My Engines: 64
My Version: ASE 15.0.2

From ASE Documentation:
Defines the maximum number of native threads the server
spawns per
engine.
When the limit for the native threads is reached, Adaptive
Server
sessions
that require a native thread, sleep until another session
releases a
native
thread.

From Solaris Documentation:
In Solaris9+, each native thread is assigned to a unique
LWP, and that
relationship is stable for the lifetime of the native
thread.
Jeff Tallman [Sybase]
2009-09-15 12:35:02 UTC
Permalink
No - typically, "max native threads per engine" are only used by the
RTMS inteface when interfacing directly to message buses (MQ, JMS,
etc.). In that case, you would need to set "max native threads per
engine" to the number of concurrent messages that you would be expecting
to send to the queue simultaneously.

However, there is a tuning issue with Sun T series. The Sun Niagara
uses CMT threading which is more like simplistic timeslicing vs. SMT
threading. The result is that if you have more threads per core than
engines, the engines get yanked off the cpu frequently. So for example,
in your case, unless planning on running 128 engines and keeping them
all busy (i.e. a lot of in-memory fully cached queries), you will get
hammered with bad performance compared to machine it replaced. At a
theoretical level with 2x8 cores, you really only have 16 cores for
execution. All chip threading attempts to do is leverage cpu idle
cycles by swapping contexts with other processes that can run. For
example, if the CPU has to fetch something from main memory vs. L2
cache, it will take a few clock cycles to fetch it. Those clock cycles
are idle. With chip threading, the premise is to swap something on
during that time.

CMT looks strictly at time-slicing vs. an interrupt that is driven when
a process has to fetch from main memory or synchronous disk io. As a
result, with 8 threads per core, a process will likely only get ~12% of
the cpu time - assuming 100% efficiency of the task switch (NOT!).....

So, if you are planning on running less than 16 engines, I would have
the sysadmins set the number of threads per core to 1 (this is tunable
with 1,2,4,8). If planning on 24 engines, you will need 2 threads per
core which would allow a maximum of 32 engines.

You also may want to reduce the default "runnable process search count"
to see what the optimal is for the number of threads per core when
running >1 thread per core....it might be a really low number (<<100).


Jeff Tallman
Enterprise Data Management Products Technical Evangelism
***@sybase.com
http://blogs.sybase.com/database
Post by unknown
I have a question about "max native threads per engine" on a
"Sun T5240
UltraSPARC-T2+"
Since the native thread and the LWP have a 1:1 relationship,
should the
"max native threads per engine" be set to the number of
engines, rather
than the default of 50/engine?
My host: Sun T5240 UltraSPARC-T2+ with (2) 8 core processors
with 128
thread
My Version: Solaris 10
My Engines: 64
My Version: ASE 15.0.2
Defines the maximum number of native threads the server
spawns per
engine.
When the limit for the native threads is reached, Adaptive
Server
sessions
that require a native thread, sleep until another session
releases a
native
thread.
In Solaris9+, each native thread is assigned to a unique
LWP, and that
relationship is stable for the lifetime of the native
thread.
Loading...