Re: Managing CPU_COUNT for micro-partitioning on AIX

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_at_oneneck.com> 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

--
http://www.freelists.org/webpage/oracle-l