locked
IIS/WSUSPool consuming all CPU and clients cannot check in RRS feed

  • Question

  • Currently CPU is nearly maxed out on our WSUS (Config Manager Software Update Point server) and clients cannot scan for updates, getting error 0x8024401c. This has been an ongoing, recurring issue for us. In the past maintenance/cleanup of SUSDB has addressed it, or in one case when we were running out of space we truncated the tbEvents table to free it up.

    This time we have run full cleanup on the servers in our environment, run the script to re-index the SUSDB and free space is not an issue. Further, I have increased the queue time on the WSUSPool to 25000 and increased the private memory limit to 12 GB. Nothing has helped—the CPU is still running hot and clients cannot scan. The IIS logs look clean to me, 200s with an occasional 400 or 500.

    I thought I would check in and see if anyone had any ideas before contacting MS support...

    Thursday, August 10, 2017 6:41 AM

All replies

  • Hi Sir,

    Have you checked the similar thread :

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/6e06d98e-7d43-4424-befa-49e16f6ff00e/wsuspool-eating-100-cpu?forum=winserverwsus

     

    Best Regards,

    Elton


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, August 11, 2017 9:43 AM
  • Your cleanup routines you've done have no comparison to my script's cleanup and maintenance.

    Have a peek at my Adamj Clean-WSUS script. It is the last WSUS Script you will ever need.

    http://community.spiceworks.com/scripts/show/2998-adamj-clean-wsus

    What it does:

    1. Remove all Drivers from the WSUS Database.
    2. Shrink your WSUSContent folder's size by declining superseded updates.
    3. Remove declined updates from the WSUS Database.
    4. Clean out all the synchronization logs that have built up over time (configurable, with the default keeping the last 14 days of logs).
    5. Compress Update Revisions.
    6. Remove Obsolete Updates.
    7. Computer Object Cleanup (configurable, with the default of deleting computer objects that have not synced within 30 days).
    8. Application Pool Memory Configuration to display the current private memory limit and easily increase it by any configurable amount.
    9. Run the Recommended SQL database Maintenance script on the actual SQL database.
    10. Run the Server Cleanup Wizard.

    It will email the report out to you or save it to a file, or both.

    Although the script is lengthy, it has been made to be super easy to setup and use. There are some prerequisites and instructions at the top of the script. After installing the prerequisites and configuring the variables for your environment, simply run:

    .\Clean-WSUS.ps1 -FirstRun

    and then

    .\Clean-WSUS.ps1 -InstallTask

    If you wish to view or increase the Application Pool Memory Configuration, you must run it with the required switch. See Get-Help .\Clean-WSUS.ps1 -Examples

    If you're having trouble, there's also a -HelpMe option that will create a log so you can send it to me for support.


    Adam Marshall, MCSE: Security
    http://www.adamj.org


    • Edited by AJTek.caMVP Saturday, August 12, 2017 2:53 AM grammer.
    • Proposed as answer by AJTek.caMVP Monday, August 21, 2017 3:21 AM
    Saturday, August 12, 2017 2:52 AM
  • Thanks for sharing. Log is showing this:

    FullyQualifiedErrorId : ERROR Connecting to the WSUS Server: <Server Name Redacted>. Please check your settings and try again.

    Am I missing something obvious or is the server so overloaded the script won't complete?

    Sunday, August 13, 2017 9:28 PM
  • Did you change the variable for the WSUS server name? If you did, change it back as it automatically grabs it. Make sure you set the port and if you are using SSL or not.

    Version 3.0 will automatically detect everything, but it is not out yet.


    Adam Marshall, MCSE: Security
    http://www.adamj.org

    Sunday, August 13, 2017 9:41 PM
  • I restarted IIS and also went back to not specifying the variable for the WSUS server. The script completed but unfortunately has not helped. The server still has a pegged CPU and clients cannot check in. This was the log summary:

    Statistics for all tables have been updated.
    Done updating statistics.2017-08-13 18:15:29.263
    WSUS DB Maintenance Stream Duration: 00:00:02:29

    Adamj WSUS Server Cleanup Wizard:

    <server name redacted>
    Version: 6.3.9600.18694
    SupersededUpdatesDeclined: 0
    ExpiredUpdatesDeclined: 0
    ObsoleteUpdatesDeleted: 0
    UpdatesCompressed: 0
    ObsoleteComputersDeleted: 0
    DiskSpaceFreed (MB): 0
    DiskSpaceFreed (GB): 0
    WSUS Server Cleanup Wizard Duration: 00:00:00:16

    Clean-WSUS Script Duration: 00:00:26:25

    Monday, August 14, 2017 12:59 PM
  • At this point, I wonder if it would be better to simply uninstall and then re-install the SUP on the host. Any pitfalls with this option? Clients without the ability to scan for updates in the interim would not be an issue as they cannot check at all now.

    • Edited by BryanCP Monday, August 14, 2017 3:46 PM
    Monday, August 14, 2017 3:41 PM
  • Hi BryanCP,

    Please give it a try :

    1. Decline all superseded updates.

    http://www.tecknowledgebase.com/43/how-to-identify-and-decline-superseded-updates-in-wsus/

    2. install KB 2919355 and 3159706 

     https://support.microsoft.com/en-us/kb/2919355

     https://support.microsoft.com/en-us/kb/3159706

     

    Best Regards,

    Elton


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, August 15, 2017 2:33 AM
  • Elton, these updates were already installed on this server. Thanks for the suggestion though. Cleaning up the superseded updates was something I thought was handled my the AdamJ script.

    In the end, I removed the SUP and WSUS role and started over. It was done in 3 hours after troubleshooting for a week and I should have done it after the first day.

    I am going to leverage AdamJ's script for maintenenace moving forward. Thanks for sharing.

    • Proposed as answer by AJTek.caMVP Monday, August 21, 2017 3:21 AM
    Tuesday, August 15, 2017 11:59 AM
  • Have you installed the latest August 8, 2017—KB4034658 (OS Build 14393.1593) patch?

    This seems to be causing the issue, I am experiencing the same issue where WSUS IIS Worker Process uses 100% CPU and eventually crashes.

    MS has updated the KB and confirmed this is a patch issue but no workaround yet :( Anyone out there have a workaround for this?

    Tuesday, August 15, 2017 3:43 PM
  • No, our issue occurred before this update was released. Thanks for the heads up though—I will hold this back on this month's deployment.

    EDIT: Our WSUS Server is 2012 R2; the issue you mentioned applies to 2016 only AFAIK.

    • Edited by BryanCP Tuesday, August 15, 2017 3:53 PM
    Tuesday, August 15, 2017 3:45 PM
  • The issue you are describing is very similar - i bet its the same code change in all of these KBs that is causing this nightmare.
    Tuesday, August 15, 2017 3:58 PM
  • Looks like I am not the only one, and the issue is not limited to what techy86 posted about:

    High CPU/High Memory in WSUS following Update Tuesdays

    This was posted just last week.

    Tuesday, August 22, 2017 12:08 PM