Home | History | Annotate | Line # | Download | only in Notes 
      1 **************************************************************************
      2 * Notes for all scripts that trace Java using the hotspot provider.
      3 *
      4 * $Id: ALLjava_notes.txt,v 1.1.1.1 2015/09/30 22:01:09 christos Exp $
      5 *
      6 * COPYRIGHT: Copyright (c) 2007 Brendan Gregg.
      7 **************************************************************************
      8 
      9 * I see "drops"
     10 
     11 If you see the following output,
     12    
     13    dtrace: 2547 drops on CPU 0
     14 
     15 This means that JVM events (usually methods) were executed too quickly for
     16 DTrace to keep up, and as a safety measure DTrace has let events slip by.
     17 This means, at least, that the output is missing lines. At worst, the
     18 output may contain corrupted values (time deltas between events that were
     19 dropped).
     20 
     21 If you see drops, you should first ask yourself whether you need to be
     22 tracing such frequent events at all - is there another way to get the same
     23 data?  For example, see the j_profile.d script, which uses a different
     24 technique (sampling) than most of the other Java scripts (tracing).
     25 
     26 You can try tweaking DTrace tunables to prevent DTrace from dropping events.
     27 A key tunable is "bufsize", and can be set in scripts like so,
     28 
     29    #pragma D option bufsize=32m
     30 
     31 That line means that 32 Mbytes will be allocated to the DTrace primary
     32 buffer per-CPU (how depends on bufpolicy). If you have many CPUs, say 8,
     33 then the above line means that 256 Mbytes (32 * 8) will be allocated as a
     34 buffer while your D script is running. 
     35 
     36