Comments on: Instance Caging http://antognini.ch/2009/11/instance-caging/ Fri, 27 Jan 2012 07:31:12 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Christian Antognini http://antognini.ch/2009/11/instance-caging/comment-page-1/#comment-27102 Christian Antognini Thu, 16 Jun 2011 07:27:53 +0000 http://antognini.ch/?p=774#comment-27102 Hi Sigrid > first of all, let me congratulate you on your Berlin workshop regarding the > query optimizer - it was a real informative, nice and interesting event! Thank you! > For example: On one DSS system, with a mean mreadtim of 9.12, the standard deviation was 3.74, > resulting in a conclusion going "with a probability of 90%, mreadtim lies between 2.97 and 15.27"... > Even more impressing, on one OLTP system, the mean mbrc was 50, with a stddev of 32, giving a > confidence interval, at 90% probability, of minus 3 to plus 103 for mbrc... What about the standard deviation of sreadtim? > Now I wonder how to explain this extreme variation, given that the values are already taken > over a 10-hour period... the only source of variation would be the day of week, and AFAIK > there should not be such great variation in workload here, at least as regards the OLTP applications. IMO, because of the way multiblock reads work, makes such variations more or less normal. In fact, the size of multiblock reads is strongly dependent on the data which is stored in the buffer cache. > Could it be that sampling over a 10-hour period is not a good thing to do, and if so, > for what reason (I just remember you having an example involving more fine-grained > sampling periods, which were aggregated somehow afterwards ...)? I always worked with shorter periods. With them I had the opportunity to choose between an average, max, or whatever value I wanted. With long periods you can only take the average. > Also, I can't help wondering whether this great standard deviation invalidates the result, somehow...? IMO no. Cheers, Chris Hi Sigrid

> first of all, let me congratulate you on your Berlin workshop regarding the
> query optimizer – it was a real informative, nice and interesting event!

Thank you!

> For example: On one DSS system, with a mean mreadtim of 9.12, the standard deviation was 3.74,
> resulting in a conclusion going “with a probability of 90%, mreadtim lies between 2.97 and 15.27″…
> Even more impressing, on one OLTP system, the mean mbrc was 50, with a stddev of 32, giving a
> confidence interval, at 90% probability, of minus 3 to plus 103 for mbrc…

What about the standard deviation of sreadtim?

> Now I wonder how to explain this extreme variation, given that the values are already taken
> over a 10-hour period… the only source of variation would be the day of week, and AFAIK
> there should not be such great variation in workload here, at least as regards the OLTP applications.

IMO, because of the way multiblock reads work, makes such variations more or less normal. In fact, the size of multiblock reads is strongly dependent on the data which is stored in the buffer cache.

> Could it be that sampling over a 10-hour period is not a good thing to do, and if so,
> for what reason (I just remember you having an example involving more fine-grained
> sampling periods, which were aggregated somehow afterwards …)?

I always worked with shorter periods. With them I had the opportunity to choose between an average, max, or whatever value I wanted. With long periods you can only take the average.

> Also, I can’t help wondering whether this great standard deviation invalidates the result, somehow…?

IMO no.

Cheers,
Chris

]]> By: Christian Antognini http://antognini.ch/2009/11/instance-caging/comment-page-1/#comment-26677 Christian Antognini Tue, 14 Jun 2011 12:54:38 +0000 http://antognini.ch/?p=774#comment-26677 Hi Erwin I'm not aware of particular problems in this area. Since I do not have an AIX system handy, I cannot test it either. You might try to open an SR... Cheers, Chris Hi Erwin

I’m not aware of particular problems in this area. Since I do not have an AIX system handy, I cannot test it either. You might try to open an SR…

