MONITOR DISK - Meaning of values - HECnet

16 Sep 2015

Johnny Billquist <bqt at softjar.se> writes:

...
 On 2015-09-16 13:34, Brian Schenkenberger, VAXman-
wrote:
  Sampsa Laine <sampsa at mac.com> writes:

  On 16 Sep 2015, at 11:46, Brian Schenkenberger,
VAXman- =
 <system at TMESIS.COM> wrote:

  Sampsa Laine <sampsa at mac.com> writes:
 =20
> I'm running a batch job that is creating a large (82 GB) file and =3D
> monitoring the system with MONITOR DISK.
> =20
> The value I'm getting is 39 - what does this actually mean, what is =  the
=3D
 > unit that is being monitored?
 =20
 =20
 I'm assuming you did not specify /ITEM.  =46rom the MONITOR HELP:
 =20
     When the /ITEM qualifier is omitted, the default is =  /ITEM=3DOPERATION_RATE.
  	:
 	:
        OPERATION_    Specifies that I/O operation rate statistics are
        RATE          displayed for each disk.
 =20
 What's you concern, if any? 
 Yes, I did this but the operation rate does not give me an indication of =
 how many block/second are beyond read/written, or does it? 
 It's a performance metric that is maintained in/by VMS about the number of I/O
 operations to the disks.  Maintaining block counts would be more/only meaning-
 ful on a per-disk basis.  That's generally not something that's a performance
 metric.

 This is a very simple procedure to get you a block/second count.  Put this in
 a file (BLOCKS_PER_SECOND.COM, for example) and execute it with the disk name
 in question. (ie. $ @BLOCKS_PER_SECOND DKA100)

 $ 100$:	BLOCKS_THEN = F$getdvi(P1,"FREEBLOCKS")
 $	WAIT ::01
 $	WRITE SYS$OUTPUT BLOCKS_THEN-F$getdvi(P1,"FREEBLOCKS")	! THEN - NOW
 $	GOTO 100$ 
Wouldn't that just show a delta of how many blocks have been allocated? 
That do not really correspond to I/O throughput.

That said, what does the monitor operation_rate tell? Is it QIOs, disk 
blocks, disk requests, or something else? 
Think $QIOs.  There's also the queue length /ITEM.  That would show the $QIOs
that are queued but have not yet been processed.

...
 If it would actually be disk blocks, then Sampsa can
indeed deduce I/O 
rates from it, since we know the size of a disk block.
However, QIOs can cover many disk blocks, and so can I/O requests. 
Correct.  It's overall disk statistics; not individual disk statistics.

...
 While I'm at it - a slightly different question. On
a VMS system (VMS 
7.3 on a VAX), I now have like hundreds of telnet connections that are 
in a SUSP state. This have gone so far that I cannot establish any more 
connections to the system. I have no idea what people/probes/robots have 
been doing, but it seems TCP/IP or telnet daemon in VMS 7.3 have some 
issues. 
Hmm.  What version of TCPIP?

$ TCPIP SHOW VERSION

...
 But my first question is, how do I get rid of all these
processes? Do I 
have to kill each one, giving the PID, or is there some better way of 
getting this unstuck? 
Generally, process SUSPension is voluntary.  Something had to tell the process
to SUSPend itself.  If there was a process "idling", waiting for I/O activity,
it would generally wait in LEF (Local Event Flag) wait state.

Can you send me a "$ SHOW SYSTEM" output of this too?  From there, we can look
to see why it's SUSpended (some SDA work will ensue).  It very well may be an
issue that has already been addressed with TCP/IP (eg. some TCP/IP bug that's
placing processes into SUSPended state when the connection terminates).  Are
these TELNET connection initiated via somebody TELNETting into the system? Or,
are these reverse telnet established sessions?

I need to dash out.  My wife is having surgery in a week and I must take her
to hospital today for pre-surgery tests.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.