I suggest you ...

13 votes
Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
You have left! (?) (thinking…)
Martin Ehrnst shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
  • Martin Ehrnst commented  ·   ·  Flag as inappropriate

    Confirmed by MS Premier Support. This rule does not do anything else than to log the event. The monitors using the event are disabled by default. It is totally safe to disable, and as long as you have *any* other event collected by SCOM you have confirmation of event collection work

  • Martin Ehrnst commented  ·   ·  Flag as inappropriate

    Hi Kevin, yes, we noticed the cpu impact on our hosts. Managed to track it down to that particular script using perf.mon etc. over a few hours. Not a problem for a single VM but for a host you will see CPU wait time etc caused by this as all VM's want to run at the exact same time.

    Added a few screen shots. one for a VM and one for the host who struggle the most

    VM: https://pasteboard.co/GSZjJRQ.png

    Host: https://pasteboard.co/GSZkoLd.png

  • Kevin Holman commented  ·   ·  Flag as inappropriate

    Are you actually seeing CPU impact here in practice, or in theory? Because the simple writing of an event is VERY low CPU impact. Like difficult to measure, low.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Could probably change:

    From :
    <DataSource ID="Scheduler" TypeID="System!System.SimpleScheduler">

    To(will need to allow some overrides or hardcode the values instead):

    <DataSource ID="Scheduler" TypeID="System!System.Scheduler">
    <SpreadInitializationOverInterval Unit="Seconds">$Config/SpreadTimeSeconds$</SpreadInitializationOverInterval>
    <ExcludeDates />

Feedback and Knowledge Base