locked
SDK-based Management Pack causes 100% CPU utilization for HealtService.exe RRS feed

  • Question

  • We developed an MP that uses SDK to create SCOM objects and insert a large number of performance counters ~ 2000 every 5 minute interval.

    On SCOM side the MP has about 2000 instances of UnitMonitor (only ~20 per class but there are lots of  actual objects). In these monitors we use 

    DataSource based on Microsoft.SystemCenter.TargetEntitySdkPerformanceDataProvider. All worked fine for a year but lately added a bunch of new objects/counters and CPU utilization for the MonitoringHost.exe started to spike to 100% a few seconds after the Performance Counters were posted via SDK. The spike lasts for up to 3 minutes. No DB or Network spikes observed. We suspect SCOM does not deal efficiently with SDK Performance data - as if a separate SdkPerformanceDataProvider is started for every UnitMonitor when the counters are posted rather than having cooked-down - one per Target instance.

    Can anyone shed some light on this? I suspect only the Microsoft engineers would know.

    Our environment is like this:

    • SCOM 2012 R2 UR4
    • Windows Server 2012 8 Core, 16 GB Ram

    Thanks,

    Dave




    • Edited by dmtr2000 Friday, December 5, 2014 12:58 AM Correction
    Thursday, December 4, 2014 8:43 PM

Answers

  • Hi Dave,

    is there a way that you can reduce the number of performance insertions? Regardless of even fixing the performance issue, the impact from a database standpoint may be something to consider in the long term. My point is that fixing one issue, will take us to the next one, etc etc.

    I would reduce the number of insertions, only to the either insertion of the "most critical" or "top #". Also, aren't those counters already captured out of the box?

    hth

    Jose

    • Marked as answer by Yan Li_ Friday, December 19, 2014 1:43 AM
    Monday, December 15, 2014 2:46 AM

All replies

  • I will involve some engineer who is more familiar with this topic, there may be some delay, thanks for your time.

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Friday, December 12, 2014 12:00 PM
  • Hi Dave,

    is there a way that you can reduce the number of performance insertions? Regardless of even fixing the performance issue, the impact from a database standpoint may be something to consider in the long term. My point is that fixing one issue, will take us to the next one, etc etc.

    I would reduce the number of insertions, only to the either insertion of the "most critical" or "top #". Also, aren't those counters already captured out of the box?

    hth

    Jose

    • Marked as answer by Yan Li_ Friday, December 19, 2014 1:43 AM
    Monday, December 15, 2014 2:46 AM