Solved! Re: Lots and lots of system time

[Harald Hanche-Olsen]

[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.

- Harald