Skip to content
adatum
  • Home
  •  About adatum
  •  Learn Azure Bicep
  •  SCOM Web API
System Center Opertations manager logo Operations Manager

SCOMpercentageCPUTimeCounter cause CPU Spike

  • 13/03/2017
  • by Martin Ehrnst

To be honest this have existed for years, and written about back in 2014. Now, in 2017, SCOM 2016 UR2 is released the problem remains. Perhaps with greater consequence due to virtualization.

If you’re unfamiliar with the problem SCOMpercentageCPUTimeCounter.vbs (.ps1 in SCOM 2016) is a script included in the “System Center Core Monitoring” management pack, and is used as the data source for a rule and a monitor to determinate agent health by gathering ‘HealthService’ CPU usage. The rule and monitor are set to run at a fixed interval of 321 seconds (I assume the person who wrote the MP just tapped 3-2-1 on their numpad 🙂 ) and sync time set to 00:00

 

[supsystic-tables id=1]

If you want to look at the actual code you will find  the data source on SystemCenterCore.com

 

Running this script every 5 minutes isn’t exactly a problem when you have physical servers or a small amount of virtual machines on your Hypervisor. But if you run 100 or 300VM’s on one host and each single VM start this script simultainiasly it will create it creates unnecessary load on your host. If this host is overcommitted as well CPU wait time could cause a ‘freeze’ on your tenant machines as well.

To illustrate the problem, I have attached a graph, that clearly show spikes during script execution.

vcenter host cpu spike SCOM

 

On a monitored computer you will see a cscript.exe process executing the following command line “c:\windows\system32\cscript.exe” /nologo “SCOMPerventageCPUTimeCounter.vbs

Cscript.exe running SCOM Cpu percentange script

 

Unfortunately out of the box there isn’t much to do. Sync time and interval is the only overridable parameters, and these will only help reduce the load on the agent machine itself. So if you experience CPU utilization peaks due to this script, I see only two options

  • Disable the rule and monitor
    • Then you will have to rely on the CPU utilization monitor from the operating system management pack
  • Create a new rule and monitor, using SpreadInitializationOverInterval parameter
    • Reduces load as executions occurs randomly within the set interval
    • Requires authoring skills, but possible. Some information here.

 

To not let this go into oblivion, I have left feedback on Operations Manager user voice. Hopefully, Microsoft will make some changes in the future. If you have suggestions or other experience please let me know and i will update accordingly.

Share this:

  • LinkedIn
  • Twitter
  • Reddit
Operations Manager

HealthServiceStore.edb file growth

  • 25/03/201508/04/2015
  • by Martin Ehrnst

A while back i got an alert that system drive on one of our monitored servers was full. When examining what was consuming disk space I noticed that HealthServiceStore.edb, located in the agent’s Health Service State folder was way to large.

HealthServiceStore.edb is where the result of every workflow that runs on this agent is stored and sent to your Management Server(s). An agent running a lot of performance counters (Exchange, SQL etc) will probably have a larger database file than your average file server.

At first, i tried to flush the agents cache wich did not work. The next thing i tried was to run the “online store maintenance” task from OpsMgr console, this task will run a de-fragmentation of the database file.
onli

You can follow the result in the event log, HealthService (7404) Health Service Store: Online defragmentation is beginning a full pass on database ‘<C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Health Service Store\HealthServiceStore.edb>’.

Did this work? No, my database file was still huge.
The next thing to do, is to perform a “Dirty Defrag” on the DB file. To do this,

  • open your favorite shell and navigate to C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Health Service Store
  • Stop Healthservice.exe (Microsoft Monitoring Agent)
  • Run esentutl /r edb (recovery mode)
  • Start defragmentation by running esentutl /d HealthServiceStore.edb

esentutl

Your healthservicestore.edb should now have a normal size.

Do you have anything to include, please comment.

Share this:

  • LinkedIn
  • Twitter
  • Reddit

Popular blog posts

  • Azure Application registrations, Enterprise Apps, and managed identities
  • SCOM 1801 REST API Interfaces
  • Creating Azure AD Application using Powershell
  • Automate Azure DevOps like a boss
  • Access to Blob storage using Managed Identity in Logic Apps - by Nadeem Ahamed

Categories

Automation Azure Azure Active Directory Azure Bicep Azure DevOps Azure Functions Azure Lighthouse Azure Logic Apps Azure Monitor Azure Policy Community Conferences CSP Monitoring DevOps Guest blogs Infrastructure As Code Microsoft CSP MPAuthoring OMS Operations Manager Podcast Powershell Uncategorised Windows Admin Center Windows Server

Follow Martin Ehrnst

  • Twitter
  • LinkedIn

RSS feed RSS - Posts

RSS feed RSS - Comments

Microsoft Azure MVP

Martin Ehrnst Microsoft Azure MVP
Adatum.no use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it. Cookie Policy
Theme by Colorlib Powered by WordPress