Performance monitoring?

[pll at lanminds.com]

In a message dated: Fri, 20 Dec 2002 09:52:53 EST
Michael O'Donnell said:

>I'm not sure I understand what you're trying to measure,

I want to know what percentage of time the disk is busy doing stuff.
Or, conversely, what percentage of time the disk is not doing stuff.

Here's the problem set.

I/We have this box being used as a black-box storage device.  We are 
trying to characterize it's over-all performance; from CPU 
utilization to disk IO, memory, swapping, etc.

Since most of the people I work with are hard-core storage engineers, 
one of the metrics they're used to is "disk busy time", that time 
that the disk is spent doing something, and therefore is unable to 
take more requests.

The interesting thing is that iostat will tell you how many requests 
per second were made, and how much data per second was transferred, 
but there is no correlation between the two; i.e. I know how many 
requests were made, but not the size of those requests.  Therefore, I 
have no idea what percentage of requests is represented by the amount 
of data transferred.

  mod> you might find it difficult to characterize certain behaviors
  mod> of your disk units if they have caches (pretty much all of
  mod> them do) that are enabled (pretty much all have them enabled
  mod> by default) because the caches will, to some extent, hide the
  mod> delays due to seek- and rotational-latencies.

Well, yes, I understand that, however at this level, I don't think 
it matters.  The OS should only care how fast it's requests are 
answered.  If the OS makes a request, and it gets blocked, then the 
disk is "busy".  On the other hand, if it makes a request, and gets 
and answer, the disk wasn't "busy".  Some answers are obtained faster 
than others, which might be attributable to cache hits, but the 
bottom line is, the disk wasn't busy when I made my request.

(btw, I too question the validity of such a number, but hey, that's 
what they asked me for, and they pay me, so I need to humor them :) 
-- 

Seeya,
Paul
--
Key fingerprint = 1660 FECC 5D21 D286 F853  E808 BB07 9239 53F1 28EE

	It may look like I'm just sitting here doing nothing,
   but I'm really actively waiting for all my problems to go away.

	 If you're not having fun, you're not doing it right!