Re: Managing CPU_COUNT for micro-partitioning on AIX
- From: "Mark Brinsmead" <pythianbrinsmead@xxxxxxxxx>
- To: Brandon.Allen@xxxxxxxxxxx
- Date: Wed, 5 Jul 2006 21:17:33 -0600
CPU_COUNT increased from 8 to 10? How "big" was the microLPAR to begin
with?
Is the hypervisor doing something sleazy like offering a (new) logical CPU
for every 0.1 of a physical CPU your LPAR is given?
In a strange way, that could almost make sense -- each "time slice" you are
given on a physical CPU is modeled inside the LPAR as a separate logical
processor. Of course, I'm guessing again.
My advice: if your sysadmins like to keep you in the dark, "borrow" the
manuals and educate yourself. A DBA's job is made enormously more difficult
is he/she is not *permitted* to know the details of the "hardware" and
operating system the database is running on. I can *imagine* a situation
where somebody approaches me and tells me something like: "I want you to
manage my database. But you're not allowed to know the operating system,
the number of CPUs, the amount of memory, or the physical structure of the
storage layer; DBA's don't need to know these things, they are matters fo
Sysadmins only."
Of course, I can easy imagine my (probably two-syllable) response, too. ;-)
Anyway, I would be concerned about the inflated CPU_COUNT here. CPU_COUNT
is probably a good but less important that most of us really care to
imagine, but CPU_COUNT=10 on a system with (maybe) 1.5 "physical" processors
(okay, you're probably getting fractions of all four) could probably lead to
a number of bad choices on the part of the optimizer.
Where I believe it is usually appropriate to leave CPU_COUNT alone and let
Oracle and the OS do what comes naturally, I think in this case I would
probably override what I had been given, and set CPU_COUNT to 2 or maybe 4.
(If you *are* getting little slices of 4 physical processors, then your
theoretical maximum concurrency would, indeed, be 4.) Certainly CPU_COUNT =
10 sounds out of line for your circumstances.
You should maybe try to impress upon your sysadmins (or their manager) that
messing with your servers without consulting you first can be a bad idea.
In general, *adding* CPUs or memory is pretty easy, and relatively safe.
*Removing* resources, however, can be another matter. This can definitely
require advanced planning.
You don't (for example) want to find youself in a situation where your SGA
is suddenly bigger than RAM...
On 7/4/06, Allen, Brandon <Brandon.Allen@xxxxxxxxxxx> wrote:
We're running 10.2.0.2 on AIX 5.3 with LPARs and my Unix admins threw in
a few extra tenths of a CPU in our production environment without even
giving me any advanced notice, which I wasn't too happy about considering we
hadn't even tested it, but Oracle seemed to handle it without any problems
and cpu_count magically went up from 8 to 10. Honestly, I'm not even sure
how many tenths of physical CPUs I'm running on. All I know is what it
looks like according to topas, vmstat, sar and Oracle, which are all in
agreement that there were 8, and are now 10, virtual/logical CPUs, but I
don't really know exactly how it's configured behind the scenes other than
that there are really only 4 multi-core CPUs in the box. My Unix admins
like to keep me in the dark as much as possible so I don't ask too many
questions. You'll notice when you run the AIX 5.3 performance utilities
there are metrics called ent and entc% or something like that - can't
remember for sure off the top of my head, but these represent the number of
virtual CPUs your LPAR is entitled to, and the % of your entitlement you are
consuming.
Regards,
Brandon
Privileged/Confidential Information may be contained in this message or
attachments hereto. Please advise immediately if you or your employer do not
consent to Internet email for messages of this kind. Opinions, conclusions
and other information in this message that do not relate to the official
business of this company shall be understood as neither given nor endorsed
by it.
--
Cheers,
-- Mark Brinsmead
Staff DBA,
The Pythian Group
http://www.pythian.com/blogs
Other related posts:
