I have a situation that I would like to debug with dtrace, but I am not sure how. I have a process that kicks off, runs for a few seconds (perhaps milliseconds) then goes away. And this happens very frequently, think old-school CGI based web app. And just for a little more fun, this app makes extensive use of shared libraries. How can I use dtrace? I don''t have an existing process to attach the pid provider. I could use the pid$target stuff, but that would linvolve modifying the system to kick off the processes with dtrace -c. This would be possible, but painful. And, it would mean I would have to use a post-processing step should I want/need to aggregate results from multiple processes. Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20091203/2d09685b/attachment.html>
On Thu, Dec 3, 2009 at 10:07 PM, Kevin Fitch <kfitch42 at gmail.com> wrote:> I have a situation that I would like to debug with dtrace, but I am not sure > how. > > I have a process that kicks off, runs for a few seconds (perhaps > milliseconds) then goes away. And this happens very frequently, think > old-school CGI based web app. And just for a little more fun, this app makes > extensive use of shared libraries. > > How can I use dtrace? I don''t have an existing process to attach the pid > provider. > > I could use the pid$target stuff, but that would linvolve modifying the > system to kick off the processes with dtrace -c. This would be possible, but > painful. And, it would mean I would have to use a post-processing step > should I want/need to aggregate results from multiple processes. >You could do what I call the "DTrace two-step": have one DTrace script catch the exec-success probe firing, predicated on "execname =foo", stop the process and kick off a second DTrace script (via system()) that uses the pid provider. Something like this: exec-success / execname == "myapp" / { stop(); system("other-d-script -p %d", pid); } This might not do what you want, though, given that you want to aggregate data from multiple instances of this app inside DTrace. Another trick you could use is to always start that app via a DTrace script that specifies the probes of interest. (This script is essentially a throwaway whose only purpose is to enable these probes.) You can then have a second DTrace script already running (using the -Z flag) that wildcards the pid in these probes, e.g., "pid*::malloc:entry". The -Z flag will let this script start, even though it matches nothing. As probes are enabled when the app runs, the pre-existing wild-carded probe specifications will also match, so the data collection specified in your second script will occur as you want. For example, if you wanted to keep track of the total amount of memory allocated via malloc(3C) by all the instances of your app, you could start the app every time with this script using "dtrace -c": pid$target::malloc:entry { /* I don''t care about collecting data. */ this->foo = 4; } You''d then have the following script already running (don''t forget the -Z): pid*::malloc:entry / execname == "myapp" / { @a[pid] = sum(arg0); } HTH, Chad
On Thu, Dec 03, 2009 at 10:07:03PM -0500, Kevin Fitch wrote:> I have a situation that I would like to debug with dtrace, but I am not sure > how. > > I have a process that kicks off, runs for a few seconds (perhaps > milliseconds) then goes away. And this happens very frequently, think > old-school CGI based web app. And just for a little more fun, this app makes > extensive use of shared libraries. > > How can I use dtrace? I don''t have an existing process to attach the pid > provider.Take a look at "dtruss" in the Dtrace toolkit: http://www.brendangregg.com/DTraceToolkit-0.99.tar.gz It will monitor a process by name and the process doesn''t need to exist when you invoke dtruss. I use this for transient process debugging.
On Thu, Dec 3, 2009 at 10:07 PM, Kevin Fitch <kfitch42 at gmail.com> wrote:> I have a situation that I would like to debug with dtrace, but I am not sure > how. > > I have a process that kicks off, runs for a few seconds (perhaps > milliseconds) then goes away. And this happens very frequently, think > old-school CGI based web app. And just for a little more fun, this app makes > extensive use of shared libraries. > > How can I use dtrace? I don''t have an existing process to attach the pid > provider. > > I could use the pid$target stuff, but that would linvolve modifying the > system to kick off the processes with dtrace -c. This would be possible, but > painful. And, it would mean I would have to use a post-processing step > should I want/need to aggregate results from multiple processes. >Is this a production system? If not, you could predicate on firings of cfork:create to catch the process you wanna look at. Rafael
Rafael Vanoni wrote:> On Thu, Dec 3, 2009 at 10:07 PM, Kevin Fitch <kfitch42 at gmail.com> wrote: >> I have a situation that I would like to debug with dtrace, but I am >> not sure >> how. >> >> I have a process that kicks off, runs for a few seconds (perhaps >> milliseconds) then goes away. And this happens very frequently, think >> old-school CGI based web app. And just for a little more fun, this app >> makes >> extensive use of shared libraries. >> >> How can I use dtrace? I don''t have an existing process to attach the pid >> provider. >> >> I could use the pid$target stuff, but that would linvolve modifying the >> system to kick off the processes with dtrace -c. This would be >> possible, but >> painful. And, it would mean I would have to use a post-processing step >> should I want/need to aggregate results from multiple processes. >> > > Is this a production system? If not, you could predicate on firings of > cfork:create to catch the process you wanna look at.Sorry, make that proc:::create. I''m not sure how much this would impact a production system, I guess it depends on your workload. But you might be able to get away with it. Rafael