Solved! Re: Lots and lots of system time
hanche at math.ntnu.no
Sat Nov 26 08:13:10 PST 2011
[Brandon Allbery <allbery.b at gmail.com> (2011-11-26 15:46:34 UTC)]
> On Sat, Nov 26, 2011 at 08:42, Harald Hanche-Olsen <hanche at math.ntnu.no>wrote:
> > syscall::connect*:entry
> > syscall::connect*:return
> I wonder if there's a better way to do that, in particular avoiding the
> wildcards; I would suspect it ends up waking up on *every* syscall to do
> the glob, which on a system-wide basis will be extremely expensive no
> matter how much it's optimized.
My understanding is that wildcard matching is done only when dtrace
starts. It should create just four probes:
; sudo dtrace -l -n 'syscall::connect*:'
ID PROVIDER MODULE FUNCTION NAME
840 syscall connect entry
841 syscall connect return
1462 syscall connect_nocancel entry
1463 syscall connect_nocancel return
> Also, I would try to limit what processes
> are getting traced.
That would defeat my purpose, which was to track this globally to find
out if processes are making unexpected TCP connections. I know, there
is an application to do that: Little Snitch. I just thought dtrace
could do the same job.
> DTrace isn't magic; if you hook a critical path system-wide (and
> they don't come much more critical than the syscall provider),
> you''re going to feel it.
Right, but I think it's claimed to be magic, at least in the sense
that it will not impact anything other than the targets you are
probing. You're supposed to be able to use dtrace on a production
server under heavy load to pinpoint any performance problems. That is
a major reason for having created dtrace in the first place, as far as
I am aware. So I am still surprised.
More information about the macports-users