G'Day Bob,

On Thu, Jun 26, 2008 at 07:40:28AM -0700, Bob Resendes wrote:
> [Just starting out with DTrace and was hoping to get some guidance.]
> 
> I have a "benchmark" program that I monitored with both prstat (prstat -mL -P 
> <PID>) and pfilestat (from the DTrace toolkit). Prstat reports LAT values in 
> the 0.1-0.2% range, but pfilestat reports "waitcpu" values in the 6-10%. 
> Since those two numbers supposedly represent time waiting for the CPU, I'm 
> wondering why they are so different for the same application (over the same 
> time period).

prstat -mL is giving a by-thread summary, which is going to be better than
either prstat -m, pfilestat, or anything else that tries to represent
multiple thread info by-process.

> On a side note, the pfilestat script (I think) assumes that a "read entry" 
> will be followed by a "read return" probe. On a per-thread basis, I can see 
> this happening, but if the application has multiple threads/readers/writers, 
> isn't it possible to get interleaved syscalls? For example,
> 
> Thread1-> read entry
> Thread2 -> write entry
> Thread1 -> read return
> Thread2 -> write return
> 
> If so, then shouldn't the pfilestat script be using thread local variables 
> for timing versus globabl variables?

Try it, and consider a multi-threaded app with a thread that keeps calling
sleep() for 10 seconds (or some interval greater than the summary).  You'd
want your profile:::tick-5s to walk the thread list to account for this
properly, but that involves loops - and DTrace doesn't do loops.  It doesn't
mean this is impossible to solve, just that it'll start getting difficult.
Representing this data by-process presents another challenge - how to
present data that will best identify performance issues.

I believe pfilestat was written as a demo of what is possible, and works
great in some situations but not others.  The docs should explain that -
sorry.  Perhaps the easiest fix would be to allow pfilestat to take an
optional tid as an argument; and document that it should be used when
analysing buly multi-threaded apps.

pfilestat is one of the longest of the 230+ scripts, if you are
starting out, it may be best to "ls -lrLS" in /Bin and start from the top.

Brendan

-- 
Brendan
[CA, USA]
_______________________________________________
dtrace-discuss mailing list
[email protected]

Reply via email to