Archive
Posts in DTrace
Measuring system call time with procsystime
When debugging application performance problems related to high system time, I typically start my analysis by watching the system calls the application is issuing, and measuring how much time is spent in each system call. Gathering this information is simple with DTrace syscall provider, and the DTraceToolkit comes with the procsystime script to allow admins to easily analyze system call behavior. To use procsystime to measure how much time the sshd proceses are spending in each system call, we can run procsystime with the "-T" option to get the total time spent in all system calls, the "-n" option, and the process name to analyze (in the example below, using the string "sshd" will cause procsystime to analyze the system call behavior for all processes named sshd): The output will contain the name of the system call in the left hand column, and the time spent in that system call in the right hand column. There are additional options to display the number of calls to each system call, and you can also filter by process id if you want to measure a specific process…
$ read more →Viewing busy code paths with DTrace
Periodically I want to see the busiest application and system code paths on a system. Prior to Solaris 10, this was a difficult questions to answer without custom instrumentation. Now that we have DTrace, we can use the DTrace profile provider and an aggregation to view the busiest code paths in the kernel: To see the busiest userland code paths, we can aggregate on the executable and userland stack frames, but only when we are in user context (arg1 indicates which context we are in): This is huge, and with two lines of DTrace, you can dynamically view the busiest code paths in kernel and user context. Nice!
$ read more →Debugging directory server issues with DTrace
Today while installing Sun's directory server, I kept getting the error "No components have been selected for installation in the selected directory" after selecting numerous components for installation: Directory Server components showing a checked box will be installed. Since I had previously installed the directory server on the machine, I started to wonder if the directory server had placed a package repository somewhere on the file system. To see if this was the case, I fired up opensnoop from the DTraceToolkit: Sure enough, there is a product registry file in /var/sadm/install. Once I removed it with rm: The installation went off without a hitch…
$ read more →Viewing utilization per file descriptor on Solaris 10 hosts
While load-testing a MySQL back-end last weekend, I wanted to be able to monitor read and write utilization per file descriptor. The DTraceToolkit comes with a nifty script named pfilestat that does just that: In addition to displaying the amount of data that is read from or written to each file descriptor, pfilestat also provides information on how much time is spent sleeping and waiting for I/O. This is yet another reason why the DTraceToolkit is da shiznit!
$ read more →Brendan Gregg amazes me again
I spent some time last night catching up with mailing lists, and saw that Brendan Gregg recently added DTrace SDT probes to one of the Javascript engines. If you don't know who Brendan is, he is a brilliant guy, and the author of the DTraceToolkit among other things. I always love reading about his work, and I find it interesting that he recently joined Sun Microsystems. Sun is extremely lucky to have such a great guy working for them, and I can't say enough about how much I respect Brendan and his work.
$ read more →