Re: Re: Oracle and cpu/core

  • From: "l.flatz@xxxxxxxxxx" <l.flatz@xxxxxxxxxx>
  • To: niall.litchfield@xxxxxxxxx
  • Date: Thu, 5 Nov 2015 08:51:30 +0000 (GMT+00:00)

Hi,
what I normally do is picking the awr from each instance where the cpu delta is
highest and find out how many cores got used.
you can query that right from the dba_hist_ tables by dividing cpu times in
seconds by the number of seconds of the snapshot (usually 3600).
Adding this up for each instance is kind of your worst case. Consider it is
still not the peaks but rather a per snapshot average.
Thus, I believe although not all your databases will be peaking the same time,
it would still be a good idea to have that amount of CPU ready.
You can overload a Intel CPU by roughly factor 1.5 (two threads) . Thus you can
plan with 64 * 1.5 = 96 CPUs. 96 instances might work out if you got a lot of
tiny instances that use less than a CPU on average. It sounds ambitious though.
Looks like consolidating in CDB could be a good idea.
Of course as Niall said instance caging is a good idea and you should use it.
Regards
Lothar
----Ursprüngliche Nachricht----
Von : niall.litchfield@xxxxxxxxx
Datum : 05/11/2015 - 09:01 (GMT)
An : woody.mckay@xxxxxxxxx
Cc : oracle-l@xxxxxxxxxxxxx
Betreff : Re: Oracle and cpu/core
One solution I would have thought appropriate here would be to implement the
instance caging feature of Oracle. There's an 11g white paper on this
http://www.oracle.com/technetwork/database/performance/instance-caging-wp-166854.pdf
. You've got a 64 core server and are proposing 96 instances so you are
planning on over provisioning - there's nothing wrong with that - but you do
rely on the assumption that the database instances will be mostly idle, or at
least not busy at the same time. If this doesn't prove valid then in an
instance caging environment you will have waits for cpu, and in a non caged
environment you will likely have nasty cases where db1 effectively kills db
2-96 :).
Given that you've gone with a separate listener and ip for each database, I'd
also give serious consideration to using virtualization with one db per vm. You
can then allow the hypervisor to do the cpu scheduling.
On Wed, Nov 4, 2015 at 6:40 PM, Woody McKay <woody.mckay@xxxxxxxxx> wrote:
Hi,
Our hosting unit is designing a large server and want to put about 96 SID's on
it. They've worked through I/O and RAM considerations. This is on Win 64 2012
R2.
However, they are not sure about cpu/core count and usage. They currently have
64 cores and need to know how many of the cores will each SID (oracle.exe)
can/will use. If a SID can't use all cores, then what's the best way to spread
the SIDs across all the cores. I talked about cpu groups, but they said that
Oracle always picks cpu group 0 on startup and they have to manually reassign
the groups to each oracle.exe process.
I've only had about 40 SIDs on a box with 24 cores, so I don't really have the
experience to provide the best answers.
Any thoughts? Thanks
--
Sincerely,
WoodyMcKay
--
Niall Litchfield
Oracle DBA
http://www.orawin.info

Other related posts:

  • » Re: Re: Oracle and cpu/core - l.flatz@xxxxxxxxxx