Maintenance at its limits

Back in the days before Windows 8 and Server 2012, all the patches would quickly consume lots of disk space in the windows installer folder, due to caching of all the files, to make it possible if you needed to uninstall patches.
A common fix back then was to delete the contents, either manually or through some 3.part tools, which could cause inconsistency.

In win 8 and server 2012 Microsoft invented the Thrusted installer and TiWorker process to, among other stuff, maintain the WinSxS folder like cleaning up duplicated or orphaned files and compress the remaining folders.
In addition to that .Net precompiles its intermediate code into native machine code for the updated parts.
Sound pretty good ehh? Well it has some drawbacks…

All this maintenance stuff will of course use resources, a lot of resources, as the CPU goes high (one core at 100%) and a lot of Disk IO due to all the filehandling and compressing. As the process is started at normal thread prioritization it will be handled evenly among other programs started by the user or system. The task is started in the maintenance window (default at 2.00 in the morning) or when started up and any previous schedules was missed.

So you might figure out what happens if you use test or development environments that revert to snapshots… It will start its maintenance task right after Windows startup and this will highly impact your performance tests and what else you are running as part of the deployment job.

Another case is in datacenters when all servers suddenly at 2 starts using IO on the Disk system server 2012 automatic maintenance killed san

There has been a lot of fixes trying to minimize the impact, but not the root cause of the issue: The thread prioritization
Now, MS came to the rescue, with the release of Windows 10 Creators Update Fall edition 1709 (Build 10.0.16299.15) or Windows Server 2016 with build>16273

In the new release MS distinguish between the tasks it needs to accomplish.
When checking and installing updates will still run at normal priority, so will manually started maintenance, when the user started the maintenance.
However compression of the WinSxS folder due to low disc space or if the size of the folder exceeds 3 times the initial size.

So lets see when the first updates rolls out to latest Windows. it looks promising.

Author: KimC

TFS admin and deployment fellow

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s