[dtrace-discuss] dtrace wired issue

Aubrey Li
Tue, 15 Jan 2008 02:13:11 -0000

On Jan 14, 2008 10:46 PM, Bryan Cantrill <bmc at eng.sun.com>
wrote:
>
> On Mon, Jan 14, 2008 at 09:16:34PM +0800, Aubrey Li wrote:
> > On Jan 14, 2008 8:52 PM, Sean McGrath - Sun Microsystems Ireland
> > <sean.mcgrath at sun.com> wrote:
> > > Aubrey Li stated:
> > > < Every first time to run dtrace command after the system boot
up,
> > > < It takes a very long time to get response.
> > > < But the second time is OK, as follows:
> > > <
> > > < # time dtrace -l > /dev/null
> > > <
> > > < real    4m8.011s
> > > < user    0m0.116s
> > > < sys     0m2.420s
> > >
> > >   This first time is probably when the kernel is loading the
dtrace modules.
> > >   Though still seems slow, 4 minutes.
> > >     What kind of system (cpu speed etc) is the machine ?
> >
> > # psrinfo -vp
> > The physical processor has 2 virtual processors (0 1)
> >   x86 (GenuineIntel 10674 family 6 model 23 step 4 clock 2400 MHz)
> >         Intel(r) CPU                  @ 2.40GHz
> >
> > So, I failed to understand the modules loading needs 4 minutes.
>
> Yes, this is definitely fishy.  Is this a highly memory constrained system?

# prtconf -vp | grep Mem
Memory size: 2023 Megabytes

> If you "modunload -i 0" enough times to get dtrace(7D) unloaded
(that
> is, "dtrace" doesn''t appear in modinfo), does it again
take 4 minutes?
> As you can imagine, it''s a little tough to investigate this
problem because
> we can''t use DTrace to do it! ;)

This doesn''t work on my side. modinfo always shows me
"dtrace".

>
> > > < # time dtrace -l > /dev/null
> > > <
> > > < real    0m0.632s
> > > < user    0m0.075s
> > > < sys     0m0.553s
>
> And 600+ milliseconds is still a long time.  How many probes are we talking
> about here?

# dtrace -l | wc -l
   52604

-Aubrey