Has anyone experience high CPU (pegged at 100% indefinitely on single-vCPU VMs) as a result of using the windows_updates.vbs plugin distributed with OMD?
We noticed some VMs 100% CPU and tracked it back to windows update (was a svchost.exe process consuming the CPU). Restarting Windows Update service helped for a little while then it came back. So then I thought maybe it was the plugin so I removed it from
the plugins directory, restarted Windows Update, and the high CPU usage has not come back since.
It seems it affected other multi-vCPU and physical servers, but it wasn’t as obvious as it was on single-vCPU VMs.
FWIW, the script usually does work… but this time it seems to have gotten hung up on something. Checking for updates using the point and click method works fine on these servers.
we see the same for our servers on 2008/2008R2 - the less CPU the server had the more worse the problem is. In our opinion it's a general WSUS problem when an OS is what we call "patched to death". We've got this also in time of 2003 and now 2008/2008R2 have also to much patches.
The Windows Update Agent on the server needs to much CPU to inventorize the installed updates and check if new ones exist. You can see this if by trying the following:
- stop services: Check_MK, Windows Update, Windows Modules Installer
- delete c:\windows\SoftwareDistribution (local WSUS cache)
- starts service Windows Modules Installer, Windows Update (don't start Check_MK)
- trigger Windows Update Agent to reset itself and check for updates ("wuauclt.exe /resetauthorization /detectnow")
If you now look at the Task Manager you'll see that svchost grabs again all CPU power for minutes.
The Check_MK windows_update.vbs just worsens the problem because it triggers the detection more often as WSUS do it by itself.
Has anyone experience high CPU (pegged at 100% indefinitely on single-vCPU VMs) as a result of using the windows_updates.vbs plugin distributed with OMD?
We noticed some VMs 100% CPU and tracked it back to windows update (was a svchost.exe process consuming the CPU). Restarting Windows Update service helped for a little while then it came back. So then I thought maybe it was the plugin so I removed it from the plugins directory, restarted Windows Update, and the high CPU usage has not come back since.
It seems it affected other multi-vCPU and physical servers, but it wasn't as obvious as it was on single-vCPU VMs.
FWIW, the script usually does work.. but this time it seems to have gotten hung up on something. Checking for updates using the point and click method works fine on these servers.
Another side effect is an ever-growing CBS.log file in c:\windows\logs\CBS.
See MS KB 947821 for possible (but not always effective) resolutions to Windows Servicing Store corruption.
The only workaround is to cache the windows updates check for a long time (e.g. 24 hours or so).
Cheers,
Phil
···
-----Original Message-----
From: checkmk-en-bounces@lists.mathias-kettner.de [mailto:checkmk-en-bounces@lists.mathias-kettner.de] On Behalf Of Barth Uwe
Sent: 22 July 2015 07:07
To: checkmk-en@lists.mathias-kettner.de
Subject: [Check_mk (english)] Antw: Windows Updatae Plugin - 100% CPU
Hi Lance,
we see the same for our servers on 2008/2008R2 - the less CPU the server had the more worse the problem is. In our opinion it's a general WSUS problem when an OS is what we call "patched to death". We've got this also in time of 2003 and now 2008/2008R2 have also to much patches.
The Windows Update Agent on the server needs to much CPU to inventorize the installed updates and check if new ones exist. You can see this if by trying the following:
- stop services: Check_MK, Windows Update, Windows Modules Installer
- delete c:\windows\SoftwareDistribution (local WSUS cache)
- starts service Windows Modules Installer, Windows Update (don't start Check_MK)
- trigger Windows Update Agent to reset itself and check for updates ("wuauclt.exe /resetauthorization /detectnow") If you now look at the Task Manager you'll see that svchost grabs again all CPU power for minutes.
The Check_MK windows_update.vbs just worsens the problem because it triggers the detection more often as WSUS do it by itself.
Has anyone experience high CPU (pegged at 100% indefinitely on single-vCPU VMs) as a result of using the windows_updates.vbs plugin distributed with OMD?
We noticed some VMs 100% CPU and tracked it back to windows update (was a svchost.exe process consuming the CPU). Restarting Windows Update service helped for a little while then it came back. So then I thought maybe it was the plugin so I removed it from the plugins directory, restarted Windows Update, and the high CPU usage has not come back since.
It seems it affected other multi-vCPU and physical servers, but it wasn't as obvious as it was on single-vCPU VMs.
FWIW, the script usually does work.. but this time it seems to have gotten hung up on something. Checking for updates using the point and click method works fine on these servers.
Well meet in Munich for the 2nd Check_MK Conference!
Book your place now and be part of it.
October 18th-20th, 2015 http://mathias-kettner.com/conference
Hoople Ltd, Registered in England and Wales No. 7556595
Registered office: Plough Lane, Hereford, HR4 0LE
"Any opinion expressed in this e-mail or any attached files are those of the individual and not necessarily those of Hoople Ltd. You should be aware that Hoople Ltd. monitors its email service. This e-mail and any attached files are confidential and intended solely for the use of the addressee. This communication may contain material protected by law from being passed on. If you are not the intended recipient and have received this e-mail in error, you are advised that any use, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. If you have received this e-mail in error please contact the sender immediately and destroy all copies of it."
I knew about the CBS.log problem that Phil mentioned. I can work around that. It's good to know it's not just us seeing the 100% CPU. I figured it was Windows Update itself and not specifically the script since all the script does is call Windows Update via VBS calls.
FWIW, we are also seeing it on 2012R2 servers so it doesn't get any better.
What I'm wondering is this. Since WIndows Update is already checking on its own for updates (I think we have it set to check at 3AM or something), does it cache that info anywhere? Could the windows_updates.vbs script just read the latest status from Windows Update rather than ask Windows Update to actively go check to see if there are any updates? Windows it not my primary area of expertise so I don't know these answers off the top of my head.... I will investigate and maybe try tweaking the script if I can find anything out.
As of now, I have the script disabled on all servers because the high CPU was causing such a problem (lasting for much more than a few minutes).
Thank you,
Lance
···
________________________________________
From: checkmk-en-bounces@lists.mathias-kettner.de <checkmk-en-bounces@lists.mathias-kettner.de> on behalf of Barth Uwe <Uwe.Barth@stadt-chemnitz.de>
Sent: Wednesday, July 22, 2015 2:06 AM
To: checkmk-en@lists.mathias-kettner.de
Subject: [Check_mk (english)] Antw: Windows Updatae Plugin - 100% CPU
Hi Lance,
we see the same for our servers on 2008/2008R2 - the less CPU the server had the more worse the problem is. In our opinion it's a general WSUS problem when an OS is what we call "patched to death". We've got this also in time of 2003 and now 2008/2008R2 have also to much patches.
The Windows Update Agent on the server needs to much CPU to inventorize the installed updates and check if new ones exist. You can see this if by trying the following:
- stop services: Check_MK, Windows Update, Windows Modules Installer
- delete c:\windows\SoftwareDistribution (local WSUS cache)
- starts service Windows Modules Installer, Windows Update (don't start Check_MK)
- trigger Windows Update Agent to reset itself and check for updates ("wuauclt.exe /resetauthorization /detectnow")
If you now look at the Task Manager you'll see that svchost grabs again all CPU power for minutes.
The Check_MK windows_update.vbs just worsens the problem because it triggers the detection more often as WSUS do it by itself.
Has anyone experience high CPU (pegged at 100% indefinitely on single-vCPU VMs) as a result of using the windows_updates.vbs plugin distributed with OMD?
We noticed some VMs 100% CPU and tracked it back to windows update (was a svchost.exe process consuming the CPU). Restarting Windows Update service helped for a little while then it came back. So then I thought maybe it was the plugin so I removed it from the plugins directory, restarted Windows Update, and the high CPU usage has not come back since.
It seems it affected other multi-vCPU and physical servers, but it wasn't as obvious as it was on single-vCPU VMs.
FWIW, the script usually does work.. but this time it seems to have gotten hung up on something. Checking for updates using the point and click method works fine on these servers.