What does the Infrastructure Agent Rule "Excessive Interrupts" mean? (4308012)

The excessive interrupts alarm does not detect the cause of the interrupts, the text suggests the possibility of a bad disk controller or network interface issue as a general description based on previous customer experience to help provide some guidance where to begin investigating an issue.An easy way to show where interrupts can come from is to explain how operating systems such as *nix, Linux or windows get data from the disks. Imagine a piece of code doing its thing, eventually the code gets to a point where it needs more data to process and needs to get this from the disk.  The code makes a system call asking for X bytes of data to be read from the disk.  The operating system translates the request for X bytes into instructions for the retrieval of N blocks of data from the disks and  into places the instructions on the disk controller and moves user process to a “waiting state” as it is waiting for the data to come back from the disk.  The operating system usually at this point give the CPU to another process which does not require I/O.  A number of milliseconds pass and the disk has got the data and sent it down the cable to the disk controller.  It promptly raises an interrupt to tell the operating system that the data has returned.  The processor calls the interrupt-handling routines of the operating system and (in this case) moves the data from the controller’s memory to the operating system’s buffers/cache.  If the read request was for 10 blocks of data, 10 interrupts will this be raised by this approach.

A number of operating systems record the count of interrupts that are raised.  Interrupt is usually caused by a time-sensitive event such as a read from the storage subsystem or network having been completed at which time the event that caused the interrupt needs to be dealt with, and so the hardware (usually) raises an interrupt which the CPU has to deal with by running the code associated with the interrupt.  So for the example of the read being completed, the interrupted CPU then calls the appropriate interrupt-handling routine of the operating system’s kernel and spends some time moving the data from the disk subsystem into the operating system’s buffers/cache.

A high level of interrupts is not in itself indicative of a problem and can be perfectly normal in a lot of systems’ architectures.

However interrupts generally require the operating system to spend processing the cause of the interrupt.  In fact some operating systems list the CPU time spent on processing interrupts (or rather on handling the event that caused the interrupt to be raised – in Linux the mpstat command displays this) separately from user-mode processing and system calls.

What can be indicative of issues is for a system in a steady state (i.e. where the workload does not change significantly in terms of load on the system or in its characteristics, especially I/O characteristics) to have a sudden increase in interrupts.  This is what the alarm’s message is referring to.  If everything has stayed the same and all of a sudden the interrupt count increases, that may indicate that an I/O device such as a disk controller or network card or HBA is causing spurious interrupts to be raised.