RE: Negative ramifications of setting CPU_COUNT lower?

I'll take the opportunity to fix two typos "too small and SGA" should be
"too small an SGA" and "disabus" should be "disabuse." I don't know where
these gremlins come from that depress keys on my keyboard that differ from
what my mind is directing and omit characters I'm sure I have typed.

 

And although I think Dan got my sentiment about right, I just wanted to note
for the record I did not type or utter the phrase "best practice." In
general I think people mean "the way I do it and you're stupid if you try
anything else"  when they type "best practice" though I suspect Dan is an
exception to that general rule and means it in a kind fashion and only uses
it at all because even a fine fellow like Dan cannot completely resist being
taken over by market speak under his current employment arrangement. So if
you strike out "best practice" and replace it with "a pretty good starting
point that might turn out to be good enough" then you've captured my
sentiment exactly. And I think that is also Oracle's goal: Get the settings
right out of the box most of the time just by looking at the system you're
running on. It ain't perfect yet, and they shouldn't even be trying to make
it perfect - but it is doggone good.

 

Of course that's no reason to treat warnings as errors. But I think I've
already beaten that dead horse several times. PETA please note the horse was
already dead when I started beating it.

 

Regards,

 

mwf

 

  _____  

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Dan Norris
Sent: Friday, November 06, 2009 2:14 PM
To: mwf@xxxxxxxx
Cc: sacrophyte@xxxxxxxxx; ORACLE-L
Subject: Re: Negative ramifications of setting CPU_COUNT lower?

 

Note that "instance caging" is enabled by using database resource manager in
conjunction with setting cpu_count. I don't think it answers your questions,
but it is relevant as it is a case where setting the cpu_count is necessary.
I agree with Mark that, in general, letting Oracle determine and use its
defaults is best practice--especially when going to a new release.

Anyway, here's the info from the 11.2 docs on instance caging:
http://download.oracle.com/docs/cd/E11882_01/server.112/e10595/dbrm007.htm#A
DMIN13333

Dan

On Fri, Nov 6, 2009 at 12:32 PM, Mark W. Farnham <mwf@xxxxxxxx> wrote:

Oracle has done some really marvelous work coming up with really pretty good
automated guesses at good starting points for the various knobs and switches
and even more impressive work about dynamically adjusting them to the
workload. The upshot is that unless you're doing something specfically
different for a real world reason (which includes not perturbing a working
systems' settings), you should at least give Oracle's defaults a chance to
succeed, especially in a fresh environment.

 

The downside of the success of such efforts is a re-surgence of the notion
that they can calculate ratios of values that should be forbidden, case in
point too small and SGA in the face of a lot of CPUs on a system. We tried
really, really hard circa 1990-1995 under Oracle VLDB and MOSES to disabus
Oracle of the notion of every having any artificial limitations, and for a
time we succeeded. Give us the live hand grenade, was the phrase, and if
we're not careful it is our fault, not yours. Every single time (EVERY
SINGLE TIME) I have ever seen an artificial limitation injected into the
settings it has caused someone a problem sometime. Using the various
resources to predict good defaults is one thing; using them to inject error
conditions that do not need to be errors is another. Even if it had only
warned that the sga was probably too small the user problem would have gone
away naturally. And of course once someone gets the idea that artificial
limits (rather than automated good starting points and warning about dubious
choices) are an acceptable thing, hilarity ensues. 20 lashes with a wet
noodle to the manager who dropped the ball on this one. And I INSIST it is a
dropped ball (with the obvious warning the corrective in the general case).

 

Then there is the whole substance issue on threads and equivalent horsepower
and 9 women trying to have a baby in one month, but my intention in this
contribution is only to wiegh in against any artificial limitations. SAAAL?
(society against any artificial limitations)?

 

Regards,

 

mwf

 

 

 

  _____  

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Charles Schultz
Sent: Friday, November 06, 2009 9:47 AM
To: ORACLE-L
Subject: Negative ramifications of setting CPU_COUNT lower?

 

Good day,

 

We recently moved 55 databases from a Sun F15K to a Sun T5440. You can
imagine what happened next. =)

Reading Glenn Fawcett's blog
<http://blogs.sun.com/glennf/entry/virtual_cpus_effect_on_oracle> , we
indeed see that CPU_COUNT = 256. I have filed an SR with Oracle, but as I
wait I am curious if those of you in the know could tell me what are the
negative ramifications of resetting CPU_COUNT. If we go forward with this
action, I want to do so in an informed manner, and not simply shooting in
the dark.

 

Thanks.

-- 
Charles Schultz

Other related posts: