arunthomas
commented
7 years ago @ivonchyk Using the -w problem may help with the first problem. More details here: https://blogs.oracle.com/jonh/entry/the_dtrace_deadman_mechanism
For the second problem, it certainly seems like there's a bug in the buflimit implementation. I can take a look early next week if @gvnn3 doesn't find time.
gvnn3
copied from original email about issue:
When I instrument too many probes causing a large numbers of drops with a command like
sudo dtrace -q -o /dev/null -s print/256mb_probes.d -x bufsize=63m -x buflimit=25 -c "sh wget_256mb.sh"
dtrace reports a large number of drops followed by "dtrace: processing aborted: Abort due to systemic unresponsiveness". In my understanding, this is a response to DTrace consuming too many resources.
When I ran a script (see below for code) that would call a dtrace command causing the above mentioned process aborting multiple times in a row, the machine that I was running the script on would crash and require a reboot. When I ran the process-aborting dtrace commands several times in a row manually, the machine did not crash, however...
script code:
!/bin/sh
ki=25 for k in
seq 1 2doecho "Running with buflimit = ${ki}" sudo dtrace -q -o /dev/null -s print/1gb_probes.d -x bufsize=63m -x switchrate=128hz -x buflimit="${ki}" -c "sh wget_1gb.sh" 2>&1 | tee -a "buflimit_test_outputs/result.${ki}.txt"
echo "sleeping" sleep 5 sudo dtrace -q -o /dev/null -s print/1gb_probes.d -x bufsize=63m -x switchrate=128hz -x buflimit="${ki}" -c "sh wget_1gb.sh" 2>&1 | tee -a "buflimit_test_outputs/result.${ki}.txt"
echo "sleeping" sleep 5 sudo dtrace -q -o /dev/null -s print/1gb_probes.d -x bufsize=63m -x switchrate=128hz -x buflimit="${ki}" -c "sh wget_1gb.sh" 2>&1 | tee -a "buflimit_test_outputs/result.${ki}.txt"
ki=$(($ki + 25))
done