Re: Managing CPU_COUNT for micro-partitioning on AIX
- From: "Mark Brinsmead" <pythianbrinsmead@xxxxxxxxx>
- To: gorbyx@xxxxxxxxx
- Date: Sun, 2 Jul 2006 18:57:25 -0600
Hmmm... This is something of a thorny issue...
First off, correct me if I'm wrong (I probably am, and I'm sure somebody
here likely
will), but isn't CPU_COUNT mainly used by the database to decide the degree
of
parallelism that can/should be used?
I doubt the database really cares whether you have .1 CPUs or .8 CPUs. If
you have
1 CPU or less, you're not likely to have a lot of opportunity for
parallelism. Unless,
I suppose, you have a 50% slice of two CPUs. I would *hope* the the IBM
hypervisor
presents the appropriate number of CPUs to the "virtual machine" (and thus
the
operating system and thereby the database).
In any event, I'm a little more interested in the other part of this
question -- the unasked
question about licensing implications.
Be *very* sure that you are clear on the licensing implications of
micropartitioning. This
is a subject that I have not researched in detail, but I would expect the
rules of "software"
partitioning to apply here. In essence, under the rules of software
partitioning, all (physical)
CPUs (CPU-cores) in the "box" will need to licensed for Oracle, regardless
of how many
(or how few) Oracle actually uses. Even if you *use* Oracle only on a
1/10th CPU uLPAR,
you'd need to license all 4 CPU-cores.
The rules for micro-LPARs, however, may be "special"...
Contrary to what Wolfgang suggests (facetiously, I am sure!) Oracle
probably will not
try to force you to pay for 20 CPU licenses to run Oracle on 20 micro-LPARs
of 1/10th
of a CPU each. Probably. Count your blessings; lots of other vendors
*would*!
Also bear in mind that micro-LPARs almost certainly depend on the "magic" of
"time-slicing". I would guess that the hypervisor probably apportions CPU
time to
micro-LPARs in quanta of 10 milliseconds since the last set of rules I saw
made
the "resolution" for the portion of a CPU 1/100th. (The *minimum* size is
1/10th, but
you can go in increments of 0.01 above that.)
Time division multiplexing is pretty cool stuff (it must be -- it's been
with us for 40+
years and its still going strong) but it's not quite magic.
Consider the analogy of microwave ovens. Unless you have one of those fancy
"inverter" microwave ovens, when you set the power level to 10%, 10% power
is
exactly what you do NOT get. What you *do* get is 100% power for 10% of the
time.
With a 1/10th CPU micro-LPAR, I would expect to get (something like) a 100ms
time
slice once per second. For the remaining 900ms, my database server will
probably
be doing precisely nothing. That's probably okay for a development box, but
I would
be *very* apprehensive about using this technology for production (and
therefore also
system test, UAT, etc.). Either way, be prepared for some unhappy anomolies
with
regard to stuff like "response time".
The above comments are based (mostly) on guesses. Don't quote me, and don't
get all upset if I am wrong.
DO do the homework yourself. If licensing considerations or performance
characteristics matter to you, (to the original poster, that is) DO check
these out
before you commit to this platform.
If you do learn anything interesting about licensing rules (for Oracle) or
implications
of time-slicing in the hypervisor (e.g., my guesses are completely wrong)
please
share your findings.
Good luck!
[Oh, by the way, I would personally just let CPU_COUNT default. But then,
I'd only be doing this on a development box, so I wouldn't care much, would
I?
;-) ]
Cheers,
-- Mark Brinsmead
Staff DBA,
The Pythian Group
http://www.pythian.com/blogs
Other related posts:
