From brendan.gregg at tpg.com.au Sat Mar 12 14:50:31 2005 From: brendan.gregg at tpg.com.au (Brendan Gregg) Date: Sun, 13 Mar 2005 09:50:31 +1100 (EST) Subject: [DTrace] socketsnoop.d - TCP by PID Message-ID: G'Day Folks, Well, I had a weekend home in Sydney while inbetween flights and have knocked out a few programs. (I've been programming for 23 hours straight, so if there is something really dumb in one my scripts then please excuse me :) # socketsnoop.d UID PID DIR SIZE CMD 0 19886 W 64 ssh mars 0 19886 R 80 ssh mars 0 19915 W 0 finger @mars 0 19915 W 2 finger @mars 0 19915 R 633 finger @mars 0 19915 R 0 finger @mars 0 19886 W 64 ssh mars 0 19886 R 80 ssh mars 0 19886 W 48 ssh mars 0 19886 R 80 ssh mars 100 4789 W 6 vncviewer mars:4 100 4789 R 348 vncviewer mars:4 100 4789 W 10 vncviewer mars:4 I set a goal of TCP, and now have socketsnoop.d working for any TCP protocol I've thrown at it, including telnet. There is a variety of fbt and mib probes to pick from, none of them are simply perfect, many run asynchronously to the responsible process. James Dickens has been helping out from an IRC forum - IRC seems like it might be really useful for us to team up in. Well, it especially helps me as I'm thousands of miles away! :) socketsnoop.d is on my website at, http://www.brendangregg.com/DTrace/socketsnoop.d cheers, Brendan From brendan.gregg at tpg.com.au Sat Mar 12 15:06:22 2005 From: brendan.gregg at tpg.com.au (Brendan Gregg) Date: Sun, 13 Mar 2005 10:06:22 +1100 (EST) Subject: [DTrace] %CPU, %Mem, %Disk and %Net by PID Message-ID: G'Day Folks, Well, this one was my white whale. I now have a demonstration program that uses Perl, Kstat, /proc/*/usage, /proc/*/psinfo, and DTrace. The program itself is more of a prototype, I want to get serious about it and rewrite it in C. It currently has output like, # prustat -t5 -snet 10 PID %CPU %Mem %Disk %Net COMM 90 0.00 0.09 0.00 0.00 syseventd 443 0.00 0.13 0.00 0.00 snmpd 102 0.00 0.00 0.00 0.00 picld 10096 0.00 0.35 0.00 0.00 bash 445 0.00 0.00 0.00 0.00 dtlogin PID %CPU %Mem %Disk %Net COMM 22554 0.00 0.00 2.83 11.76 rcp 22553 0.00 0.00 2.43 11.47 rcp 4789 1.17 0.45 0.00 0.20 vncviewer 440 4.89 45.39 0.00 0.00 Xsun 90 0.00 0.09 0.00 0.00 syseventd PID %CPU %Mem %Disk %Net COMM 4789 0.82 0.45 0.00 0.02 vncviewer 12047 0.01 0.13 0.00 0.01 rlogin 440 8.94 45.39 0.00 0.00 Xsun 12046 0.00 0.27 0.00 0.00 rlogin 90 0.00 0.09 0.00 0.00 syseventd ^C Wheee, I can see rcp's %Net and %Disk! (oh, and it probably died too soon before I /proc/*/psinfo pr_pctcpu'd it. Not to worry, if it missed sampling then it would be unlikely to have had huge values there anyway (especially considering pr_pctcpu's averaging algorithm over time))).... It's on my dtrace site (http://www.brendangregg.com/DTrace/prustat). It can also do a prstat style of refresh output, and other stuff. # prustat -h prustat ver 0.50, demo release USAGE: prustat [-cehinuwxz] [-p PID] [-s sort] [-t top] [interval] [count] prustat # %Utilisation prustat -i # + I/O stats prustat -u # + USR/SYS times prustat -x # + Context Switchs prustat -c # Clear screen prustat -w # Wide output prustat -z # Skip zero lines prustat -e # Extra precision prustat -p PID # this PID only prustat -s sort # sort on pid|cpu|mem|disk|net|utime|vctx|... prustat -t lines # print top number of lines only eg, prustat 2 # 2 second samples (first is historical) prustat 10 5 # 5 x 10 second samples prustat -t 8 10 5 # 5 x 10 second samples, top 8 lines only prustat -ct 20 5 # 20 lines with screen refresh each 5 seconds prustat -iuxct 5 10 # multi output, all reports every 10 seconds prustat -ct 22 -s cpu 5 # 22 lines, sort by cpu, every 5 secs prustat -ct 22 -s mem 5 # 22 lines, sort by mem, every 5 secs prustat -ct 22 -s net 5 # 22 lines, sort by network, by disk, every 5 secs ... My performance obsession also led me to write sysperfstat last night/morning, $ sysperfstat 1 ------ Utilisation ------ ------ Saturation ------ Time %CPU %Mem %Disk %Net CPU Mem Disk Net 23:41:01 3.00 79.41 0.00 0.00 0.00 0.00 0.00 0.00 23:41:02 32.00 79.69 1.29 8.40 0.00 0.00 0.00 0.00 23:41:03 55.00 80.12 25.15 65.40 0.00 0.00 0.01 0.00 23:41:04 63.00 80.42 22.02 82.53 0.00 0.00 0.01 0.00 23:41:05 82.00 80.64 44.74 84.22 0.00 0.00 0.07 0.00 23:41:06 88.00 80.85 41.31 86.41 2.00 0.00 0.05 0.00 23:41:07 74.00 81.04 48.37 86.16 0.00 0.00 0.05 0.00 23:41:08 75.00 81.06 74.18 84.34 3.00 0.00 0.24 0.00 23:41:09 47.00 80.78 18.59 82.96 0.00 0.00 0.00 0.00 23:41:10 13.00 80.64 0.00 18.79 1.00 0.00 0.00 0.00 but that's only Kstat so it's not as cool. :) Brendan [Sydney, Australia] From oss at cvele.net Thu Mar 17 10:33:59 2005 From: oss at cvele.net (oss at cvele.net) Date: Thu, 17 Mar 2005 13:33:59 -0500 (EST) Subject: [DTrace] Dtrace in OpenSolaris? Message-ID: <24666.66.250.5.198.1111084439.squirrel@ns1.astrahosting.com> Hi, I have a problem with dtrace in the latest Software Express (Nevada nv_07 X86) booted into the latest OpenSolaris kernel (SunOS lokrum 5.10.1 tonic-clone-i386..24-Feb-2005 i86pc i386 i86pc). A simple script like # dtrace -n 'syscall:::entry {@[probefunc] = count() }' returns the following error message: bash-3.00# dtrace -n 'syscall:::entry {@[probefunc] = count(); }' dtrace: invalid probe specifier syscall:::entry {@[probefunc] = count(); }: "/usr/lib/dtrace/procfs.d", line 312: operator . cannot be applied to type "struct sem *"; must be applied to a struct or union It seems as if some files were not updated for Nevada. What shall I do? TIA, Dragan -- Dr Dragan Cvetkovic, To be or not to be is true. G. Boole No it isn't. L. E. J. Brouwer From mws at eng.sun.com Thu Mar 17 11:45:40 2005 From: mws at eng.sun.com (Michael Shapiro) Date: Thu, 17 Mar 2005 11:45:40 -0800 (PST) Subject: [DTrace] Dtrace in OpenSolaris? In-Reply-To: <24666.66.250.5.198.1111084439.squirrel@ns1.astrahosting.com> from "oss@cvele.net" at "Mar 17, 2005 01:33:59 pm" Message-ID: <200503171945.j2HJjeSm205190@poptart.sfbay.sun.com> > > Hi, > > I have a problem with dtrace in the latest Software Express (Nevada nv_07 > X86) booted into the latest OpenSolaris kernel (SunOS lokrum 5.10.1 > tonic-clone-i386..24-Feb-2005 i86pc i386 i86pc). > > A simple script like > > # dtrace -n 'syscall:::entry {@[probefunc] = count() }' > > returns the following error message: > > bash-3.00# dtrace -n 'syscall:::entry {@[probefunc] = count(); }' > dtrace: invalid probe specifier syscall:::entry {@[probefunc] = count(); > }: "/usr/lib/dtrace/procfs.d", line 312: operator . cannot be applied to > type "struct sem *"; must be applied to a struct or union > > It seems as if some files were not updated for Nevada. > > What shall I do? > > TIA, Dragan > You have mismatched CTF information (this is the symbolic type information that DTrace and MDB use to understand kernel types). Did you download the binaries you are running from somewhere or did you build them yourself? If you downloaded them, from where? If you build them, did you do a full nightly or an incremental build? With what changes? -Mike -- Mike Shapiro, Solaris Kernel Development. From keith.wesolowski at sun.com Thu Mar 17 12:03:27 2005 From: keith.wesolowski at sun.com (Keith M Wesolowski) Date: Thu, 17 Mar 2005 12:03:27 -0800 Subject: [DTrace] Re: [Opensolaris-bugs] Dtrace in OpenSolaris? In-Reply-To: <24666.66.250.5.198.1111084439.squirrel@ns1.astrahosting.com> References: <24666.66.250.5.198.1111084439.squirrel@ns1.astrahosting.com> Message-ID: <20050317200327.GA14397@sun.com> On Thu, Mar 17, 2005 at 01:33:59PM -0500, oss at cvele.net wrote: > I have a problem with dtrace in the latest Software Express (Nevada nv_07 > X86) booted into the latest OpenSolaris kernel (SunOS lokrum 5.10.1 > tonic-clone-i386..24-Feb-2005 i86pc i386 i86pc). This is a known problem; please see point 10 of the current release notes, as well as https://www.opensolaris.org/pipermail/code/2005-March/000043.html and https://www.opensolaris.org/pipermail/code/2005-March/000044.html. Unfortunately the archives of the original problem report seem to be missing. -- Keith M Wesolowski "Sir, we're surrounded!" Solaris Kernel Team "Excellent; we can attack in any direction!" From oss at cvele.net Thu Mar 17 12:10:43 2005 From: oss at cvele.net (oss at cvele.net) Date: Thu, 17 Mar 2005 15:10:43 -0500 (EST) Subject: [DTrace] Hostid bug? (was Re: Dtrace in OpenSolaris?) In-Reply-To: <24666.66.250.5.198.1111084439.squirrel@ns1.astrahosting.com> References: <24666.66.250.5.198.1111084439.squirrel@ns1.astrahosting.com> Message-ID: <42941.66.250.5.198.1111090243.squirrel@ns1.astrahosting.com> > > Hi, > > I have a problem with dtrace in the latest Software Express (Nevada nv_07 > X86) booted into the latest OpenSolaris kernel (SunOS lokrum 5.10.1 > tonic-clone-i386..24-Feb-2005 i86pc i386 i86pc). > Btw, the same kernel returns hostid as 000000 (don't remember how many of them). If I boot the standard snv_07 kernel (i.e. SunOS lokrum 5.10.1 snv_07 i86pc i386 i86pc), hostid works fine. Is that another problem with OpenSolaris source or is it me miscompiling it? Thanks and bye, Dragan P.S. To Mike: I have installed Solaris express 2/05 here and then downloaded the latest kernel from OpenSolaris.org (20050226) and run full nightly on it. The only thing switched off was debugging. However, I didn't do any BFU-ing. -- Dr Dragan Cvetkovic, To be or not to be is true. G. Boole No it isn't. L. E. J. Brouwer From rmilkowski at task.gda.pl Wed Mar 30 04:18:57 2005 From: rmilkowski at task.gda.pl (Robert Milkowski) Date: Wed, 30 Mar 2005 14:18:57 +0200 Subject: [DTrace] dtrace_dof_maxsize Message-ID: <16710452322.20050330141857@task.gda.pl> Hello dtrace, IMHO it should be in official DTrace documentation on docs.sun.com and BigAdmin. -- Best regards, Robert mailto:rmilkowski at task.gda.pl From rmilkowski at task.gda.pl Wed Mar 30 04:52:13 2005 From: rmilkowski at task.gda.pl (Robert Milkowski) Date: Wed, 30 Mar 2005 14:52:13 +0200 Subject: [DTrace] Arguments in PID provider Message-ID: <1368822644.20050330145213@task.gda.pl> Hello dtrace, args[] does not work with PID provider and only arg0-9 are available. How can I access more then first 10 arguments? -- Best regards, Robert mailto:rmilkowski at task.gda.pl From ahl at eng.sun.com Thu Mar 31 09:27:24 2005 From: ahl at eng.sun.com (Adam Leventhal) Date: Thu, 31 Mar 2005 09:27:24 -0800 Subject: [DTrace] Arguments in PID provider In-Reply-To: <1368822644.20050330145213@task.gda.pl> References: <1368822644.20050330145213@task.gda.pl> Message-ID: <20050331172724.GE8955@eng.sun.com> Hey Robert, Good question. It's kind of tricky and it will change depending on the ISA, but you can do it. sparc 32-bit: this->argN = *(uint32_t *)copyin(uregs[R_SP] + sizeof (uint32_t) * (N + 17), sizeof (uint32_t)); (only applies to args past the first 6) sparc 64-bit: this->argN = *(uint32_t *)copyin(uregs[R_SP] + 0x7ff + sizeof (uint64_t) * (N + 16), sizeof (uint64_t)); (only applies to args past the first 6) x86: this->argN = *(uint32_t *)copyin(uregs[R_SP] + sizeof (uint32_t) * (N + 1), sizeof (uint32_t)); amd64: this->argN = *(uint64_t *)copyin(uregs[R_SP] + sizeof (uint64_t) * (N - 5), sizeof (uint64_t)); (only applies to args past the first 6) If you run into any problems with those let me know. One tricky thing about amd64 is that the compiler seems free to use as much or as little of the 64 bits allotted to each argument so if you pass an int, the first 32-bits will contain the value of the 32-bit int, and the upper 32-bits will be garbage. Of course, you can just cast the value to an int, but it's a pitfall to watch out for. We're working on getting the args array working for the pid provider and we'll consider allowing more than just 10 args. Adam On Wed, Mar 30, 2005 at 02:52:13PM +0200, Robert Milkowski wrote: > Hello dtrace, > > args[] does not work with PID provider and only arg0-9 are > available. How can I access more then first 10 arguments? > > -- > Best regards, > Robert mailto:rmilkowski at task.gda.pl > > _______________________________________________ > DTrace mailing list > DTrace at opensolaris.org > https://www.opensolaris.org/mailman/listinfo/dtrace -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl