Hi (ummm, Tester?) -
First and foremost, what's the errno on the fork failure?
99% of the time, the errno information is enough to figure out
why forks are failing.
Second, make sure you look in /var/adm/messages - if fork
is failing because of a system resource issue, you'll often
get a syslog message that tells you what's wrong.
You really should not need to generate a kernel function call
trace to root-cause the failure of any system call, including fork.
It's like using an MRI and studying the resuling film when the
problem is a small cut that just needs some disinfectint and
a band-aid. You're looking much deeper than you need to.
Thanks,
/jim
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.
Thanks
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
