Re: [dtrace-discuss] tcptop error: failed to resolveSS_TCP_FAST_ACCEPT: Unknown variable name

Thanks - prustat works great once I point it at Sun's perl (I was using a newer install) I'm going to record some snapshots when the contention is happening... What if I wanted to quantify the latency (wait times) due to DNS lookups (I suspect I could benefit from a local caching install - but I

Re: [dtrace-discuss] tcptop error: failed to resolveSS_TCP_FAST_ACCEPT: Unknown variable name

On Mon, Jan 21, 2008 at 02:48:47PM -0800, Fletcher Cocquyt wrote: > Forgive me, where do I find 'interstat' ? > > Also, where can I get Sun::Solaris::Kstat for prustat? It's probably already under /usr/perl5/5.8.4/lib - it's a vendor (Sun) supplied package. prustat was written as a demo tool - i

Re: [dtrace-discuss] tcptop error: failed to resolveSS_TCP_FAST_ACCEPT: Unknown variable name

Forgive me, where do I find 'interstat' ? Also, where can I get Sun::Solaris::Kstat for prustat? [EMAIL PROTECTED]:~ 2:32pm 146 # perl -MCPAN -e 'install Sun::Solaris::Kstat' [snip] Fetching with LWP: ftp://ftp.perl.org/pub/CPAN/modules/03modlist.data.gz Going to read /export/home/fcocquyt/.

Re: [dtrace-discuss] tcptop error: failed to resolveSS_TCP_FAST_ACCEPT: Unknown variable name

On Mon, Jan 21, 2008 at 02:16:02PM -0800, Brendan Gregg - Sun Microsystems wrote: > On Mon, Jan 21, 2008 at 01:55:36PM -0800, Fletcher Cocquyt wrote: > > Followup - this system has a lot of kernel activity and I/O - (top typically > > shows CPU > 50% kernel) - but the hotkernel blorked with this (

Re: [dtrace-discuss] tcptop error: failed toresolve SS_TCP_FAST_ACCEPT: Unknown variable name

On Mon, Jan 21, 2008 at 02:17:46PM -0800, Fletcher Cocquyt wrote: > Replaced SS_TCP_FAST_ACCEPT with SS_DIRECT in tcptop per the thread you > cited - now I get a new error: > > [EMAIL PROTECTED]:~ 2:14pm 133 # ./tcptop > dtrace: failed to compile script /dev/fd/11: line 163: failed to resolve > `t

Re: [dtrace-discuss] tcptop error: failed to resolveSS_TCP_FAST_ACCEPT: Unknown variable name

On Mon, Jan 21, 2008 at 01:55:36PM -0800, Fletcher Cocquyt wrote: > Followup - this system has a lot of kernel activity and I/O - (top typically > shows CPU > 50% kernel) - but the hotkernel blorked with this (eventhough > load avg was only ~2 and command line is responsive): > > [EMAIL PROTECTED]

Re: [dtrace-discuss] tcptop error: failed toresolve SS_TCP_FAST_ACCEPT: Unknown variable name

Replaced SS_TCP_FAST_ACCEPT with SS_DIRECT in tcptop per the thread you cited - now I get a new error: [EMAIL PROTECTED]:~ 2:14pm 133 # ./tcptop dtrace: failed to compile script /dev/fd/11: line 163: failed to resolve `tcp_g_q: Unknown symbol name I got it from here: http://www.brendangregg.com/D

Re: [dtrace-discuss] tcptop error: failed to resolve SS_TCP_FAST_ACCEPT: Unknown variable name

G'Day, On Mon, Jan 21, 2008 at 01:39:03PM -0800, Fletcher Cocquyt wrote: > Hi, I am trying to debug the bottle neck(s) in a Solaris 10 > Mailman/Spamassassin/Sendmail VMWare VM and get the following error from > tcptop: > > [EMAIL PROTECTED]:~ 1:35pm 103 # ./tcptop > dtrace: failed to compile scr

Re: [dtrace-discuss] tcptop error: failed to resolveSS_TCP_FAST_ACCEPT: Unknown variable name

Followup - this system has a lot of kernel activity and I/O - (top typically shows CPU > 50% kernel) - but the hotkernel blorked with this (eventhough load avg was only ~2 and command line is responsive): [EMAIL PROTECTED]:~ 1:41pm 114 # ./hotkernel Sampling... Hit Ctrl-C to end. dtrace: processi

Re: [dtrace-discuss] tcptop error: failed to resolve SS_TCP_FAST_ACCEPT: Unknown variable name

On Mon, Jan 21, 2008 at 01:39:03PM -0800, Fletcher Cocquyt wrote: > Hi, I am trying to debug the bottle neck(s) in a Solaris 10 > Mailman/Spamassassin/Sendmail VMWare VM and get the following error from > tcptop: > > [EMAIL PROTECTED]:~ 1:35pm 103 # ./tcptop > dtrace: failed to compile script /dev

[dtrace-discuss] tcptop error: failed to resolve SS_TCP_FAST_ACCEPT: Unknown variable name

Hi, I am trying to debug the bottle neck(s) in a Solaris 10 Mailman/Spamassassin/Sendmail VMWare VM and get the following error from tcptop: [EMAIL PROTECTED]:~ 1:35pm 103 # ./tcptop dtrace: failed to compile script /dev/fd/11: line 40: failed to resolve SS_TCP_FAST_ACCEPT: Unknown variable name

Re: [dtrace-discuss] DTrace, Solaris 9, JVM

On Jan 21, 2008 2:58 PM, Z W <[EMAIL PROTECTED]> wrote: > Can DTrace be used with such a configuration or is DTrace only for Solaris > 10 ? DTrace is only for Solaris 10. Time to upgrade ;-) Rayson > > Thanks > ___ > dtrace-discuss mailing list > dtr

[dtrace-discuss] DTrace, Solaris 9, JVM

Hi Gurus Quick question. I have JVM 1.5 running with Solaris 9. Can DTrace be used with such a configuration or is DTrace only for Solaris 10 ? Thanks ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org

Re: [dtrace-discuss] LatencyTop

Perhaps the wording was a bit strong, and I apologize for that. I perhaps should have prefaced it with some kudos to the intel team for encouraging people to look at their systems as a whole, and measure such things. However I do stand by my assessment that it is way less than ideal to include ne

Re: [dtrace-discuss] LatencyTop

On Jan 19, 2008 9:04 AM, Colin Burgess <[EMAIL PROTECTED]> wrote: > Well I see that Brendan did reply to the OSNews link to this. He basically > shot them down at hardcoding the instrumentation - as he should have! :-) > > Shame on Intel - they should know better! > > Colin > I'm not a member of t

Re: [dtrace-discuss] LatencyTop

I don't think anyone disagrees that measuring latency is a bad idea. Note Brendan's comments in http://osnews.com/permalink?296801 "Encouraging customers to look at latencies for performance analysis is really important." ... "If this tool does get customer

Re: [dtrace-discuss] LatencyTop

On Jan 19, 2008 10:30 AM, Roman Shaposhnik <[EMAIL PROTECTED]> wrote: > On Fri, 2008-01-18 at 16:33 -0500, Colin Burgess wrote: > > I see Intel has released a new tool. Oh, it requires some patches to > > the kernel to record > > latency times. Good thing people don't mind patching their kernels,