Hi Karl Did you use ErlangC in your calculation? I dont think the calculation is in http://www.slideshare.net/karlarao/where-didmycpugo, is it? Thanks On Tue, Mar 11, 2014 at 9:34 PM, Karl Arao <karlarao@xxxxxxxxx> wrote: > From the paper, I did the simple math to estimate the end CPU requirement > and utilization without doing the migration. > Then I did the actual migration of workload and the numbers were about the > same that I got from the math. > > -Karl > > > On Tue, Mar 11, 2014 at 4:01 PM, Ls Cheng <exriscer@xxxxxxxxx> wrote: > >> Hi Karl >> >> One of my main concerns is how can we show in this case, TPS as >> exponentially distributed because as Cary points in his book in order to >> use M/M/n the distribution must be be exponential. >> >> I ran last week a couple of TPC load with 300 and 420 users then I used >> both transaction per second and logical reads per second metric and both >> showed normal data distribution and that is why I have doubts of how to use >> queueing theory in Oracle. >> >> From your paper was you able to predict the change from v1 to x2 without >> run the actual test? Then run the test and validate the prediction? >> >> >> Thanks >> >> >> >> >> >> >> >> On Tue, Mar 11, 2014 at 8:40 PM, Karl Arao <karlarao@xxxxxxxxx> wrote: >> >>> >>> >>> The queueing theory knowledge is still applicable. So here on the page 8 >>> of this paper http://www.slideshare.net/karlarao/where-didmycpugo >>> I'm migrating a workload from 16CPUs to 24CPUs.. you can say they are >>> the "servers" >>> then I have this 1205 TPS (transactions/sec) .. you can say this is the >>> "arrival rate" >>> >>> then I have this other numbers comparing the V2 and X2 running the 1205 >>> TPS >>> Exadata v2 >>> 40-45% CPU util >>> 17ms latency >>> AAS 9 <-- measure of db time >>> >>> Exadata x2 >>> 15-20% CPU util >>> 10ms latency >>> AAS 6 <-- measure of db time >>> >>> >>> So using the numbers above, when migrating from v2 to x2. 1 CPU of V2 is >>> equivalent to .58 CPU of X2 which means you have a faster processor (or >>> server in queueing theory) >>> >>> = 16*.45*.58 >>> = 4.2 this is how many CPUs you need on the X2 if you are using 7.2 CPUs >>> (16*.45) on the V2.. so 16 CPUs of V2 is equal to 9.4 CPUs of X2 >>> >>> >>> Applying the queueing theory concepts mentioned on the Chapter 5 of the >>> book: >>> >>> * so.. on the same rate of TPS, the faster CPU translates to faster per >>> execution resulting to lower CPU utilization >>> * so the extra CPU capacity on the faster CPU can be used for additional >>> transactions or workload growth.. resulting to more work being done >>> * now if you do it the other way.. faster to slower.. each SQL will >>> execute longer and in turn will cause higher CPU.. The important thing here >>> is to have the CPU equivalent of the source # of CPUs taking into >>> consideration the chip efficiency factor (speed) on the destination to >>> accommodate the processing power it needs and not anymore aggravate the >>> speed down (faster to slower) effect. So you'll still be able to achieve >>> the same TPS but the response times will be longer and CPU util higher. >>> >>> even on slower to faster CPUs, the TPS may not even change.. because >>> it's the same amount of workers that's doing the same amount of work as you >>> move across platforms. the change you'll be seeing is just lower resource >>> utilization and the gains you'll have is being able to put more work on the >>> workers resulting to more transaction rate >>> >>> So when observing change of workloads when moving to slower-faster with >>> no workload change do the following: check the load profile (TPS).. it >>> should be the same.. then check on per SQL if per exec remained the same >>> (it should be the same).. then check on CPU usage it should be lower >>> >>> And when observing change of workloads when moving to slower-faster with >>> workload change do the following: check the load profile (TPS).. it should >>> be higher.. then check on per SQL if per exec remained the same (it should >>> be higher).. then check on CPU usage it should be higher >>> >>> >>> Now, if the question is when do I run out of gas? then I'll do the >>> regression analysis on it. >>> >>> BTW, if you are interested on this kind of stuff, I have subscribed on >>> the following google groups owned by Neil Gunther and from time to time >>> there are a lot of discussions about this area of performance >>> >>> guerrilla-capacity-planning@xxxxxxxxxxxxxxxx >>> perfviz@xxxxxxxxxxxxxxxx >>> >>> >>> >>> >>> -Karl >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Mar 11, 2014 at 12:03 PM, Ls Cheng <exriscer@xxxxxxxxx> wrote: >>> >>>> Hi Karl >>>> >>>> So I guess you agree that Queueing Theory is not applicable using >>>> database metrics, which is basically I am looking for >>>> >>>> I've got the statistics without tears book as well, it is good about >>>> normal distribution.... :-) >>>> >>>> >>>> >>>> On Tue, Mar 11, 2014 at 4:51 PM, Karl Arao <karlarao@xxxxxxxxx> wrote: >>>> >>>>> I've read both of the books, and I love them. On this link are my >>>>> notes - http://goo.gl/b8aNOj >>>>> Although queueing theory is pretty cool, I find the chapter on >>>>> regression analysis more suited for real world but the queueing theory >>>>> chapter builds a nice foundation of ResponseTime=ServiceTime+QueueTime >>>>> which is from a practical use case point of view the Performance Page >>>>> you've got all of that components in a nice pretty dashboard broken down >>>>> into wait class with CPU as your service time and everything else is >>>>> QueueTime. >>>>> >>>>> For the regression analysis on the link (r2project), what I did is >>>>> rank the independent values (x) that has the high correlation coefficient >>>>> and make use of that to forecast the dependent value (y). Also the page 8 >>>>> of this paper http://www.slideshare.net/karlarao/where-didmycpugoalso >>>>> gives you more insights about the "more CPUs, faster CPUs, more and >>>>> faster CPUs" section of the book, I think it's page 32. >>>>> >>>>> >>>>> -Karl >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Mar 11, 2014 at 9:46 AM, Ls Cheng <exriscer@xxxxxxxxx> wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> I have been reading Craig's book and Cary's book (chapter 9) for the >>>>>> last 2 weeks, the theory in the books look great but when I tried to >>>>>> start >>>>>> using in the real world it the questions started to appear. >>>>>> >>>>>> For example, arrival rate, what arrival rate in Oracle is >>>>>> exponentially distributed......? Cary says logical reads in his book but >>>>>> I >>>>>> just dont see how can that be possible by using the database metric (for >>>>>> example system metric such as Logical Reads Per Sec or Logical Reads Per >>>>>> User Call). Craig's book I dont even mention a useful database metric (I >>>>>> havent finished the book yet so I might have missed if he has said so), >>>>>> the >>>>>> book just uses all the time the work unit transaction per second. >>>>>> >>>>>> Both book provide a queueing theory workbook but they are useless >>>>>> from database metric point of view since no metric is poisson or >>>>>> exponential distributed (again I am not able to see it, if someone can >>>>>> please advice). >>>>>> >>>>>> But Jonathan you just mention "buffer gets per user call" which is >>>>>> similar to Logical Reads Per User Call from v$sysmetric, why do you think >>>>>> that is exponentially distributed :-? >>>>>> >>>>>> >>>>>> Thanks >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Mar 11, 2014 at 3:30 PM, Jonathan Lewis < >>>>>> jonathan@xxxxxxxxxxxxxxxxxx> wrote: >>>>>> >>>>>>> >>>>>>> It's an interesting question - and I don't think you can find a >>>>>>> current metric that would help unless you started doing something a >>>>>>> little >>>>>>> clever with ASH. >>>>>>> >>>>>>> In an OLTP system something like 'buffer gets per user call" would >>>>>>> probably be a reasonable fit - but there's no capture at that >>>>>>> granularity. >>>>>>> Similarly disc I/O requests per call might be appropriate. Then there >>>>>>> are >>>>>>> things like disk I/O requests per disc per second. But every >>>>>>> possibility I >>>>>>> think of requires too fine a level of granularity unless you can find a >>>>>>> way >>>>>>> to construct a valid model from the samples in v$active_session_history. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> Jonathan Lewis >>>>>>> http://jonathanlewis.wordpress.com >>>>>>> @jloracle >>>>>>> ------------------------------ >>>>>>> *From:* oracle-l-bounce@xxxxxxxxxxxxx [oracle-l-bounce@xxxxxxxxxxxxx] >>>>>>> on behalf of Ls Cheng [exriscer@xxxxxxxxx] >>>>>>> *Sent:* 11 March 2014 14:20 >>>>>>> *To:* Paul Houghton >>>>>>> *Cc:* Oracle Mailinglist >>>>>>> *Subject:* Re: Queueing Theory in Oracle >>>>>>> >>>>>>> Hi >>>>>>> >>>>>>> I have had a quick read, I think the link you posted talks about >>>>>>> queue time but not about queueing theory such as a M/M/n model. The >>>>>>> problem >>>>>>> is I am not able to find a database metric that is exponential >>>>>>> distributed >>>>>>> which allows us to use the M/M/n queueing theory. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Mar 11, 2014 at 3:16 PM, Paul Houghton < >>>>>>> Paul.Houghton@xxxxxxxxxxxxxxx> wrote: >>>>>>> >>>>>>>> Craig Shallahamer talks about queuing theory in the following blog >>>>>>>> post. >>>>>>>> >>>>>>>> >>>>>>>> http://shallahamer-orapub.blogspot.co.uk/2011/08/why-tuning-oracle-works-and-modeling-it.html >>>>>>>> >>>>>>>> I hope this is helpful >>>>>>>> >>>>>>>> PaulH >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Karl Arao >>>>> Blog: karlarao.wordpress.com >>>>> Wiki: karlarao.tiddlyspot.com >>>>> Twitter: @karlarao <http://twitter.com/karlarao> >>>>> >>>> >>>> >>> >>> >>> -- >>> Karl Arao >>> Blog: karlarao.wordpress.com >>> Wiki: karlarao.tiddlyspot.com >>> Twitter: @karlarao <http://twitter.com/karlarao> >>> >> >> > > > -- > Karl Arao > Blog: karlarao.wordpress.com > Wiki: karlarao.tiddlyspot.com > Twitter: @karlarao <http://twitter.com/karlarao> >