WSUS / Memory and/or CPU consumption

Claudio Fiechter 6 Reputation points
2022-01-19T14:28:27.007+00:00

Hi!

We have a really big issue with the CPU / Memory consumption from IIS/WSUS on many different servers.

We install WSUS on a server 2016 or 2019 with SQL as DB solution. Updates are not stored locally, the clients are installing the updates directly from microsoft. After the inital setup the IIS worker processes starts to consume a huge amount of memory and/or CPU.

I've already done some researches and did all the IIS tweaking which is mentioned in different blogs in the web (Memory Limit, Queue Length, etc.). Unfortunately this has no effect. If the memory limit is set to, lets say 8gb for example then the IIS Application Pool just crashes after reaching the configured memory limit. If its set to unlimited it takes up to almost infinite memory and the server becomes very sluggish, also the WSUS mmc crashes.

This issue occurs on many different servers in complete different environments, even when WSUS is managing only 5 to 10 clients - on the servers runs nothing besides WSUS.

I've already opened a microsoft ticket but it seems a bit hopeless at the moment. The support engineer confirmed that this behavior is not normal but also has no solution at the moment. We already switched some installations from WID to SQL - the behavior is the same.

So if anyone here has an idea or a hint I'd be very grateful, this starts to hunt me in my dreams :-)

Have a nice day!

Windows Server
Windows Server
A family of Microsoft server operating systems that support enterprise-level management, data storage, applications, and communications.
12,170 questions
0 comments

5 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Greg Long 5 Reputation points
    2023-02-21T20:44:53.09+00:00

    I think you are talking about CPU on the server receiving updates and not the WSUS servers sending the updates. I see the exact same thing. I would suggest you have WSUS send updates to you servers. I setup a LAB , I have a main WSUS and two Satellite systems. One satellite does not download updates, the other does. I then do test up update downloads from both. For the same exact Client I get two very different behaviors.

    On the client that downloads updates from WSUS server we get almost no CPU utilization for a 2GB download.

    On the client that points to the WSUS that does not download updates , we also have to make sure the "Alternate Download Server" is blank or not set. We then see the Client download updates from the internet and it KILLS the boxes. a 2 CPU box will use 100% CPU for almost the entire duration of the download. I see network services and TIWorker using CPU. I assume this is because of the way internet downloads of Windows Updates work.

    That is why I say go with WSUS downloads if possible.

    1 person found this answer helpful.
    0 comments
  2. Philippe Levesque 5,691 Reputation points MVP
    2022-01-19T15:35:55.913+00:00

    Hi

    Did you select only the specific product you want to manage from the WSUS option ? to be sure to not have all the product catalog downlaoded and used.

    0 comments
  3. Adam J. Marshall 8,706 Reputation points MVP
    2022-01-19T16:36:42.517+00:00

    Have you run the monthly WSUS maintenance?

    https://www.ajtek.ca/wsus/how-to-setup-manage-and-maintain-wsus-part-8-wsus-server-maintenance/

    There's also MUCH MORE than just the SQL reindexing script.

    What products and classifications do you have selected? Only those in your network or did you check them all?

    0 comments
  4. Claudio Fiechter 6 Reputation points
    2022-01-20T09:07:18.11+00:00

    Thanks for your inputs - I've always just selected the producst and classification which we're currently using in the appropriate environment.

    I've already bought your script for a lot of different environment to automate the maintenance which works very good but unfortunately this does also not resolve the issue...

  5. Adam J. Marshall 8,706 Reputation points MVP
    2022-01-23T22:33:45.253+00:00