locked
WSUS status report causing high cpu usage on clients??? RRS feed

  • Question

  • Hi,

    Since yesterday morning, we've been noticing abnormal cpu spikes on many of our windows servers.  It's occurring randomly and only lasts for about 5 or 10 mins, then goes away.  On a hunch that it might be windows updates, I checked our WSUS server and noticed that the "last report status report" date for each of the affected machines matches very closely to the time when the spike occurred.  I have checked %windir%\WindowsUpdate.log  on a couple of the machines and the last entry in the file shows something similar to:

    2015-07-16 12:28:09:365  872 f34 AU Launched new AU client for directive 'Install Approval', session id = 0x2

    Nothing has changed with our WSUS configuration (which is controlled by group policy).  Also, our group policy is set to auto download and schedule the install on Sunday mornings....immediate installation disabled....detection frequency disabled.

    all that said:

    1.  what exactly is the log entry that I posted above saying?  Is it downloading approved updates?  Installing them (it shouldn't be according to our policy)

    2.  why is this causing cpu spike's?...after reviewing our performance logs for each server (going back 30 days), these servers never have cpu spikes like this.

    3. what exactly is the "status report" date showing in wsus and how to control it?

    Thanks in advance for any tips!

    Thursday, July 16, 2015 5:42 PM

Answers

  • thx for the reply.

    Yes, I forgot to mention before that I did catch one of these in the act and saw with taskmgr that svchost was the process responsible for chewing up cpu.

    The option in the gpo to instal low impact updates is disabled....also, the detection frequency is disabled....which upon further reading, having this disabled sets the client to the default....check for updates approx. every 16-22 hours (random).  looking at my perf logs, each the spikes are occurring about 20 hours apart on all of the servers....all exactly during the time frame where I see the message I posted above from the WindowsUpdate.log on the affected client.....also, it's not spiking all of my machines....just machines with 1 vcpu. 

    my grand conclusion is that this week was a very heavy patch week (wsus shows that we synced over 2800 updates this week from MS).....my guess is that the number of updates for the client to check is obviously processor intensive and more then some of my puny vm's with 1 vcpu can handle.  hopefully, this will cease after the updates are applied this sunday.....for now, I can rest somewhat easier knowing that the spikes are from the updates client and not some rogue malware

    Friday, July 17, 2015 12:59 PM

All replies

  • check the GPOs to ensure the interval of clients checking in for updates is not something like 1 hour

    the behavior is normal for clients to check in with the server daily even if you are just updating on Sundays

    check if you have the GPO option enabled to immediately install low-impact updates which will deploy approved updates in the background as long as they don't require a reboot

    you need to use process explorer to see what exactly is causing CPU spikes.  windows update agent is enclosed in one of the svchost containers so you would need to drill down and find out what's going on

    • Proposed as answer by Steven_Lee0510 Monday, August 10, 2015 5:18 AM
    Thursday, July 16, 2015 7:01 PM
  • thx for the reply.

    Yes, I forgot to mention before that I did catch one of these in the act and saw with taskmgr that svchost was the process responsible for chewing up cpu.

    The option in the gpo to instal low impact updates is disabled....also, the detection frequency is disabled....which upon further reading, having this disabled sets the client to the default....check for updates approx. every 16-22 hours (random).  looking at my perf logs, each the spikes are occurring about 20 hours apart on all of the servers....all exactly during the time frame where I see the message I posted above from the WindowsUpdate.log on the affected client.....also, it's not spiking all of my machines....just machines with 1 vcpu. 

    my grand conclusion is that this week was a very heavy patch week (wsus shows that we synced over 2800 updates this week from MS).....my guess is that the number of updates for the client to check is obviously processor intensive and more then some of my puny vm's with 1 vcpu can handle.  hopefully, this will cease after the updates are applied this sunday.....for now, I can rest somewhat easier knowing that the spikes are from the updates client and not some rogue malware

    Friday, July 17, 2015 12:59 PM