Hmm sounds really cool, will need to have a look into this Big-Oh thing. Thanks Regrads LSC On 2/23/06, MARK BRINSMEAD <mark.brinsmead@xxxxxxx> wrote: > > I am also no expert on capacity planning, but I > do know that it is at once both much more complex > than that, and yet (sometimes) surprisingly easy. > > The first thing to realise is that growth rates are > almost *never* linear. It's been my experience that > this is number one error in capacity planning; the > foolish notion that if it takes X CPU cycles to > achieve Y units of work, it will take 10 * X CPU > cycles to achive 10 * Y units of work. > > Depending on the task you are trying to achieve, the > growth curves may be logarithmic, quadratic, > exponential, or whatever. Now, here's the trick: > if you know even just a *little* bit about the > critical tasks being performed, you can make a very > good guess about which kind of growth curve to use. > > Reporting tasks are commonly dominated by sorting, > so curve of 'N * log(N)' (the Big-Oh complexity of > most sorting algorithms) might be a good guess. > (Here, N is really the number of records being > sorted, but it's often equally valid to consider it > to be something like your daily transaction volume.) > > Order entry tasks generally involve inserting > rows into tables indexed with B-Tree indexes. > The Big-Oh complexity for inserting N rows into > a B-tree index is 'N^2 * Log(N)', so if you know > nothing else, this can be a very good first guess > for your growth curve. > > The more you know about the implementation of the > application, the more reliably you can model the > growth curves. > > Once you have chosen the best curves you can, all > you need is two good samples, and you can project > growth with surpising accuracy... > > I have only had to do this once -- a *very* long > time ago -- but at the time I used this to plan > capacity for a Fortune-500 client implementing a > new mail-order line of business. Based on only > moderate knowledge of the implementation of the > application (e.g., this task is dominated by > sorting; that task is dominated by inserting into > indexed tables) and given accurate measurements > from (about) their 3rd and 6th months of operation, > I was able to project CPU capacity for 6, 12, 24, > and 60 months. > > I was told after the fact that these had proven to > be the most accurate capacity plans ever done in > that organisation (they had a whole team of > "professional" capacity planners) and that all of > my predictions up to 24 months had hit withing > +/- 10% of observed actuals. Of course, I might > have just been lucky... ;-) > > Anyway, I have found this technique to be useful > in the past, although I've never had cause to > revisit it. If you're not already familiar with > 'Big-Oh' growth curves (or algorithm analysis in > general) there are numerous books on the subject. > As far as I know, the definitive ones on the subject > are from the authors Aho, Hopcroft and Ullman [who > often work(ed) in collaboration]; chances are, you > can still find their texts in most University > book stores. > > > ----- Original Message ----- > From: LiShan Cheng <exriscer@xxxxxxxxx> > Date: Thursday, February 23, 2006 4:26 am > Subject: Re: Capacity Planning > > > Hi > > > > Thanks for the reply. > > > > I am quite lost in this area basically becase I am quite reluctant > > aboutcapacity planning since I have seen quite a few and I have > > seen cero > > success. Many times I would really like to ask the guy who did the > > plan how > > he did it without knowing so many factors. > > > > In my last project for example, a HP guy estimated 12 CPUs for a > > serverhowever in the practice we almost doubled otherwise the > > server would be CPU > > bounded. > > > > I understand it is necessary but... whose job should it be? DBA? > > HardwareVendor? Software Maker? System Admin? Mix of all is > > probably the answer but > > then what information is needed by a DBA to perform such job? > > > > Shall I tkprof 10 sessions get the cpu time and multiply by the > > real number > > of users I will have? :-) > > > > Cheers > > > > -- > > LSC > > > > > > > > On 2/23/06, Jurijs Velikanovs <j.velikanovs@xxxxxxxxx> wrote: > > > > > > I'm interested in that question as well. I believe almost all DBA-s > > > had, have, will have to answer it. > > > The most difficult for me was CPU power, I/O throughput and Memory > > > planning for home made (custom development) applications > > > . > > > By my experience you can spend tremendous amount of time (not just > > > yours time) creating capacity plan for a particular system during an > > > application development time. Work with analysts, designers, > > > developers documenting detailed calculations and all assumptions. > > But> end of the day you will get, a +/- 50% accurate result ;). > > > If at the end the applications will not perform well enough the > > > Developers will blame HW and will some think like "You need > > double HW > > > resources to get XX sec response time". DBA-s and Admins would > > say "We > > > already have some thing like top HW". It is always difficult to > > say if > > > developers have done their work well without knowing the > > applications> business. > > > . > > > At the moment I think that most effective way to plan that type of > > > capacity is make assumptions based on you or others project members' > > > previous experience. > > > - If in the past you have worked with kind of systems you currently > > > developing you know already the most important parts of application > > > you have to pay attentions. This is there you have to concentrate > > your> attention. In most cases it is something like 2% of overall > > > application code. Describe, prototype, play with that bit and of the > > > day you will get -/+ 10% accurate planning. > > > - If in the past you have worked with much bigger systems, with huge > > > amount of data processing you can think like. This system is 5 times > > > smaller the system I have worked with. Presumably this system > > will run > > > successfully on 2-3 times smaller HW and we will spend 2 times less > > > time to tune it. > > > - If you have chance to get information about system like you are > > > going to implement (like OEBS, SAP, or other pre developed > > > application, or the same functional application, or old system you > > > going to replace), you can base your assumption on that information. > > > . > > > Later on then Developers will say you haven't enough HW capacity, > > you> would be able to base you conclusion on a comparison of the > > developed> application and other systems. > > > . > > > I don't think this approach is ideal, but at the moment I haven't > > found> better. > > > I would be glad to hear others opinion. > > > > > > Thank you in advance, > > > Jurijs > > > > > > > > > On 2/23/06, LiShan Cheng <exriscer@xxxxxxxxx> wrote: > > > > Hi > > > > > > > > I was wondering if anyone know any source about effective > > Oracle RDBMS > > > > Capacity Planning. I mean effective because in the past I have > > seen many > > > so > > > > called "Capacity Plan" which failed miserably in the practice. > > I am not > > > sure > > > > how can a DBA perform Capacity Planning without knowing much > > about the > > > > application? > > > > > > > > Cheers > > > > > > > > > > > > LSC > > > > > > > > > > > > > > > > > -- > > > Jurijs > > > +44 7738 013090 (GMT) > > > ============================================ > > > http://otn.oracle.com/ocm/jvelikanovs.html > > > > > > >