Find why process uses 100% cpu.

[Richard Whalen]

$ @TCPWARE:TCPWARE_COMMANDS
$ NETCU SHOW CONNECTIONS
Will list active connections and their state.
If you don't see the BG device that your program is using, then that BG device doesn't have an active connection.

Note that a program that uses BG devices and uses the SELECT socket library call (and I believe that the RPC code does) will always have at least one BG device that does not have a connection associated with it. This BG device is used for the qiow that does the SELECT operation. (This is true for TCP/IP services, MultiNet and TCPware.)

[Volker Halle]

Edward,

the call stack shows various routines on the stack at the time you issued the SDA> CLUE CALL command.

There is a call to SYS$OPEN_C (called from the C runtime library), called from a routine in GTMSHR.

You would need to execute a couple of those SDA> CLUE CALL commands against the looping process and find out, which of the call frames are constantly shown on the stack. Then go to the highest frame (lowest Procedure Frame address), which shows a return address in your code (GTMSHR or other). When this call frame is ALWAYS on the stack of the looping process, you need to analyze the call made from that return address.

You need the map and the source listing (with machine code !) of the current version of that module for further analysis.

Based on the fact, that there is a SYS$OPEN call, this might give a hint...

Volker.

[Edward Alekxandr]

Thanks everyone for all your help.

I think i've traced the error to the following M code:

F D Q:DONE
. S S=L-$L(R),R=R_$E(XWBRBUF,1,S),XWBRBUF=$E(XWBRBUF,S+1,999999)
. I ($L(R)=L)!(R[$C(4))!(C>TO) S DONE=1 Q
. R XWBRBUF:2 S:'$T C=C+1 S:$L(XWBRBUF) C=0
. I $G(XWBDEBUG)>2,$L(XWBRBUF) D LOG^XWBDLOG("rd: "_$E(XWBRBUF,1,252))

When the process is run interactively rather than detached, I can step through the M code and it seems to loop rapidly through this at maximum throttle.


I'm going to have another look tomorrow, but I'm somewhat zombie-fied with flu today so thinking is out of the window.

[Jan van den Ende]

@John:


On an OpenVMS system, using 100% of a CPU means the process is compute bound, and no one else wants the CPU. The way the priority system works, your CPU hungry process will rapidly become a replacement for the Idle loop. Other processes should not be significantly affected.


Well, in these matters I usually consider you to be WAY better informed than I am, but this time I feel things are not exactly as you portray them.

As I have (regrettably) experienced all to often, in cases like this the process actually gets an interactive terminal IO request boost, which as soon as it is satisfied gets a re-boost, etc. Effectively tying up one CPU.
If you have several such (eg, Progress) processes, then as soon as "several" reaches "number of CPU's" it becomes VERY hard to take corrective measures!

The solution (ahh, call that workaround) for us was to enable Virtual Terminals, and have a (short) Disconnected Terminal process termination.

fwiw

Proost.

Have one on me.

jpe