This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
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!
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.
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?
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...
anonymous user
Please follow the below links and confirm whether it is helpful: https://learn.microsoft.com/en-us/troubleshoot/mem/configmgr/troubleshoot-wsus-server-high-cpu-usage#:~:text=If%20it%20changes%20more%20often%2C%20your%20connection%20limit,increase%20connection%20limits%20to%20the%20WSUS%20administration%20website.
Hope the above will be helpful.
Regards, Rita
How many vCPUs do you have set for the VM?
https://www.ajtek.ca/wsus/wsus-system-requirements-what-should-i-plan-for/
Hi Adam
Thanks for your input - usually we assign to our VMs from 4 up to 6 vCPUs. If I assign the vCPUs for the WSUS VM following your guidance then the other VMs which are running on the same host (e.g. SQL, RDS, DC) are running with very poor performance.
But after doing some of the tweaks which were linked here CPU seems now to be fine. Also switching from WID to SQL seems to fix the issue with the crazy high memory consumption of the database. What now bugs me is the memory consumption of the iis worker process. On a server which is running nothing besides WSUS and AntiVirus the IIS Worker process takes up from 4 to 6 GB of RAM - the WSUS manages 20-30 Clients and 5 Servers and does not store updates locally. In my opinion this is a lot of ram consumption for this number of clients but maybe I'm completely wrong and this is a normal behaviour?
Looking forwad to hear from you!
This doesn't make sense, unless WSUS is 100% of the time taking up CPU at every second of every day.
VM's pool resources. The vCPUs dictate how much resources the VM can use. What happens to the other resources - IF THEY ARE NOT USED at the time - by the other VM's? It's wasted and the server could have potentially allocated the resources to WSUS to allow it to process much faster, and clear the queue of what it needed to do much faster than not using them.
This comes down to Math - Shorter processing time, higher processor count, other VMs could lose out on processing power while the WSUS VM takes up 100% of the CPUs for a MUCH SHORTER duration of time (let's say 10 seconds every 24 hours - it's not that - just an example) vs longer processing time, lower processor count, other VM's have segregated virtual processors so there will never be a shared vCPU with a request for processing running for a MUCH LONGER duration of time (let's say 5 minutes every hour - just an example)
You can peg 4 vCPUs for 4 minutes, or 20 vCPUs for 20 seconds.
Example:
Start processing 1 and combine this with a queue of 2 with additional 1 growing the queue every 5 minutes, if you use 4 vCPUs, you'll have them processing 100% of the time for 44 minutes. If you pegged 20 vCPUs, you would have 20 seconds x3 used (1 + 2 in queue), and then 20 seconds pegged every 5 minutes thereafter with the first one starting at 4 minutes after the first 3 finish processing emptying the queue.
Hi Adam
You are of course right - I made a misinterpretation of the vCPU calculating and the processor scheduling in HyperV in general.
Although I'm not sure if adding more vCPUs to our VMs will resolve my issue since the CPU seems no longer to be the problem. Inside the VM the CPU utilization looks fine - in a peak there is a CPU utilization of 70% for a short time but drops down to 5 or 10%, even over a longer time. On the host itself there are also no problems noticable regarding the CPU utilization. (Yes I know that Task Manager is not the best tool monitor the ressources but following my experiences it gives a good first hint what might be the problem which needs to be investigated in detail).
But as mentioned in my previous post there is still the IIS worker process which takes up a huge amount of memory (IMHO) - I don't think the IIS worker process will take less memory if I add more vCPUs o r am I wrong? Or is it just normal for the IIS worker process / WSUS AppPool to take between 4 and 6 GB of memory in such a small environment?
Did you change the ApplicationPool memory to 4GB like WAM suggests? If so, that could be why :) Default is 1.8GB
Hi Adam
Yes, I've changed the application pool go 4GB like your tool suggested - but since I'm not an IIS expert I've always thought this is the "maximum possible" configuration and not the "fixed" consumption of the pool (I hope you get what I mean :-) )
So then this behaviour seems to be normal and our WSUS Servers will just get some more memory in the future- thank you very much!
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.