[dtrace-discuss] Dynamic variable drops when using dtrace to monitor IO performance

2008-02-05 Thread Russ
Hi; I'm trying to track I/O performance of an application accessing a solid state storage device which should have sub 15us latencies...I was looking at using iosnoop from the dtrace toolkit, as iostat is no use at this level of granularity. Unfortunately, the app is very I/O heavy and after

Re: [dtrace-discuss] Missing syscall provider probes for unlinkat(2) and friends?

2008-02-05 Thread James Carlson
Peter Memishian writes: The problem is really in the distinction between section two of the man pages (the historical system call interface) and the real OpenSolaris system call interface that dtrace exposes as syscall. Dtrace syscall isn't the same thing as man page section two,

Re: [dtrace-discuss] i know it

2008-02-05 Thread vattini giacomo
Thank you,Installing Solaris in Virtual Pc,would it be,good or has no sense? -- This message posted from opensolaris.org ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org

Re: [dtrace-discuss] Dynamic variable drops when using dtrace to monitor IO performance

2008-02-05 Thread Chip Bennett
1) Decrease the number of probe events that get recorded by being more restrictive in what you ask iosnoop to do 2) Increase the size of the DTrace switch buffer using a D pragma. You'll have to modify iosnoop. 3) Increase how often the switch buffer switches using a D pragma. Again, you'll

Re: [dtrace-discuss] Dynamic variable drops when using dtrace to monitor IO performance

2008-02-05 Thread Chip Bennett
[EMAIL PROTECTED] wrote: Chip; 1) Is hard as all I/O is actually from one process, to one disk, so little to filter on 23) I will try playing with bufsize and switchrate (is cleanrate relevant here?) Not from what I can see. Chip ___

Re: [dtrace-discuss] Missing syscall provider probes for unlinkat(2) and friends?

2008-02-05 Thread Peter Memishian
I mostly agree with that ... I just think that effort is what Adam was referring to as putting lipstick on a pig. My understanding of the rationale is that it's better to have access to a raw, undoctored syscall interface when you really need it, than to have a prettified interface