[HECnet] MONITOR DISK - Meaning of values

[Johnny Billquist]

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?
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.

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.
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?

	Johnny