Oracle using only one processor - I have eight!
rodak
cores dedicated to it, SMT is turned on (default), so there are 8
processors available. It appears that most of the time,only one
processor is being used. I also have Oracle 9i running in an LPAR on
a P5-561, with two cores dedicated (SMT on, so 6 logical processors),
and it does the same thing. All my other (non-Oracle) LPARS seem to
use the processors evenly. What's different about Oracle that might
cause this behavior?
Tony
>I have Oracle 10g running in an LPAR on a P7 770. The LPAR has two
>cores dedicated to it, SMT is turned on (default), so there are 8
>processors available. It appears that most of the time,only one
>processor is being used.
How are you measuring that? What load is Oracle under during that
processing?
--
Tony Evans
Saving trees and wasting electrons since 1993
blog -> http://perceptionistruth.com/
books -> http://www.bookthing.co.uk/
[ anything below this line wasn't written by me ]
Mark Taylor
So ... you are running in p7 mode on the Power7 Right ? so SMT++ ..
You have 2 x Physical CPUs dedicated, so 2 x Virtuals and 8 x
Logicals ? The P5 is SMT only so 2 x Logical for each Virtual .. am
assuming that they are shared, as you say 2 x cores with 6 logical,
which would be 3 x Virtual .. how are you seeing which CPUs are busy ?
nmon ? nmon in shared mode can give you some skewey graphics,
especially if you are booting with say 0.3, shared uncapped, 3 x
virtual, you really want to look at the "p" flag which will tell you
total physical and work it out from there, or trace and user "curt" to
see your spread across the CPUs .. .. What you actually need to do is
boot the p5 in dedicated to compare apples with apples, beacuse ATM
you are comparing apples with a mango salad ..
Also, do you understand what each logical CPU is ? CPU0 will be the
physical, CPU1,2,3 will be logical Simultaneous Multithreads on CPU0,
so they are not actually full physical CPUs at all .. And you
understand how and when Simultaneous Multithreading takes advantage of
free registers on a CPU ?
Benefitting from Simultaneous Multithreading
Simultaneous multithreading is primarily beneficial in commercial
environments where the speed of an individual transaction is not as
important as the total number of transactions that are performed.
Simultaneous multithreading is expected to increase the throughput of
workloads with large or frequently changing working sets, such as
database servers and Web servers.
Workloads that see the greatest simultaneous multithreading benefit
are those that have a high Cycles Per Instruction (CPI) count. These
workloads tend to use processor and memory resources poorly. Large
CPIs are usually caused by high cache-miss rates from a large working
set. Large commercial workloads are somewhat dependent upon whether
the two hardware threads share instructions or data, or the hardware
threads are completely distinct. Large commercial workloads typically
have this characteristic. Workloads that share instructions or data,
including those that run extensively in the operating system or within
a single application, might see increased benefits from simultaneous
multithreading.
Workloads that do not benefit much from simultaneous multithreading
are those in which the majority of individual software threads use a
large amount of any resource in the processor or memory. For example,
workloads that are floating-point intensive are likely to gain little
from simultaneous multithreading and are the ones most likely to lose
performance. These workloads heavily use either the floating-point
units or the memory bandwidth. Workloads with low CPI and low cache
miss rates might see a some small benefit.
Measurements taken on a dedicated partition with commercial workloads
indicated a 25%-40% increase in throughput. Simultaneous
multithreading is should help shared processor partition processing.
The extra threads give the partition a boost after simultaneous
multithreading is dispatched because the partition recovers its
working set more quickly. Subsequently, the threads perform like they
would in a dedicated partition. Although it might be somewhat
counterintuitive, simultaneous multithreading performs best when the
performance of the cache is at its worst.
HTH
Mark Taylor
@yahoo.com GD
"rodak" <robert....@gmail.com> wrote in message
news:db571a14-25db-488f...@f15g2000pro.googlegroups.com...
You have 2 processors (cores), not 8.
Oracle server proces is single-threaded so it can never run on more than one
cpu (core) at one time.
If there is a single session running on an instance, session's server proces
is either consuming exatly one CPU (core) and one thread within a CPU if it
has something to do, or is waiting for IO (doing nothing).
If there are multiple server processes serving multiple sessions (or there
are active bg processes), they may (or may even not) run on more than one
CPU core simultaneously, depending on their CPU needs.
Regards
bob123
"rodak" a écrit dans le message de groupe de discussion :
db571a14-25db-488f...@f15g2000pro.googlegroups.com...
