What is config churn?


<!--[if lt IE 9]>

<![endif]-->

Comments (14)

  1. Kevin Holman says:

    @Jr –

    Mostly just bugs in MP’s…. unfortunately. That said – in SCOM 2012, Config Churn is not nearly as much of a problem as it was in SCOM 2007 R2, due to the database driven distributed config. Not saying we shouldn’t strive to do better with best practices on management packs, but at least the impact isn’t crippling. For instance, if there was NO impact on SCOM, who would care about such things? 🙂

    1. Afzal says:

      Dear
      Good article. My config file on ms got double in size suddenly. On normal MS the size was 37 MB now it is 68 MB and dedicated management servers the size was 138 mb now it is 840 MB almost 6x increase in size. We recently had oms deployed. Can config file size increased in such folds because of OMS

      1. Kevin Holman says:

        @Azfal –

        Config file size is not a huge concern… the only real negative of a big file, is if you have churn, you are increasing the time to calculate config, and increasing IOPS significantly on the volume that holds the config file. In SCOM 2012 and later – you can measure how reliable config generation is with the queries from: https://blogs.technet.microsoft.com/kevinholman/2014/06/26/the-case-of-the-dell-detailed-mp-beware-of-large-environments/

        SELECT * FROM cs.workitem
        WHERE WorkItemName like ‘%delta%’
        ORDER BY WorkItemRowId DESC

        SELECT * FROM cs.workitem
        WHERE WorkItemName like ‘%snap%’
        ORDER BY WorkItemRowId DESC

        I’d want to know how long each takes, if this changed since adding OMS, and how often they fail. The log only keeps two days in there by design.

        Does OMS cause a huge config file? I dont know – have not seen that….. every interesting and somewhat concerning if it does. 🙂

        1. afzal says:

          dear kevin

          below is the output for snapshot sync
          DurationSeconds
          NULL
          237
          241
          226
          239
          228
          215
          203
          193
          284
          186
          201
          223
          181
          227
          189
          197
          309
          269
          266
          186
          171
          211

          also we get error 29181 sometimes for which stops synchronization for hours and some times even upto 2 days, and then resume automatically.

          OpsMgr Management Configuration Service failed to execute ‘SnapshotSynchronization’ engine work item due to the following exception

          Microsoft.EnterpriseManagement.ManagementConfiguration.DataAccessLayer.DataAccessException: Snapshot data transfer operation failed batch write

          Microsoft.EnterpriseManagement.ManagementConfiguration.DataAccessLayer.DataAccessException: Data access operation failed

          ———————————–
          System.Data.SqlClient.SqlException (0x80131904): Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
          Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. —> System.ComponentModel.Win32Exception (0x80004005): The wait operation timed out

  2. edward says:

    These queries works only when we have DW database, is there any query to check noisy discoveries with Operationmanager DB ?

  3. Anonymous says:

    Pingback from #WorstPractice ??? Enabling config churn by discovering properties that are significantly dynamic | Oleg Kapustin's sandbox

  4. Anonymous says:

    Here’s a new Knowledge Base article we published today on SCOM 2007. This one talks about configuration

  5. Anonymous says:

    Pingback from How to detect and troubleshoot frequent configuration changes in Operations Manager 2007 – Safranka M??ty??s szakmai blogja – TechNetKlub

  6. Anonymous says:

    Here’s a new Knowledge Base article we published today on SCOM 2007. This one talks about configuration

  7. johnredd says:

    Had a quick question, why are all my config churn causing property changes bogus? I mean these are static pieces of data that should not be changing. For example
    Microsoft.Windows.Server.2003.NetworkAdapter.Discovery discovers the name of the adapter. The device name is PROD but it keeps changing between PROD and ‘HP Network Teaming VIrtual Miniport Driver’. I can get the vbs discovery from the MP and test by running it locally to see if it really does retunr diff results but the VBS in the xml is minified so it is really painful to format it in order to run. This happens with tons of stuff like website name. It goes from NULL to the actual name but these servers have been montiored by SCOM for months – why would ‘old value’ be NULL?

  8. Curtiss says:

    Kevin, what is the ‘churn effect’ if I repeatedly import an MP that doesn’t contain any discoveries or group changes? specifically, what if I wanted to edit the raw XML of my notifications.internal MP and re-import the updated version every night (all
    via powershell)?

  9. Kaushik says:

    My question is about Connectors, Kevin. If a customer has an inbound connector that pushes data changes frequently to SCOM (maybe using the sdk), we will end up in same churn, without even the config file getting large in this case. What to do then? For eg. VMM has a connector that pushes DO changes. So if a customer has huge management server with lots of clusters there will be frequent DO resulting in same issue.

  10. Kaushik says:

    My question is about Connectors, Kevin. If a customer has an inbound connector that pushes data changes frequently to SCOM (maybe using the sdk), we will end up in same churn, without even the config file getting large in this case. What to do then? For eg. VMM has a connector that pushes DO changes. So if a customer has huge management server with lots of clusters there will be frequent DO resulting in same issue. Could you help.

    1. Kevin Holman says:

      Connectors can certainly create class instances, and can update class properties. Therefore, if they are updating properties of classes on a very frequent basis, this can cause config churn.

      SCOM 2012 handles config churn much better than SCOM 2007R2 did, which is when this article was written. However, it still creates large IOPS on the environment, and burdens it unnecessarily.

      I have no experience with the VMM MP’s and churn.

Skip to main content