none
Higher than normal processor interrupts

    Question

  • Every one of my VMs that I were created through a P2V are experiencing higher than average processor interrupts. They are usually in the 3-8% range, but sometimes will hang around 13-15%. The VMs in question aren’t hitting the processor very hard and it’s not a big concern for such small utilization. This happen even in safe mode (without networking.)

     

    The problem I have is that I have 2 servers running a Siemens Engineering software package that have been hanging. Both of the applications are completely different products.  Both of them worked very well on the hardware they were P2V from.  I eventually had to go back to the old hardware on one of the machines.

     

    When the machine hangs, they are almost completely unresponsive. I can ping them. The virtual console of them freezes and allows for no user input. Click on something may try to refresh that part of the screen a few minutes later. PerfMon shows a blank period during the outage. Process Explorer on the other hand, using System Information, shows the hardware interrupts pegged at 100%.  During this same period of time, I/O and memory usage remains normal.

     

    The downside of all this is that I had to go back to stable machine, meaning the hardware box.  I still have the VM, but it has not seen the 100% utilization since pulling it from production.

     

    MY QUESTION:

    What’s causing the consistent hardware interrupts. They happen on every single machine that I have converted (using SCVMM with Hyper-V R2.) Finding what is causing that may lead me to why those same boxes are pegged in the processor at 100% once the app goes back to production.

     

    I know I am leaving out details, but this is already a long post. Please comment for more details.

     

    I've had a ticket in with MS for about a month now with no help, besides them telling me is suppose to work like that and there is nothing wrong. All I really want is to find out what is causing the interrupts and a way to stop it.

    Wednesday, April 07, 2010 3:40 PM

Answers

  • This post is older than 30 days or we have not heard back from you.  Did this issue get resolved?  If so, please share with community how you resolved.  Otherwise, re-activate post if you still require assistance.


    Carmen M. Summers (MSFT) --Posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, June 24, 2010 12:03 AM
    Owner

All replies

  • Hiya,

    You might want to try and use the process monitor tool in order to pin point whats causing this.

    http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

    Wednesday, April 14, 2010 7:15 AM
  • We also have the same issue with a P2V VM.  It has high hardware interrupts in Process excploer. and the server is slow.  krview pointed to intelppm.sys and hal.sys, but disabling intelppm did not help.  processor.sys was already disabled.  The lgons to the machine are slow.   server sluggishness appears to come and go through the day. 

    It is a 2003 server that went through a P2V migration.  I did find that disabling Trend Micro Offiescan made the sluggishness go away.  Do you also run Trend Micro antivirus?  I disabled the tmproxy service and it seemed to help a little, but not totally.

     

    Josh

    Thursday, April 15, 2010 5:28 AM
  • Jesper, I've been using Process Explorer from the beginning. The process is listed under interrupts, and that is about as far as it gets. The one thing helpful I got out of it was that the system information tab seemed to log data even when perfmon locked up under High CPU load. The history shows the Hardware interrupts that consistenly in the 3-5% rang spiking to >90%. Perfmon just displayed blank data.

    Josh, It sounds like you've been down the exact path I followed. Disabling the *.sys and all. We are using Trend.  I dismissed it when the problem was happening in safe mode as well. Come to think of it, Trend does load a kernal driver. Since the HAL changed on the machine during the P2V migration, that might just be it exactly. I'll pull it off and let AutoPCC reconfigure it.

    Thanks for the response guys

    Friday, April 16, 2010 2:40 PM
  • Just restarted after removing Trend and I am still seeing consistent hardward interupts.
    Monday, April 19, 2010 3:01 PM
  • Jesper, I've been using Process Explorer from the beginning.


    Process Monitor and Process Explorer is not the same thing :) - you might be able to get some further details using the Process Monitor rather than the Process Explorer.

    Tuesday, April 20, 2010 7:36 AM
  • This post is older than 30 days or we have not heard back from you.  Did this issue get resolved?  If so, please share with community how you resolved.  Otherwise, re-activate post if you still require assistance.


    Carmen M. Summers (MSFT) --Posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, June 24, 2010 12:03 AM
    Owner
  • Hello All,

    I have had this issue in my environment, and it somehow was related to TripWire. Java.exe which is the process used by Tripwire was taking about 11% of the whole CPU, but it was also trigger interrupts process which was taking up to 50% and LSASS.exe process which was taking about 40% of CPU.

    it was really confusing, because machine was a VM and it shouldn't have any Hardware issue. MS wasn't able to help me in this matter so after a month or so we was able to finally find the root cause which was the Tripwire.

    i have searched almost every post about this issue with no luck. i would've not guessed it is a TW related issue simply TW's process Java.exe consumes the CPU by 11%.

    BSman,,, i guess you should check the SWs recently added, and i would strongly recommend you to check the connections at the machine by netstat -no command and see if there are any connections in TIME-WAIT or CLOSE-WAIT which normally indicates  a network issue! if there is any check corresponding PID. then check the process causing this. Please also note one or two entries of Time-wait or close-wait is a normal situation. 

     

     

    Sunday, May 22, 2011 8:16 AM