SUM Update Status Summarizer consumes 100% CPU every hour for 15 minutes


  • SCCM 2012 SP1, every hour for approximately 15 minutes we see that the sqlserver.exe process consumes all available CPU resource for approximately 15 minutes.  Within SQL Server Activity Monitor we find the spTask_SUM_UpdateStatusSummarizer stored procedure is causing this and is taking quite some time to complete.  Is anyone else seeing this?  This is surely not normal?

    My Personal Blog:

    Friday, January 25, 2013 12:47 PM


  • The best practice is the default setting.

    If it's causing you issues, then set it higher as you've done.

    The summarizer really has nothing to do with deploying updates.

    If your SQL Server is having a hard time, it's probably under-sized or experiencing other bottlenecks caused by not designing it properly.

    No, there is no current fix for the summarizer issue (to my knowledge).

    Jason |

    Friday, August 23, 2013 2:59 PM

All replies

  • The query within the sp that is consuming the most CPU time is this;

    merge Update_ComplianceSummary dst   
            using (select * from v_Update_ComplianceSummary_Live where CI_ID in (select CI_ID from @ci) and NumUnknown>=0) src   
                on dst.CI_ID=src.CI_ID  
                when matched    
                    then update set LastSummaryTime=src.LastSummaryTime, NumTotal=src.NumTotal, NumUnknown=src.NumUnknown,    
                                    NumNotApplicable=src.NumNotApplicable, NumMissing=src.NumMissing, NumPresent=src.NumPresent, NumInstalled=src.NumInstalled, NumFailed=src.NumFailed   
                when not matched   
                    then insert (CI_ID, LastSummaryTime, NumTotal, NumUnknown, NumNotApplicable, NumMissing, NumPresent, NumInstalled, NumFailed)   
                         values(src.CI_ID, src.LastSummaryTime, src.NumTotal, src.NumUnknown, src.NumNotApplicable, src.NumMissing, src.NumPresent, src.NumInstalled, src.NumFailed)   

    The total CPU time taken is over 185,000 ms.

    Is there any database tuning or indexing etc. that I can perform?

    My Personal Blog:

    Friday, January 25, 2013 12:51 PM
  • More Info from the VMware performance monitor shows that these spikes occur starting at approximately (+/- 30 minutes) 11am in the morning and continue until 1am the following morning.  between 01:00 and 11:00 these spikes do not occur.

    The environment currently only handles server client systems, which are obviously on throughout the day and night.  Only a couple of workstations are currently configmgr clients.

    I cannot find any configurable item that behaves this way during the aforementioned hours.

    All site components and site systems are healthy.

    WSUS is synchronising fine.

    My Personal Blog:

    Friday, January 25, 2013 4:57 PM
  • Hello,

    could you resolve the issue? Have seen exact the same behaviour today. CPU utilization of the SQL is stuckling at 80% for very long (~ 2hrs). The task is summarzing the update compliance. Have set the update summarziation to a higher interval, but thats not a pretty good workaround. My thought was that maybe the indexes are broken, additionally i gave more RAM to the SQL Instance. Site and componets systems are healthy too. Anyone an idea?

    Thursday, February 14, 2013 6:15 PM
  • Indexing does seem a likely culprit here. Have you enabled the built-in database index site maintenance task?

    Jason |

    Thursday, February 14, 2013 7:04 PM
  • Yes its sheduled to Sunday, hope it will help. I`ll update this thread afterwards
    Thursday, February 14, 2013 8:05 PM
  • We are having the same issue after updating to SP1. Our server will run between 80-90% CPU usage for roughly an hour whenever the software update summarization is ran. We have also adjusted the update summarization schedule to run less frequently which helps but is not a permanent solution. We do have the "Rebuild Index" maintenance task enabled and have even manually rebuilt the indexes for all databases on the server with no change in performance when the summarization is ran.

    Edit: It is possible that this issue was occurring before the SP1 update.

    • Edited by BCCS Support Thursday, February 14, 2013 9:53 PM
    Thursday, February 14, 2013 9:31 PM
  • Also experiencing this issue where the Database CPU hits 100% for about 10-15 minutes every hour on running this summisation query.

    Love to hear a way to resolve this issue other than just turning down the schedule.

    We are running SCCM 2012 SP1.

    Thursday, February 14, 2013 11:21 PM
  • I am relieved to hear that this is not just an isolated incident.  I am not working with that specific customer at the moment so I can't actively try possible solutions.  The weird thing is that with an almost identical configuration in my own VMware environment I do not see these spikes - however the main difference is that my lab environment was BUILT from SP1 media and the customer environment was an upgrade.  I wonder if the database upgrade process introduces some changes that are not 'quite right'.

    My Personal Blog:

    Friday, February 15, 2013 4:46 PM
  • Something new in this issue?

    Monday, February 25, 2013 8:38 AM
  • Something new in this issue?

    Same problem here. My system was upgradet with SP1. My system (most of it) is migrated from SCCM 2007. In my LAB environment all is normal, this system is not migrated and does not have the same load by far.

    Indexing once a week does not help.

    Read this post, same issue: here

    I Will set the Software Update Summarization to once a day and see it that helps.

    Tuesday, March 5, 2013 10:33 AM
  • Where is the setting for software update summarization schedule?

    edit: Just found it.  Under Software Library, Select "All Software Updates", and a "Schedule summariztion" button appears in the toolbar.  

    Tuesday, March 5, 2013 11:22 PM
  • I too am seeing this same issue.  I have adjusted the summarization to run once per day, but that is not a permanent solution.  Has anyone found a permanent fix for this?  Our system already has 4 CPU's.



    Tuesday, March 19, 2013 2:30 PM
  • At this point, there is no permanent fix; however, the product group is aware of the "issue" and is actively working on a resolution.

    Larger organizations seeing this issue have set the task to run even less frequently -- like once a week or month -- unfortunately, it cannot be disabled.

    This task simply serves to update software update compliance information in the console which for many larger organizations is pretty useless anyway so there really is no harm in not having this info up to date in the console; it in no way affects data in the DB.

    Jason |

    Tuesday, March 19, 2013 3:33 PM
  • Well hopefully a patch/fix is released at some point, I would like to see it implemented.

    If anyone hears anything it would be awesome if they could post the info to this thread. :)

    Wednesday, March 20, 2013 7:25 AM
  • I have the same problem on a clean SCCM 2012 SP1 install (not upgraded from RTM). The problem exist both before and after installing CU1.

    Hope the SCCM Team will have a fix ready soon!

    Thursday, April 18, 2013 7:07 AM
  • We have the same problem to after SP1 upgrade and have seen CPU spike to 90% and also filling up this folder "E:\MSSQL\MSRS10_50.MSSQLSERVER\Reporting Services\LogFiles" with logfiles. 

    I have set the Software Update Summarization Schedule to 7 days instead. But is it safe to delete the logfiles in that location? It has grown to 29GB.

    Monday, May 20, 2013 11:12 AM
  • Reporting services log files have *nothing* to do with the software update summarizer.

    Your reporting services DB should be in simple mode. No, it is generally not safe to delete SQL log files -- they are not normal text log files.

    Jason |

    Monday, May 20, 2013 3:29 PM
  • Hi,

    We do also see this issue with SUM Update Status Summarizer consumes 100% CPU

    We did have set the "software update summarization schedule" to once per hour, and change to once per day (What is the best practice for this setting).

    We did notice it when we deployed Windows Update, with an narrow schedule for deploing and installing.

    We also notice that it is har for the server to process files in inboxes\auth\\incoming and it is hard for the SQL to handle this.

    Is there any general fix for this?


    Friday, August 23, 2013 12:55 PM
  • The best practice is the default setting.

    If it's causing you issues, then set it higher as you've done.

    The summarizer really has nothing to do with deploying updates.

    If your SQL Server is having a hard time, it's probably under-sized or experiencing other bottlenecks caused by not designing it properly.

    No, there is no current fix for the summarizer issue (to my knowledge).

    Jason |

    Friday, August 23, 2013 2:59 PM
  • Has anyone found a solution to this problem.  We are also experiencing it and our setup is very similar.
    Wednesday, August 28, 2013 4:23 PM
  • Nothing different than is already discussed in this thread.

    Jason |

    Wednesday, August 28, 2013 5:25 PM
  • Still have the same issue in our environment, hoping there is a fix published soon seeing as how the appropriate product group is apparently aware of it.
    Wednesday, August 28, 2013 11:22 PM
  • Just been experiencing the issue in my small lab environment - it was maxing out the SQL Server's 4 vCPUs every hour as described above

    I've now set the SUM Summarizer to run weekly to see if this helps. 

    BTW, I'm using SCCM 2012 SP1 with CU3 installed - planning to goto R2 as soon as I can.

    Regards Craig Wilson

    Friday, November 8, 2013 10:50 AM