similar to: Control-c

while trying to use the USDT made available to us in Postgresql database I have problems enabling them. On my database server I ran 1024+ PG processes (1024 clients). The server is a 8 core T2000 @1000MHz. 32GB. 7 storage arrays. Solaris 10 Update 4. Home compiled PG 8.3 beta 1 (optimized binary for T1 chip) with DTrace probes enabled. When running without enabling the probes I have approx 25%

Hi: I''m running Indiana (OpenSolaris developer preview) under parallels in OS X 10.5.1. I can consistently get Solaris to hang. Doing a dtrace -n pid\$target::malloc:entry''{@=count()}'' -c ls will consistently hang Solaris. Basically doing anything with PID provider with the -c option seems to hangs Solaris. Only way to recover is to stop and start Parallels desktop.

>From time to time a jboss process would end eating all, the available CPU and the load avg would skyrocket. Once the operators restarted jboss, the system''d be normal again (sometimes for weeks) until the next incident Since we moved the app from a v440 running Solaris 10 8/07 to a t2000 running Solaris 10 5/08 the problem started to happen more frequently (2-3 times a week). The

Hi, I''m working on some performance analysis with our database and it seems that when the file system (UFS) is mounted with forcedirectio, the IO probe are not triggered when an I/O event occurs. Could you confirm that ? If so, why ? Seb -- This message posted from opensolaris.org

I have a number of systems running solaris10 and i see the package and binary for dtrace installed however whenever we try to run anything we get this error dtrace: failed to initialize dtrace: DTrace device not available on system the only system in which i dont have this error is the development server that has the full solaris 10 install while others are minimized, do i need additional

everyone, Just out of curiosity, I did a dtrace -n ''syscall:::entry { @num[execname, probefunc] = count(); }'' and looked at the entries produced by ''rm''. I see everything that rm did, *except* the unlinkat - which is unfortunate because I want to trace which processes have deleted which files. So - does dtrace contain unlinkat as a probe for a system call?

What am I missing? [Download dvm.zip from https://solaris10-dtrace-vm-agents.dev.java.net/] [root at load0 /]$ mkdir /opt/dvm;cd /opt/dvm root at load0 dvm]$ unzip /home/jbuckley/dvm.zip [jbuckley at load0 ~]$ more /etc/release Solaris Nevada snv_45 SPARC Copyright 2006 Sun Microsystems, Inc. All Rights Reserved. Use is subject to

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

Hi, I have used dtrace in the past for diagnosing IO/filesystem related issues. So I am a bit familiar with dtrace scripts Now I want to diagnose performance problems in the java area. May be memory leak etc. The hotspot provider is not present. How can I get them? Does someone have any further advice? regards Hans -- This message posted from opensolaris.org

Hi All, I''ve got a problem when I have USDT probes in a static library and in the application code outside of the library. I build the static library containing some USDT probes, glomming everything together (ld -r) before creating the .a file to preserve the probe symbols. This all works fine. I build an application which also has some USDT probes. When I build the application which

Using the following dtrace command, I can see who''s calling what with lots of +/- numbers: dtrace -n ''fbt:ip:ip_output:entry{@dbtypes[((mblk_t *)arg1)->b_datap->db_type,caller] = count();}'' ...the output is what I want but not how I want to see it. What I''d rather see is the function names associated with caller and for db_type to be output in hex.

I have a program where the process seems to be sleeping a lot (waiting on something) What would be the right approach to figure out via dtrace where it is sleeping and why it is sleeping? In my current process, using truss -D shows that it reaches pollsys and the whole process sleeps for 1.5 - 1.8 seconds before it awakes again. Its the only significant process running on this two CPU

Hi all... I''ve just got my hands on a Solaris 10 box for the first time. I''ve heard wonderous things about dtrace, so the first command I type is dtrace -l which disappointingly does nothing at all. It just hangs, and neither Ctrl-D, Ctrl-C or kill -9 from another shell will do anything to kill it. The box is: SunOS t2000 5.10 Generic_118822-25 sun4v sparc SUNW,Sun-Fire-T200

Dear Experts, My customer is migrating to Solaris 10 from Solaris 8 and have asked me to determine if: With Dtrace, is the user limited to probing only processes they own? The customer has a general security requirement to control user access via management of privileges. Currently, on Solaris 8, LDAP is strongly while RBAC is weakly applied. This will likely change in the Solaris 10 production

Hi, Following "anonymous tracing" chapter, I wanna trace kmem_init(), but after reboot, I can''t get anything, why? Here is my short script kmem_init.d: #!/usr/sbin/dtrace -s fbt::kmem_init:entry { stack(); } then I just use: #dtrace -AFs kmem_init.d #reboot #dtrace -ae < got nothing here> Thanks, -Alex This message posted from opensolaris.org

Hi - I''m trying to use plockstat to help identify any mutex contention issues we may have in our c++ app. >From the docs it would appear to be a very useful tool - unfortunately in practice this doesn''t bear out purely because the stack traces produced are limited to being 39/40 characters wide. In general this means that I''m not seeing ~75% of each stack symbol and

Hello, everyone I am a newbie of DTrace and OpenSolaris. Just wondering is it possible to trace every memory read/write of a specific process given the pid? Basically speaking, I want to record the virtual addresses being accessed by the process, using which I will try to do some online analysis. If DTrace does not support this type of instrumentation, will other tools in OpenSolaris help me

[Perhaps someone could rename this list to dtrace-matt-problems-discuss?] If I run this script against my binary (which contains a USDT probe called ''concurrentq-latency''): ::: / probename == "concurrentq-latency" / { printf("[%s]:[%s]:[%s]\n", probeprov, probefunc, probename); } I get this output: dtrace: script ''testq.d'' matched 46056

I''m pleased to pass along news that the Mac OS X DTrace port has been updated in 10.5.3 to fix the issue that caused timer based probes not to fire in the presence of certain untraceable applications. http://blogs.sun.com/ahl/entry/apple_updates_dtrace A big thank you to the folks at Apple for addressing the problem. Adam -- Adam Leventhal, Fishworks

I''ve found what I think is a deadlock in the dtrace fork code. My only Solaris test machine is a single cpu box, where I have been unable to reproduce in the field so far. I''ve been able to reproduce on other platforms. Here is the scenario. You''ve got a target process, which has static probes. It is calling fork(), which causes it to end up at line 330 in fork.c: