Disk IO without doing IO's

[Wim Van den Wyngaert]

The disk IO's are also visible in mon disks.

Cas : no high water, bad. This is cluster with interbuilding shadowing.

Wim

[Wim Van den Wyngaert]

Did a show proc with lexicals of everything available via lexicals.

CPUTIM goes up with 1 ms every few seconds. No other data changed. Not sleeping after all.

Wim

[Uwe Zessin]

How can that be? The granularity of JPI$_CPUTIM is 10ms.

http://h71000.www7.hp.com/doc/73final/4527/4527pro_045.html#index_x_573

[Wim Van den Wyngaert]

Sorry Uwe, your right. It was per 10 ms.
But I did the test during a longer interval now.

CPU is sometimes frozen for some minutes, sometimes increases every few seconds.

PRI was reported on 4, 7, 8 and 9.

Did VPA sampling with interval 1 ms for the process. No samples were found when trying to report it.

Wim

[Uwe Zessin]

I would not try to make sense out of the CPU time data. It is possible to construct cases where a process is doing work, but does not get any CPU time charged - if I recall correctly, that only happens at quantum end processing. If you process gives up the CPU 'too early' you won't see an increase.

[Richard White_5]

Good Morning Wim...

This problem is "killing-me". For something that is relatively repeatable, I feel as though I should be able to come up with something that can help us further isolate.

As for the 1ms or 10ms cpu-time, I believe that the field in the "$sho proc/cont" will highlight days, hrs, min, sec, and "jiffies" which is a term from the old Tops_10/20 days. At any rate each "jiffie", while incrementing, by 1, is actually a 10 milli-second jiffie.

Typically, a user-process will receive a priority boost anywhere from one to six, after some sort of RSE, such as coming out of some sort of Wait-State, like HIB, LEF, etc. Since the "$sho proc/cont/id=xxxx" is executing "$getjpi" to that process on our behalf, the priority boost of 1, seems ok.

Sorry for not mentioning the the SDA commands for the process-stacks or call-frames.
SDA> show proc/in=xxxx
SDA> show stack/kern
SDA> show stack/use
SDA> show call
SDA> show call/next (repeat 10 to 15 times)
Hoping that we might be able to see the system-service calls for QIO...

Is it at all possible, that another user-process on the system is also executing the program "ipcdaemeon.exe" Perhaps you can execute "SDA> show summary/imag/thread" for us, after the stacks and call-frames.

Lastly, sorry about the "Good Morning" confusion, but that is my standard greeting regardless of the time-of-day or time-zone.

Thanx,
whynot3k

[Wim Van den Wyngaert]

I ran vtdpy on the hsg80 and mon dis in parallel.

vtdpy reports no thruput whatsoever on dsa4 while mon dis reports an average of 8 IO/s.

Richard : good afternoon (almost good weekend for most of us but I have to stay for another 4 hours). I'll lauch sda ...

Wim

[Wim Van den Wyngaert]

No other IPC programs active. I already checked that.

Here the SDA output.

Wim

[Willem Grooters]

"Once a minute", "freezing CPU", rings a few bells.
Could it involve some sort of "garbage collection"? I know of Java once used on my (too little) box quite regularly the system seemed freeze for i/o, and my system disk made weird grinding noises for a short time, after which the system did continue ias if nothing was wrong. Well, I know this IPCDAEMON.EXE is not a JAVA program, but doesn't C++ (or C) have a similar construction to control the heap?
Are any timers active (Timer Queue Elements in queue), since it seems to occur every minute - by the clock, so to speak - without intermediate CPU usage (HIB state)? (I guess 2, or 14? are in queue: given the other quota that are 500..). Worth looking at, probably.

Just another wild guess, I'm not sure whether it's possible on VMS, but I've seen elsewhere: A process allocating a number of diskblocks and use these as temporary space by direct access, directly connecting to the driver. I guess IO's are then counted but you won't see where it goes unless you know where to look in the execuatble.

Can you find out where these BG devices lead to? (TCPIP SHO DEV/FULL BGxxxx, where xxxx is any of the active devices). As is specified that TCPIP uses DMA as well, it _might_ be TCPIP-io is mistakenly presented as Disk IO. And since these devices are "busy" it might be the process is waiting for a signal. It could be helpful to know about these....

It might be a matter of commands, but I wonder about the open channels and RMS data.
On channel 40, there's IPCDAEMON.ERR;40, of which the RMS data is show. But of the two (adjacent) versions of IPCDAEMON.OUT on channels 20 and 70, I see no RMS data on these. Nor on what's openend on channels 00 and 80 (directories?)

[Wim Van den Wyngaert]

Willem,

The first BG is a listener.

The second is an active line to the same host and there is traffic when the application is doing something.

The third is a an active line to the other node of the cluster and there is traffic when the application is used on that other node.

The fourth is not a tcp socket and has 0 operations completed.

There is no data for the .OUT because everything is written to .ERR (but not that much). They opened sys$output twice.

On the subject of functionality : don't know but it's not that high tech.

Wim