[Check_mk (english)] Antw: Windows Updatae Plugin - 100% CPU
Lance.Tost at key-stone.com
Wed Jul 22 16:25:56 CEST 2015
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).
From: checkmk-en-bounces at lists.mathias-kettner.de <checkmk-en-bounces at lists.mathias-kettner.de> on behalf of Barth Uwe <Uwe.Barth at stadt-chemnitz.de>
Sent: Wednesday, July 22, 2015 2:06 AM
To: checkmk-en at lists.mathias-kettner.de
Subject: [Check_mk (english)] Antw: Windows Updatae Plugin - 100% CPU
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.
>>> Lance Tost <Lance.Tost at key-stone.com> 21.07.2015 20:48 >>>
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?
Here are my ini settings:
execution windows_updates.vbs = async
timeout windows_updates.vbs = 900
cache_age windows_updates.vbs = 14400
retry_count windows_updates.vbs = 3
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.
checkmk-en mailing list
checkmk-en at lists.mathias-kettner.de
Well meet in Munich for the 2nd Check_MK Conference!
Book your place now and be part of it.
October 18th-20th, 2015
More information about the checkmk-en