similar to: New OpenSolaris Project: Mozilla DTrace

(Apologies to anyone who follows me on Twitter and therefore will have seen this multiple times already.) Joyent will be offering training in DTrace: Core Features and Performance Analysis trainer: Brendan Gregg <http://dtrace.org/blogs/brendan/> (San Francisco, Sept 6-7), Max Bruning <http://wiki.smartos.org/display/DOC/Max+Bruning> (Geneva, Sept 13-14) This course introduces

G''Day Folks, I''ve rewritten execsnoop, opensnoop and shellsnoop so that they are wrapped in the Bourne shell to provide command line options (they have all lost their ".d" extensions, but the old versions are still online). They are rather more meaningful tools now. (Eg, I can run shellsnoop with "-qp PID" with the PID of a shell, and see only the characters

Does anyone out there have any thoughts on the type of load common DTrace scripts would cause on a system if run 24x7? I know "common DTrace scripts" and their underlining probe calls a vague statement. So for the lack of a common and establish set of scripts in the OS, I''ll use the most popular right for my question...the DTraceToolkit from Brendan Gregg. Which by the

DTrace folks, I''m pleased to introduce a potential new DTrace-sponsored project: the Erlang DTrace provider. To be good OpenSolaris citizens, we want to put the formation of this officially sponsored project to a vote -- as outlined in the OpenSolaris Constitution -- so here are the details for the new Project, as prepared by the Project Team: Name : Erlang DTrace Integration

I use a lot of tabs and Firefox runs very slowly. I would like to figure out which tabs are eating up resources (cpu, memory, etc). Will the Mozilla dtrace framework be any help with this? -- This message posted from opensolaris.org

G''Day All, I''m putting together a PSARC case to begin integration of the DTrace network providers. I''ve drawn up a rough plan which splits this project into over a dozen smaller steps, as documented on the network provider page: http://www.opensolaris.org/os/community/dtrace/NetworkProvider#Plan Below is a draft PSARC document for task 1, IP provider send/receive

I have been using iosoop script (see http://www.opensolaris.org/os/community/dtrace/scripts/) written by Brendan Gregg to look at the IO operations of my application. When I was running my test-program on a UFS filesystem I could see both read and write operations like: UID PID D BLOCK SIZE COMM PATHNAME 203803 4436 R 6016592 16384 diskio <none> 203803 4436 W 3448432

As noted on my blog and at http://www.opensolaris.org/os/community/dtrace/shells/ I''ve made available a DTrace provider for the Bourne shell. Before anyone starts yelling at me for not starting with another shell, read the blog I made explaining why we started with shell (link on the community page referenced above). For /bin/sh, I''ve put up something akin to a chapter in

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

The open solaris dtrace page (http://www.opensolaris.org/os/community/dtrace/) has a bad link to the DTrace Guide(http://docs.sun.com/db/doc/817-6223). This message posted from opensolaris.org

All, With Jon Haslam''s exciting news about the DTrace doc wiki (if you haven''t seen it yet, make your way to http://wikis.sun.com/display/DTrace), and with some of the discussion with the Apple folks, I''m wondering if the time isn''t right for something of a DTrace summit, perhaps as an unconference. The idea here would not be a DTrace user group (though that

This came up as an RFE during the conference (I believe it''s been logged as "4012008: brendan() action needed for DTrace Toolkit".) As everyone here is aware, DTrace is not quite as user friendly as it could be. For the uninitiated, it can be confusing to run a DTrace script and not see the expected output. Brendan Gregg has addressed this in the DTrace Toolkit[1] by

X.Org has adopted GNU autoconf as its build configuration mechanism, so when I integrated the dtrace probes, I checked to see if they should be built using this test, checking for the existence of a program named "dtrace" in the path: dnl Check for dtrace program (needed to build Xserver dtrace probes) AC_ARG_WITH(dtrace, AS_HELP_STRING([--with-dtrace=PATH], [Enable dtrace

The earlier post with the Dtrace probes definition (sent on April 23) was only to solicit feedback from all prospective users of iSCSI DTrace probes. I will follow up shortly with an updated document requesting approval from the community. thanks Priya -------- Original Message -------- Subject: Dtrace provider for the COMSTAR iscsi Target Port Provider - Review Request Date: Thu, 23 Apr

I''m running OpenSolaris 2008.05 in VirtualBox on a Windows XP host. Playing around with various probes, I found that trying to load any probe associated with bdev_strategy dumps core. I can think of one or two likely and reasonable causes for this, but am assuming it''s undesirable behavior. Anyone know what''s happening here? -- This message posted from

Hi, As I''ve discussed before whenever we add USDT probes to a C++ function and call dtrace -l we get the mangled C++ name for the dtrace function, being listed :( Now the point of USDT probes is to abstract a higher level semantic construct for users to make use of. Surely it is not meant to be listing Unstable Interfaces (implementation details), such as the containing C++

Hi, This is a proposal for probes for NFS v3 client(see attachment). These probes are under a new DTrace provider: nfsv3client. These new probes support tracing NFS v3 client activities such as sending RPC requests to NFS v3 server and receiving RPC replies from NFS v3 server. Formats and arguments of these new probes are quite similar to existing NFS v3 probes on server side (provider: nfsv3).

Hi All, One of the customer is seeing the following error messages. He is using a S10U1 system with all latest patches. Dtrace script is attached. I am not seeing these error messages on S10U2 system. What could be the problem? Thanks, Gangadhar. ------------------------------------------------------------------------ rroberto at njengsunu60-2:~$ dtrace -AFs /lib/svc/share/kcfd.d dtrace:

Dtrace does work on some workstation, such as as follows, ----------------------------------------------------------- bash-3.00# dtrace -s ./mem.d `pgrep test` dtrace: script ''./mem.d'' matched 5 probes ^C bash-3.00# uname -a SunOS ftp 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Blade-100 bash-3.00# dtrace -V dtrace: Sun D 1.1

I sent this to Brendan but never got a response. Maybe someone else can help? ----- Hi Brendan. I''m trying to debug a problem where I need to snoop the network traffic over a punchin connection, where snoop doesn''t work. I found your tcpsnoop dtrace tool, which seemed like it might be able to do what I need. Unfortunately, it doesn''t seem to have an option to dump