Boris,
I think I covered this in my response to Ryan. It was the "two stages"
part.
Note that you can avoid even using queueing theory at all if you just
make sure that utilization stays to the left of the knee in the
performance curve for each resource on the system. You can learn the
location of the knee for a given number of parallel service channels
(for example, CPUs in your case) on Table 9-3 on p260 of "Optimizing
Oracle Performance."
Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
Upcoming events:
- Performance Diagnosis 101: 12/16 Detroit, 1/27 Atlanta
- SQL Optimization 101: 12/8 Dallas, 2/16 Dallas
- Hotsos Symposium 2004: March 7-10 Dallas
- Visit www.hotsos.com for schedule details...
-----Original Message-----
Boris Dali
Sent: Sunday, December 07, 2003 12:39 PM
To: Multiple recipients of list ORACLE-L
Thanks for the clarifications, Cary.
With regards to a hardware sizing - how do LIOs fit
into queueing theory? Let's say I can come up with
something like:
#CPUs required = Sum( LIOs(Bus.Tx i)) /
(10,000*clock rate/100)
where i={Bus.Tx 1..n}
[on a projected box that haven't been bought yet, it
might be a little difficult to estimate the
denominator, ... and on the existing one I guess I
have to get hold of Jonathan's paper to learn how this
can be done]
..but in any event for forecasting purposes, how
queueing effect might be taken into account here?
Let's say I measured Sum( LIOs(...)) for a 50 users in
a unit testing environment and I am told that
production would be 10 times more than that, what do I
do?
Thanks,
Boris Dali.
- Cary Millsap <cary.millsap_at_hotsos.com> wrote: >
My answers are in-line, preceded with "[Cary
> Millsap]"...
>
>
> Cary Millsap
> Hotsos Enterprises, Ltd.
> http://www.hotsos.com
>
> Upcoming events:
> - Performance Diagnosis 101: 12/16 Detroit, 1/27
> Atlanta
> - SQL Optimization 101: 12/8 Dallas, 2/16 Dallas
> - Hotsos Symposium 2004: March 7-10 Dallas
> - Visit www.hotsos.com for schedule details...
>
>
> -----Original Message-----
> Boris Dali
> Sent: Sunday, December 07, 2003 9:54 AM
> To: Multiple recipients of list ORACLE-L
>
> Thanks a lot for the reply, Cary. Yes, your
> explanation makes all the sense in the world even
> though it is precisely the weighted average approach
> that I've seen on some capacity planning
> spreadsheets.
>
> Two additional questions if I may, Cary.
> Would it be correct to say that when I throw
> additional users on a system it is only queueing
> component of a response time that climbs up, while
> service time stays the same?
>
> [Cary Millsap] "Sort of," but not exactly. There are
> lots of scalability
> threats that begin to manifest in reality when you
> crank up the load.
> For example, you'll see "latch free" waiting on
> applications that parse
> too much, but only at higher user volumes (never in
> unit test). You can
> consider the new appearance of "latch free" events
> to be a type of
> queueing if you want, but it's really not queueing
> in the sense of a
> simple CPU queueing model.
>
> If that's true, than does
> it matter how I measure service time of my Bus.Tx1 -
> on a loaded system where hundreds of users run this
> operation or when nobody executes it all? Also is it
> important to have the other two operations - Bus.Tx2
> and Bus.Tx3 - running concurrently (as they would in
> a
> real life) for the c measurements?
>
> [Cary Millsap] You'll put yourself at risk if you
> simply try to use a
> queueing model to extrapolate big-system performance
> from data collected
> in a unit testing environment. It's because of the
> potentially
> out-of-model scalability threats.
>
> In other words assuming I have an identical replica
> of
> a production environment where I am the only user -
> would service time/rate measured there be applicable
> for a loaded system with heterogeneous workload?
>
> [Cary Millsap] ...Only if you your production
> environment doesn't
> trigger any new serialization issues that weren't
> visible on your unit
> test env.
>
> And another stupid question.
> Knowing individual business tx. characteristics
> (response time, number of CPUs required to comply
> with
> SLA requirements, average utilization per CPU, etc),
> how does one go about sizing the box in terms of the
> overall "system" required CPU capacity? Or put it
> another way - what do I tell a hardware vendor?
>
> That is, if what comes out of a queueuing exercise
> is:
> m pho
> -------- ---
> Bus.Tx1 2-way 70%
> Bus.Tx2 3-way 50%
> Bus.Tx3 4-way 80%
>
> What should be the optimistic (let's assume perfect
> liner CPU scalability for now) recommendation to
> decision makers in terms of the horsepower required
> to
> run this "system" on?
> After all, yes individual business transactions have
> their own SLA requirements (e.g. worst tolerated
> response time), but they all use the same resources,
> don't they? So even though a service time of Bus.Tx1
> might remain constant the queueing delay (and hence
> the response time) would likely to increase due to
> other concurrent activities on the system. Is there
> a
> way to account for this if capacity planning is done
> at the individual bus.tx level?
>
> [Cary Millsap] The hardest part about capacity
> planning is that there's
> no useful industry-wide standard unit of CPU work to
> use. You can't use
> MHz, you can't use MIPS, and you can't use SPECints,
> or anything else
> like that. But you can use Oracle LIOs. It's not
> hard to test a system
> to see how many LIOs/sec it can handle; this is your
> supply (capacity).
> It's also not hard to see how many LIOs/sec an
> application needs; this
> is your demand (workload). With this realization,
> capacity planning is
> much simpler. The game is to ensure that supply
> exceeds demand at all
> times, and by a sufficient amount so that you don't
> have unstable
> response times.
>
> [Cary Millsap] ...And, of course, as I mentioned
> previously, you have to
> keep your peripheral vision open for the possibility
> that some new
> scalability threat will manifest and surprise you.
>
>
> Thanks,
> Boris Dali.
=== message truncated ===
Post your free ad now!
http://personals.yahoo.ca
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Boris Dali
INET: boris_dali_at_yahoo.ca
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Cary Millsap
INET: cary.millsap_at_hotsos.com
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Sun Dec 07 2003 - 18:49:25 CST
