Re: Capacity Planning

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_at_gmail.com> 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_at_gmail.com> 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_at_gmail.com> 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
> >
>

--
http://www.freelists.org/webpage/oracle-l