[HECnet] MONITOR DISK - Meaning of values

[Brian Schenkenberger, VAXman-]

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.