Re: Capacity Planning

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_at_shaw.ca> 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_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