Cheers,
Chris

]]> By: Erwin Beckers http://antognini.ch/2009/11/instance-caging/comment-page-1/#comment-25883 Erwin Beckers Fri, 10 Jun 2011 13:10:16 +0000 http://antognini.ch/?p=774#comment-25883 Hello all, I've been doing some tests on the AIX platform with regards to instance caging. I've set it up on an LPAR with 2 logical CPUs, but have been unable to actually limit the CPU usage. It seems that no matter what the limit is set to, I can always manage to eat up all the cpu allocation on server level. This shouldn't really happen, but I have no clue as to what i might have done wrong. I've got the resource_manager setup and set the cpu_count parameter according to the importance (diving to 1 each) over each instance. Hello all,
I’ve been doing some tests on the AIX platform with regards to instance caging.
I’ve set it up on an LPAR with 2 logical CPUs, but have been unable to actually limit the CPU usage.
It seems that no matter what the limit is set to, I can always manage to eat up all the cpu allocation on server level.
This shouldn’t really happen, but I have no clue as to what i might have done wrong. I’ve got the resource_manager setup and set the cpu_count parameter according to the importance (diving to 1 each) over each instance.

]]> By: Randy Johnson http://antognini.ch/2009/11/instance-caging/comment-page-1/#comment-18791 Randy Johnson Sat, 05 Mar 2011 01:00:14 +0000 http://antognini.ch/?p=774#comment-18791 Nice post Christian. Very clear and helpful. I wonder if Oracle is contemplating moving the CBO to a % based mechanism rather than CPU_COUNT. That would allow us to cage instances to a percentage of CPU rather than a fixed number. No doubt that would be a big effort. If they did it would behave much like the DBRM manages CPU internally through the plan directives. Nice post Christian. Very clear and helpful.
I wonder if Oracle is contemplating moving the CBO to a % based mechanism rather than CPU_COUNT. That would allow us to cage instances to a percentage of CPU rather than a fixed number. No doubt that would be a big effort. If they did it would behave much like the DBRM manages CPU internally through the plan directives.

]]> By: Blogroll Report 27/11/2009-04/12/2009 « Coskan’s Approach to Oracle http://antognini.ch/2009/11/instance-caging/comment-page-1/#comment-6429 Blogroll Report 27/11/2009-04/12/2009 « Coskan’s Approach to Oracle Fri, 18 Dec 2009 00:13:35 +0000 http://antognini.ch/?p=774#comment-6429 [...] 1-How to limit number of CPU for an instance with instance caging feature of 11GR2 ? Christian Antognini-Instance Caging [...] [...] 1-How to limit number of CPU for an instance with instance caging feature of 11GR2 ? Christian Antognini-Instance Caging [...]

]]> By: Log Buffer #171: a Carnival of the Vanities for DBAs | The Pythian Blog http://antognini.ch/2009/11/instance-caging/comment-page-1/#comment-6195 Log Buffer #171: a Carnival of the Vanities for DBAs | The Pythian Blog Fri, 04 Dec 2009 18:04:37 +0000 http://antognini.ch/?p=774#comment-6195 [...] Antognini is, as always, Striving for Optimal Performance. He has a worthwhile post on instance caging, “ . . . nother small but useful feature of Oracle Database 11g Release [...] [...] Antognini is, as always, Striving for Optimal Performance. He has a worthwhile post on instance caging, “ . . . nother small but useful feature of Oracle Database 11g Release [...]

]]> By: Greg Rahn http://antognini.ch/2009/11/instance-caging/comment-page-1/#comment-6124 Greg Rahn Sun, 29 Nov 2009 20:43:00 +0000 http://antognini.ch/?p=774#comment-6124 @Marcus This feature is meant to be used for resource management of multiple instances on a single server/platform. It allows one to "curb" instances to limit the maximum CPU. One can set the sum of CPU_COUNT for all instances to match the total physical CPU count (using instance caging to partition) or the sum of the CPU_COUNTs can be higher than the physical CPU count (using instance caging to over-provision, but limit). The latter potentially allows for better host utilization given that each individual instance is below its max CPU threshold. For licensing, you can use hard partitioning with Oracle VM to limit the CPUs that have to be licensed as shown by this wiki note: http://wiki.oracle.com/page/Hard+partitioning @Marcus

This feature is meant to be used for resource management of multiple instances on a single server/platform. It allows one to “curb” instances to limit the maximum CPU. One can set the sum of CPU_COUNT for all instances to match the total physical CPU count (using instance caging to partition) or the sum of the CPU_COUNTs can be higher than the physical CPU count (using instance caging to over-provision, but limit). The latter potentially allows for better host utilization given that each individual instance is below its max CPU threshold.

For licensing, you can use hard partitioning with Oracle VM to limit the CPUs that have to be licensed as shown by this wiki note: http://wiki.oracle.com/page/Hard+partitioning

]]> By: Marcus Mönnig http://antognini.ch/2009/11/instance-caging/comment-page-1/#comment-6121 Marcus Mönnig Sun, 29 Nov 2009 16:45:03 +0000 http://antognini.ch/?p=774#comment-6121 Christian, thanks for your update on instance caging. What leaves me clueless is that setting CPU_COUNT has no influence on the number of CPUs I have to licenses. This makes virtualization of Oracle DBs even more unfeasible. Say e.g., I have one physical machine with four CPUs and four virtual machines running a DB each on it. Until now, I needed to get four 4-CPU licences for that. Now, I can set CPU_COUNT to one for all instances and I still have to get the same licenses. This is ridiculous. IMHO the only reasonable way of setting the CPU_COUNT is to open the case and physically unplug CPUs from the machine. Christian, thanks for your update on instance caging.

What leaves me clueless is that setting CPU_COUNT has no influence on the number of CPUs I have to licenses. This makes virtualization of Oracle DBs even more unfeasible. Say e.g., I have one physical machine with four CPUs and four virtual machines running a DB each on it. Until now, I needed to get four 4-CPU licences for that. Now, I can set CPU_COUNT to one for all instances and I still have to get the same licenses. This is ridiculous.
IMHO the only reasonable way of setting the CPU_COUNT is to open the case and physically unplug CPUs from the machine.

]]>