1N/A**************************************************************************
1N/A* Notes for all scripts that trace Java using the hotspot provider.
1N/A*
1N/A* $Id: ALLjava_notes.txt 52 2007-09-24 04:28:01Z brendan $
1N/A*
1N/A* COPYRIGHT: Copyright (c) 2007 Brendan Gregg.
1N/A**************************************************************************
1N/A
1N/A* I see "drops"
1N/A
1N/AIf you see the following output,
1N/A
1N/A dtrace: 2547 drops on CPU 0
1N/A
1N/AThis means that JVM events (usually methods) were executed too quickly for
1N/ADTrace to keep up, and as a safety measure DTrace has let events slip by.
1N/AThis means, at least, that the output is missing lines. At worst, the
1N/Aoutput may contain corrupted values (time deltas between events that were
1N/Adropped).
1N/A
1N/AIf you see drops, you should first ask yourself whether you need to be
1N/Atracing such frequent events at all - is there another way to get the same
1N/Adata? For example, see the j_profile.d script, which uses a different
1N/Atechnique (sampling) than most of the other Java scripts (tracing).
1N/A
1N/AYou can try tweaking DTrace tunables to prevent DTrace from dropping events.
1N/AA key tunable is "bufsize", and can be set in scripts like so,
1N/A
1N/A #pragma D option bufsize=32m
1N/A
1N/AThat line means that 32 Mbytes will be allocated to the DTrace primary
1N/Abuffer per-CPU (how depends on bufpolicy). If you have many CPUs, say 8,
1N/Athen the above line means that 256 Mbytes (32 * 8) will be allocated as a
1N/Abuffer while your D script is running.
1N/A