Oracle Press (McGraw-Hill), ISBN 0-07-2133788-3
On 2002.07.30 01:58 VIVEK_SHARMA wrote:
>
> Book "Oracle High-Performance Tuning with STATSPACK" by Don Burleson
>
> What is the PUBLISHER / Any Other Details ?
>
> Thanks indeed Dennis .
>
>
> -----Original Message-----
> Sent: Tuesday, July 30, 2002 3:24 AM
> To: Multiple recipients of list ORACLE-L
>
>
> Vivek - This sort of thing must be used with some intelligence. It is
> difficult to provide guidelines that work for all sites. Trending is
> very
> important. If a lightly loaded site that suddenly experiences high
> statistics, that may something that needs reviewed. Another site may
> always
> be highly loaded so the statistics may always look abysmal compared to
> the
> lightly loaded site. Time of day is also important. Ideally you
> collect
> statistics 24x7 and compare the trends to user events. And see how the
> statistics change over time. Trends are much more important than
> single
> statistics out of context. Don Burleson devotes several chapters to
> operating system indicators and trending in his book "Oracle
> High-Performance Tuning with STATSPACK".
> In the end, the critical measurement is user response time. If the
> users
> think performance stinks, then by definition it stinks. Perception is
> reality. Users don't care if the problem is with the network, the
> server,
> the Web server, the application server, or the database. If you have
> an
> opportunity to configure a test that simulates what the users see,
> that is
> ideal. Then when the users say that performance is bad, then you can
> show
> them your trend line. Those sort of facts saves a lot of argument. If
> your
> trend shows performance was bad, you will be inclined to check it out.
> Otherwise, the user may be convinced that it was their perception.
> Dennis Williams
> DBA
> Lifetouch, Inc.
> dwilliams_at_lifetouch.com
>
>
> -----Original Message-----
> Sent: Monday, July 29, 2002 2:48 AM
> To: Multiple recipients of list ORACLE-L
>
>
> Hi
>
> We are Trying to make a General Document to be forwarded to Customers
> which
> should allow them to know when they are performing far below normal
>
> At the Operating System Level we are trying to Identify Practical
> Critical Values which when below respective Threshold Limits which
> would give the alert about a potential problem .
>
> We are Looking for these in Areas of :-
>
> 1) Network Thruput
> 2) Memory Utilization
> 3) Swap Utilization
> 4) IO Utilization
>
> Would apreciate actual Commands used (preferably those Generic across
> different O.S.) & respective Critical Threshold Limit Values for the
> Above
>
> EXAMPLE For Network thruput Between APPLICATION Server machine &
> Database
> Server Machine
> what , by experience , are the parameters & their respective Minimum
> threshold Values which would let us know that there is a Severe
> problem
> therein ?
>
> NOTE - We have generally been measuring this by Manually ftping a Big
> File , about 100MB , between APP & DB Server machines , noting the
> thruput
> Displayed in (kbytes/s) on Completion & Converting this Value to Mega
> Bits /
> Second
> (i.e. MBPS) . If this Value is Less than 40MBPS for a 100 MBPS Cable
> we
> know there is a PRoblem with Network Bandwidth.
>
> Miscellaneous - Some Threshold Limits known to us :-
>
> Command - vmstat 5 3
> Virtual Memory Statistics: (pagesize = 8192)
> procs memory pages intr
> cpu
> r w u act free wire fault cow zero react pin pout in sy cs
> us sy
> id
> 3 1K 34 266K 84K 32K 811M 132M 339M 635 193M 0 188 28K 1K
> 16 7
> 77
> 3 1K 33 267K 84K 32K 410 71 151 0 131 0 494 2K 4K
> 4 2
> 93
> 3 1K 36 269K 82K 32K 5459 1720 807 0 3016 0 471 3K 4K
> 37 5
> 58
>
>
> 1) Utilization of CPU due to Operating System (Internal) Operations
> (%sy)
> Exceeding Utilization due to user Applications (%us)
>
> 2) Average Wait of CPU for IO to Complete (%wio) Greater than (>) 30
> % [
> From
> sar Command ]
>
> 3) Utilization of CPU due to Operating System (Internal) Operations
> (%sy) >
> 30 %
>
> 4) CPU Utilization - If Total CPU Utilization Consistently Near 0%
> Idle Or further Coupled with any of the following :-
> a)Abnormally High Wait for IO ( > 30 %) [ From sar Command ]
> b)Abnormally High Operating System CPU Utilization ( > 30 %)
> c)Abnormally High Run Queue ["r" > (3 * Number of CPUs)]
>
> THANKS
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: VIVEK_SHARMA
> INET: VIVEK_SHARMA_at_infosys.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> 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).
>
--
Mladen Gogala
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Mladen Gogala
INET: mgogala_at_adelphia.net
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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 Tue Jul 30 2002 - 01:23:18 CDT
