Interrupt Mode Time is High??

[Jorge Cocomess]

As I was scanning the log on my HP Availability Manager console and I saw this message "interrupt mode time is high". What is the meaning of this? Does anyone here ever experienced this warning before?

As you can tell, I'm a newbie to the VMS world.

Running ES45 - OpenVMS 7.3-2 ECO 2

Thanks,
J

[Phillip Thayer · Accepted solution]

What is the alarm threshold for the interrupt time set to on you AV? It could be that it is simply set too low for your system. That's the simple answer.

More likedly you need to look at some performance tuning. Is this system clustered? If so what kind of cluster traffic is being done on it (MONITOR SCS, MONITOER DLOCK). Look in the SYS$SYSTEM:MODPARAMS.DAT and see if there are any changes to the SCS parameters. If possible comment them out and run

@SYS$UPDATE:AUTOGEN SAVPARAMS TESTFILES FEEDBACK

Look at the SYS$SYSTEM:AGEN$PARAMS.REPORT and see if the SCS parameters will be lowered. If so then run the same command above but substitute the TESTFILES with REBOOT and see if the interrupt time reduces.

If the system is clustered then check the MSCP_BUFFER size and make sure it is the same as the other systems in the cluster. This can cause fragmented data transfers in a clustered environment and run the interrupt time up.

Look at http://h71000.www7.hp.com/doc/73final/6491/6491pro_014.html#index_x_551 to do more indepth performancxe tuning.

HTH.
Phil

[Volker Halle]

Jorge,

OpenVMS counts interrupt mode usage, when the system is executing code as a result of a hardware or software requested interrupt.

The interrupt load depends mostly on your workload and what the system is doing in terms of IOs. When interrupt mode time is viewed as 'high' greatly depends on interpretation and observation of the system during 'normal' load.

I would start to try to find out, what's causing this 'high interrupt mode time'. Start with $ MONI SYSTEM, $ MONI MODE and determine the Interrupt State in relation to Direct and Buffered I/O rate.

Volker.

[Hein van den Heuvel]

This system is not in a cluster is it? If it was, then one potential reason for high interupt time coudl be distributed lock management, notably lock tree movements.

As replied earlier, it could be a reporting threshold problem. If your system is doing 'just fine' simply doing more (tcp) networkactivity then the rule anticitpate. If so, don't worry, change the threshold and be happy.

An important input to that decision is of course whether anything changed. Wat changed/when?
If the message started to appear after slowy increasing load over years, then just be grateful for the early warning of a potential performance problem and take it from there. If you recently installed a new (version of a) product/patch , then clearly try to understand whether it is to do with that.

More likely the message is to be taken as an indication of excessive interupts. Poor network tuning, excessive transmission error, excessive disk IO cached by controllers where perhaps you can tune for more caching in the system itself (xfc, rms global buffers, deferred write..)

Or maybe something to do with Alignment faults?

As you google for +vms +"interrupt time", be sure to also hit on 'alignment faults' and learn how to trace/report that.

There was an old Decus presentation for which you may find the slides (I did not see them readily).
"Tuning: Analyzing High Kernel/Interrupt Time
Presenter: James Mehlhop"

Finally, please share with us what was deemed excessive, in proportion to the other cpu modes.

Hth,
Hein.

[Stanley F Quayle]

This seems to have been given at DECUS San Diego in 1999. Any chance of posting the slides or providing a link?