cddl/contrib/dtracetoolkit/Notes/ALLjava_notes.txt

   1 **************************************************************************
   2 * Notes for all scripts that trace Java using the hotspot provider.
   3 *
   4 * $Id: ALLjava_notes.txt 52 2007-09-24 04:28:01Z brendan $
   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