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. > [EMAIL PROTECTED] > > > -----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: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
