On Thu, Feb 28, 2008 at 05:53:37AM -0800, Paul van den Bogaard wrote:
> Trying to get a script to run for an hour. Up till now every attempt failed
> before the hour was over. Latest command was:
>
> dtrace -q -x dynvarsize=16g -x cleanrate=400 -s /DTrace/newstr2.d
>
> growing that dynvarsize from 128m, 25, 512 and doubling. My system "only" has
> 64GB of RAM and still dtrace produces many of the following:
>
> dtrace: 1255 dynamic variable drops with non-empty rinsing list
> dtrace: 37907 dynamic variable drops with non-empty dirty list
> dtrace: 701859 dynamic variable drops
> dtrace: 1279 dynamic variable drops with non-empty rinsing list
> dtrace: 43404 dynamic variable drops with non-empty dirty list
> dtrace: 711953 dynamic variable drops
> dtrace: 3990 dynamic variable drops with non-empty rinsing list
> dtrace: 42116 dynamic variable drops with non-empty dirty list
> dtrace: 170163 dynamic variable drops
> dtrace: 9 dynamic variable drops with non-empty rinsing list
> dtrace: 8591 dynamic variable drops with non-empty dirty list
>
> With the 16g setting it takes about 20 minutes before the first of these
> messages is produced. After that it is producing them continuously.
I suspect that you might be seeing a bug that I ran into recently (and
for which I have a fix that I will be integrating soon). Are your
dynamic variables being allocated on one CPU and deallocated on another
by any chance? (You can determine this by modifying your script to aggregate
on CPU where you would allocate and deallocate a dynamic variable.) If
this is the case, you are likely running into the same issue that I ran
into -- the symptom of which is dynamic variable exhaustion regardless
of dynamic variable size and cleanrate...
- Bryan
--------------------------------------------------------------------------
Bryan Cantrill, Sun Microsystems Fishworks. http://blogs.sun.com/bmc
_______________________________________________
dtrace-discuss mailing list
[email protected]
