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