YakShaving: Shawn Ferry's Weblog
v. intr. [MIT AI Lab, after 2000: orig. probably from a Ren & Stimpy episode.] Any seemingly pointless activity which is actually necessary to solve a problem which solves a problem which, several levels of recursion later, solves the real problem you're working on.
Archives
« July 2009
SunMonTueWedThuFriSat
   
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
       
Today

 Subscribe

Search

Links
 

Today's Page Hits: 151

Locations of visitors to this page
« OpenSolaris PowerPC... | Main | CEC: RBAC Demystifie... »
20061006 Friday October 06, 2006
CEC: Dtrace Approaches to Real-World Problems

Jim Fiori

Apparently the presentation is normally a 3+ hour presentation and Jim requested 3 hours, but all the slots are 60min.
This is a presentation on approach not learning D.
This entry is a horrible hack job on content, too much and I am learning more than I
can easily condense/digest usefully on the fly.

INTRO

Everyone needs dtrace...but it is not the first thing to run.
Identify a possible issue use Dtrace to figure out what is going on.
Advice: Practice, Practice, Practice

Approach

use the manual all examples are in /usr/demo/dtrace
use quantize(), min()/max()/avg() can hide data

Be careful using the PID provider it can impose load on a highly active process.

Normal system tools still have their place.

New tools: intrstat (some others I haven't used)

Privs -- Root level or RBAC...

Zero Probe Effect -- via instruction replacement

Scenarios

High User Time
hotuser.sh dtrace toolkit

C++ Apps
Watch for small allocations and short allocations

High System Calls (>100s)
use aggregation
use pfiles to determine target of File descriptor

System time (>10% or user:sys near 2:1)
prsatst to find it, dtrace to examine it

Threaded App.
prstat to find it
plockstat ... to see it, single process
Java
use jstack
Java 1.6 has static dtrace providers

Oracle
Look at I/O and File systems first
ONLY after regular investigation by DBA (statspack etc)

Sybase
Watch for TCP Nagle (buffering requests before sending)
Try TCP no delay on client and server

File system

Watch for periodic pauses check autoup in large memory (>8G) systems


Hints and Tools

Coming

Technorati Tags: ,


Oct 06 2006, 02:41:28 PM EST Permalink

Comments:

Post a Comment:

Comments are closed for this entry.
Blog Information Profile for YakShaving