Re: Re: Oracle and cpu/core

From: <l.flatz_at_bluewin.ch>
Date: Thu, 05 Nov 2015 08:51:30 +0000
Message-ID: <970806.9299.1446713490926.JavaMail.webmail_at_bluewin.ch>



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_at_gmail.com
Datum : 05/11/2015 - 09:01 (GMT)
An : woody.mckay_at_gmail.com
Cc : oracle-l_at_freelists.org
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_at_gmail.com> 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

--

http://www.freelists.org/webpage/oracle-l Received on Thu Nov 05 2015 - 09:51:30 CET

Original text of this message