On 06/02/09 18:30, tester wrote:
Jim,
Thanks. You are right, I was using the specopen.d, but looking for fork
errors instead of open. I did not know that probe has to fire before
predicate gets evaluated. It now makes sense for 40% increase in load
during dtracing. I would like to see the code path during a fork
failure (and ultimately the reason), do you have any suggestion without
incurring a significant overhead. We have an application that forks
around 1000+ processes in 5-10 seconds and occassionaly the fork fails.
I am think it is from lack of VM, but also have a feeling that there are
some hardcoded limits in the kernel. There was plenty of RAM available
duiring the fork failure.
I'd suggest you look at speculations - commit the speculation on fork
failure, discard it on success.
HTH
Michael
--
Michael Schuster http://blogs.sun.com/recursion
Recursion, n.: see 'Recursion'
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
