Wednesday, October 08, 2008
Ptime modifications
Late last year I made a proposal to make some modifications to ptime(1) (the full text of the proposal can be found in the second message here. The proposal includes links to the original RFEs.) There've been some bumps along the way, but the changes are soon going to be putback into Solaris. (Thanks, Rafael!)
When I made these changes, I was mostly just going through the list of open Solaris bugs looking for things to do, it wasn't something that I needed. I've recently found it to be an exceedingly useful tool, though, especially with the -m and -p options. For example, something's just not right with this particular process:
This is a case of misaligned memory accesses on a SPARC box, which is why all the time is showing up in trap. Here's another process in a bad way:
The cause of this aberrant behavior is probably good fodder for a later blog entry.
When I made these changes, I was mostly just going through the list of open Solaris bugs looking for things to do, it wasn't something that I needed. I've recently found it to be an exceedingly useful tool, though, especially with the -m and -p options. For example, something's just not right with this particular process:
# ptime -mp 3878 real 3:00:47.519957300 user 12:13.948207800 sys 37.210204400 trap 19:40.638837300 tflt 2.942089500 dflt 0.783120500 kflt 0.000000000 lock 5:29:23.879672500 slp 6:00:46.021626100 lat 17.081155000 stop 0.000081200 #
This is a case of misaligned memory accesses on a SPARC box, which is why all the time is showing up in trap. Here's another process in a bad way:
# ./ptime -mp 2715 real 106:51:30.161266600 user 4:28:49.022048500 sys 19:00:33.201052500 trap 0.047837500 tflt 0.051432200 dflt 0.038230200 kflt 0.000000000 lock 103:08:06.134729400 slp 299:24:41.087893200 lat 1:04:27.602323100 stop 2.913079800
The cause of this aberrant behavior is probably good fodder for a later blog entry.
