Re: Negative ramifications of setting CPU_COUNT lower?
- From: Dan Norris <dannorris@xxxxxxxxxxxxx>
- To: mwf@xxxxxxxx
- Date: Fri, 6 Nov 2009 13:14:07 -0600
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#ADMIN13333
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:
