RE: wio above 20% - is that high?

Excellent advise of course, but I think another question to ask is why do you care? It may be that you think the "system" is slow, a process is slow, or you may just be concerned with what the number means. I would suggest that the first two are performance concerns and that you should heed Cary's advice. If however, you're simply concerned about the number then I would suggest that you consider the problem from a workload perspective. In other words, have I exceeded the capacity of my machine? To answer this, you might investigate the "rates" at which your system is doing work. If you find that you're workload is approaching your capacity then you'll have two responsible choices, reduce workload or increase capacity.

Andy Rivenes
arivenes_at_llnl.gov

At 06:35 AM 12/2/2004, Cary Millsap wrote:
>Susan,
>
>One way I'd encourage you to think about your question is to ask:
>
>- Is there *any* circumstance under which a really high value might be
>acceptable (or perhaps even desirable)?
>
>- Is there *any* circumstance under which a really low value might be
>unacceptable?
>
>I haven't thought your particular question through to the end, but in my
>experience, every time I've ever analyzed a question of your question's
>format in this way, I've discovered that there is NO threshold that can =
>be
>counted upon to indicate even the presence or absence of a problem. When =
>you
>can't even reliably tell whether there *is* a problem or not, then you
>certainly can't use the metric to measure anything about *how* good or =
>bad a
>problem might be. I've found every system-wide utilization metric I've =
>ever
>analyzed to lead me to the same dead end (including the database buffer
>cache hit ratio, various latch miss ratios, the %sys CPU ratio, various =
>I/O
>rates, index vs full-scan break-even ratios, even system-wide average
>response time).
>
>Every time I've done the analysis I'm suggesting, I've found the same
>conclusion: stop looking at derivative metrics like system-wide =
>utilization
>rates, and start looking at what really matters: response times of
>individual, prioritized business tasks.
>
>
>Cary Millsap
>Hotsos Enterprises, Ltd.
>http://www.hotsos.com
>* Nullius in verba *
>

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