Why does Disk Cleanup take so much time and cpu?
Just a curiosity question. Disk Cleanup has been spending 100% of one of my cores for quite a while and still going. Seems to be spending a lot of time especially on Windows Update Cleanup.
Can't quite understand why deleting files should be such an intensive activity. Especially since it already spent quite a lot of time calculating what it could delete.
Why does Disk Cleanup take so much time and cpu? What does it do that is so intensive?
windows windows-8.1 windows-update disk-cleanup
add a comment |
Just a curiosity question. Disk Cleanup has been spending 100% of one of my cores for quite a while and still going. Seems to be spending a lot of time especially on Windows Update Cleanup.
Can't quite understand why deleting files should be such an intensive activity. Especially since it already spent quite a lot of time calculating what it could delete.
Why does Disk Cleanup take so much time and cpu? What does it do that is so intensive?
windows windows-8.1 windows-update disk-cleanup
add a comment |
Just a curiosity question. Disk Cleanup has been spending 100% of one of my cores for quite a while and still going. Seems to be spending a lot of time especially on Windows Update Cleanup.
Can't quite understand why deleting files should be such an intensive activity. Especially since it already spent quite a lot of time calculating what it could delete.
Why does Disk Cleanup take so much time and cpu? What does it do that is so intensive?
windows windows-8.1 windows-update disk-cleanup
Just a curiosity question. Disk Cleanup has been spending 100% of one of my cores for quite a while and still going. Seems to be spending a lot of time especially on Windows Update Cleanup.
Can't quite understand why deleting files should be such an intensive activity. Especially since it already spent quite a lot of time calculating what it could delete.
Why does Disk Cleanup take so much time and cpu? What does it do that is so intensive?
windows windows-8.1 windows-update disk-cleanup
windows windows-8.1 windows-update disk-cleanup
edited Jul 10 '15 at 19:18
SushiGuy
1035
1035
asked Dec 2 '14 at 13:46
SvishSvish
15.8k53108168
15.8k53108168
add a comment |
add a comment |
7 Answers
7
active
oldest
votes
Windows compresses the WinSxS folder by removing replaced updates ad compressing files which can't be uninstalled and which are not used into diffs. This takes a lot of CPU power and thats why you see a high CPU usage.
You can analyze the CPU usage with xperf/WPA to verify this.
Doesn't it also calculate the space saved when compressing the oldest files (those not opened recently)?
– Justin Goldberg
Dec 2 '14 at 21:43
Nice video! Will definitely check into that tool :D
– Svish
Dec 3 '14 at 9:18
@Svish have you verified this? Is the question answered?
– magicandre1981
Dec 23 '15 at 5:23
add a comment |
I can confirm that Windows Updates Cleanup takes almost 100% CPU usage, it's all about WinSxS compression and reintegration of updates:
I started cleanup first time after Windows install and it took 2 hours to finish 50%.
From graph you can see, that at first lot of reading of small files from disk (second graph), and after 100% CPU usage for compression, and so on.
add a comment |
Just to put fire on the question, i had done on an inmutable virtual machine the next steps:
- Boot a SystemRescueCD and mount the windows partition
- List all files on disk to a log file (less than a minute)
- Reboot onto Windows
- Let
cleanmgr
do its job and take note of the time (more than eight hours) - Reboot onto SystemRescueCD and mount the windows partition
- List all files on disk to another log file (less than a minute)
- Reset back the inmutable virtual machine
- Reboot onto Windows
- Do a FOR /F ... to delete such files in an admin command prompt (cmd) and take note of the time (less than five minutes)
Please note i rebooted onto Linux SystemRescueCd just to be able to list all files, also the ones looked by Window and also to do such listing as fast as possible (no acl check, etc).
Also please note that on cleanmgr
i only count only time after search ends (the search itself also tooks more than six hours).
So deleting the files is not the botle neck (the delete itself only need five minutes but cleanmgr
takes more than eight hours).
The delete it self can go so fast since the host is a Linux, that speed is caused just because Linux caches all writes to the fixed size file that is used as the disk on the virtual machine (24GiB), and since i have 64GiB of RAM and i let to the Windows 16GiB it does not need to use SWAP neither PAGEFILE.SYS; also more, Linux can hold the full file on RAM (i tested with that file on RAM and delete times go done a lot, but cleanmgr
time does not drop down).
Yes, if i put the virtual disk totally on RAM, cleanmgr
time does not drop but if i manaully delete the files, that time drops down just a little (Linux write cache is great when you have 64GiB of RAM on it).
My configuration for the tests:
- Host: Linux 64bits distro over a hardware that main parts are AMD Deca Core 5GHz with 64GiB of RAM and a Sata Raid0 controller with two WD VelociRaptor HDDs (able to sustain a combined secuential write speed of near 1GiB/s and a 4K random write of 300MiB/s); cost is >ten thousand euros
- Guest: Windows 10 Home with 16GiB of ram and a Virtual disk of 24GiB
Test1: Having the 24GiB virtual disk on the physical harddisks
Test2: Having the 24GiB virtual disk on the Linux host RAM
I am afraid that cleanmgr
is doing something on the windows registry per each file it deletes (accessing the registry is very low).
Monitors i had:
- CPU usage on the Linux host and on the Windows Guest (most time between 0% and 1%, with pikes of 5%, no more)
- HDD usage on the Linux host (near 0% when
cleanmgr
was working, with pikes of 2%), Linux disk cache is really great avoiding dato be sent to real disk - HDD usage on the Windows guest (most time between 2% and 15% when
cleanmgr
was working, with pikes of 28%)
So clearly cleanmgr
is doing a lot of undetectable work, maybe sleep times? Maybe not, if it is accesiing registry, the CPU for that is not counted by Windows monitors, HDD on that is not used (registry is on RAM), etc., and each access to the registry can take more than a second... try your own program to access registry by opening the registry and closing it per each action versus letting the HK* opened... it is a great difference.
So if cleanmgr
does for each file:
- Open registry HK*
- Consult whatever needs and/or do some writes on registry
- Close registry HK*
It can take as much as two or three seconds per operation, and if it does one operation per file, it can take near one hour per each thousand of files... my count of files was just a little bit more than 40000 files, so 40000 files / 8 hours is processing one file each 1.3 seconds... on the other side, deleting them on a script (after knowing wich ones) tooks less than five minutes, that is deleting about 133 per second... a hufe difference.
So definitly cleanmgr
time is not caused by the deletion
it self! What else is it doing? Please M$ improve that speed!
1
This is not an answer to the original question. If you have a new question please ask your own question (referencing this one for context if it helps).
– DavidPostill♦
Feb 28 '17 at 11:43
Why didn't you use the process monitor (docs.microsoft.com/en-us/sysinternals/downloads/procmon) to analyze the actions of windows registry etc?
– cybernard
Apr 11 '18 at 1:22
*immutable sp.
– StingyJack
Sep 8 '18 at 14:07
add a comment |
Deleting 20 files of 5mb in size will take more time to delete than 10 files of 64mb in size. This is because when system deletes files, it doesn't really delete them (as empty space on a drive can be made of "noise" bits) but just overwrites the front part that says, "A file starts here" with gibberish and then it will happily overwrite that and the following parts later when you want to use the space. In reality, deleting is the same as writing otherwise.
The thing with disk cleanup, is the things it cleans are usually LOTS of small files (internet cookies, temporary files, etc.). As such, it does a lot more writing to the disk than a lot of other things, and can take as much time as installing something new, due to the volume being written to disk.
The original question specifically asks about Disk Cleanup.
– liljoshu
Dec 26 '15 at 21:59
add a comment |
One way to mitigate this problem and speed up the "Windows Update Cleanup" phase of "Disk Cleanup" a bit is to temporarily set a higher priority for the TiWorker.exe process for the duration of the so-called 'cleanup' activity.
In the Task Manager 'Details' pane, find TiWorker.exe
and right-click to show a pop-up menu. For 'Set Priority," choose "Above Normal." For me, this increased the TiWorker
CPU activity--from averaging around 16%--up to its full potential of 25% (on a 4-core machine).
Aside from the miniscule speedup--and possibly good feeling of accomplishment--this provides, there's little that can be done since apparently "Windows Update Cleanup" is coded in a way that, for some unknown reason, proceeds file-by-file, making the overall work horribly disk-bound.
And also, do know that the process is most probably not hung, and will indeed complete someday. To verify this (and to yet further distract yourself during this annoying wait time), you can check the 'Disk Activity' section of Resource Monitor (run "resmon.exe").
Very nice speed up!
– subjectivist
Sep 17 '18 at 20:04
add a comment |
Another word of warning: part of what takes up the time is that, when cleaning up WinSxS, Disk Clean-up has first to uncompress a lot of files. So disk usage actually increases for the first part of the clean-up!
add a comment |
Another way to speed up the process is to run the Disk Cleanup for about 5 min. Stop it, then re-start it, and it will whizz through in a jiffy! Also, De-Fragging or Optimizing your HDD/SSD beforehand will speed things up, just remember to de-frag/Optz it again after cleanup.
Please don't defragment your SSD it wears out read and write cycles and has almost no gain.
– Nordlys Jeger
Nov 6 '18 at 10:57
@NordlysJeger Windows itself does defrag for SSDs by design
– magicandre1981
Nov 6 '18 at 15:48
my bad, thank you for the info.
– Nordlys Jeger
Nov 6 '18 at 15:50
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f847556%2fwhy-does-disk-cleanup-take-so-much-time-and-cpu%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
7 Answers
7
active
oldest
votes
7 Answers
7
active
oldest
votes
active
oldest
votes
active
oldest
votes
Windows compresses the WinSxS folder by removing replaced updates ad compressing files which can't be uninstalled and which are not used into diffs. This takes a lot of CPU power and thats why you see a high CPU usage.
You can analyze the CPU usage with xperf/WPA to verify this.
Doesn't it also calculate the space saved when compressing the oldest files (those not opened recently)?
– Justin Goldberg
Dec 2 '14 at 21:43
Nice video! Will definitely check into that tool :D
– Svish
Dec 3 '14 at 9:18
@Svish have you verified this? Is the question answered?
– magicandre1981
Dec 23 '15 at 5:23
add a comment |
Windows compresses the WinSxS folder by removing replaced updates ad compressing files which can't be uninstalled and which are not used into diffs. This takes a lot of CPU power and thats why you see a high CPU usage.
You can analyze the CPU usage with xperf/WPA to verify this.
Doesn't it also calculate the space saved when compressing the oldest files (those not opened recently)?
– Justin Goldberg
Dec 2 '14 at 21:43
Nice video! Will definitely check into that tool :D
– Svish
Dec 3 '14 at 9:18
@Svish have you verified this? Is the question answered?
– magicandre1981
Dec 23 '15 at 5:23
add a comment |
Windows compresses the WinSxS folder by removing replaced updates ad compressing files which can't be uninstalled and which are not used into diffs. This takes a lot of CPU power and thats why you see a high CPU usage.
You can analyze the CPU usage with xperf/WPA to verify this.
Windows compresses the WinSxS folder by removing replaced updates ad compressing files which can't be uninstalled and which are not used into diffs. This takes a lot of CPU power and thats why you see a high CPU usage.
You can analyze the CPU usage with xperf/WPA to verify this.
answered Dec 2 '14 at 17:14
magicandre1981magicandre1981
81.2k20124203
81.2k20124203
Doesn't it also calculate the space saved when compressing the oldest files (those not opened recently)?
– Justin Goldberg
Dec 2 '14 at 21:43
Nice video! Will definitely check into that tool :D
– Svish
Dec 3 '14 at 9:18
@Svish have you verified this? Is the question answered?
– magicandre1981
Dec 23 '15 at 5:23
add a comment |
Doesn't it also calculate the space saved when compressing the oldest files (those not opened recently)?
– Justin Goldberg
Dec 2 '14 at 21:43
Nice video! Will definitely check into that tool :D
– Svish
Dec 3 '14 at 9:18
@Svish have you verified this? Is the question answered?
– magicandre1981
Dec 23 '15 at 5:23
Doesn't it also calculate the space saved when compressing the oldest files (those not opened recently)?
– Justin Goldberg
Dec 2 '14 at 21:43
Doesn't it also calculate the space saved when compressing the oldest files (those not opened recently)?
– Justin Goldberg
Dec 2 '14 at 21:43
Nice video! Will definitely check into that tool :D
– Svish
Dec 3 '14 at 9:18
Nice video! Will definitely check into that tool :D
– Svish
Dec 3 '14 at 9:18
@Svish have you verified this? Is the question answered?
– magicandre1981
Dec 23 '15 at 5:23
@Svish have you verified this? Is the question answered?
– magicandre1981
Dec 23 '15 at 5:23
add a comment |
I can confirm that Windows Updates Cleanup takes almost 100% CPU usage, it's all about WinSxS compression and reintegration of updates:
I started cleanup first time after Windows install and it took 2 hours to finish 50%.
From graph you can see, that at first lot of reading of small files from disk (second graph), and after 100% CPU usage for compression, and so on.
add a comment |
I can confirm that Windows Updates Cleanup takes almost 100% CPU usage, it's all about WinSxS compression and reintegration of updates:
I started cleanup first time after Windows install and it took 2 hours to finish 50%.
From graph you can see, that at first lot of reading of small files from disk (second graph), and after 100% CPU usage for compression, and so on.
add a comment |
I can confirm that Windows Updates Cleanup takes almost 100% CPU usage, it's all about WinSxS compression and reintegration of updates:
I started cleanup first time after Windows install and it took 2 hours to finish 50%.
From graph you can see, that at first lot of reading of small files from disk (second graph), and after 100% CPU usage for compression, and so on.
I can confirm that Windows Updates Cleanup takes almost 100% CPU usage, it's all about WinSxS compression and reintegration of updates:
I started cleanup first time after Windows install and it took 2 hours to finish 50%.
From graph you can see, that at first lot of reading of small files from disk (second graph), and after 100% CPU usage for compression, and so on.
answered Dec 4 '15 at 20:05
Arunas BartisiusArunas Bartisius
686610
686610
add a comment |
add a comment |
Just to put fire on the question, i had done on an inmutable virtual machine the next steps:
- Boot a SystemRescueCD and mount the windows partition
- List all files on disk to a log file (less than a minute)
- Reboot onto Windows
- Let
cleanmgr
do its job and take note of the time (more than eight hours) - Reboot onto SystemRescueCD and mount the windows partition
- List all files on disk to another log file (less than a minute)
- Reset back the inmutable virtual machine
- Reboot onto Windows
- Do a FOR /F ... to delete such files in an admin command prompt (cmd) and take note of the time (less than five minutes)
Please note i rebooted onto Linux SystemRescueCd just to be able to list all files, also the ones looked by Window and also to do such listing as fast as possible (no acl check, etc).
Also please note that on cleanmgr
i only count only time after search ends (the search itself also tooks more than six hours).
So deleting the files is not the botle neck (the delete itself only need five minutes but cleanmgr
takes more than eight hours).
The delete it self can go so fast since the host is a Linux, that speed is caused just because Linux caches all writes to the fixed size file that is used as the disk on the virtual machine (24GiB), and since i have 64GiB of RAM and i let to the Windows 16GiB it does not need to use SWAP neither PAGEFILE.SYS; also more, Linux can hold the full file on RAM (i tested with that file on RAM and delete times go done a lot, but cleanmgr
time does not drop down).
Yes, if i put the virtual disk totally on RAM, cleanmgr
time does not drop but if i manaully delete the files, that time drops down just a little (Linux write cache is great when you have 64GiB of RAM on it).
My configuration for the tests:
- Host: Linux 64bits distro over a hardware that main parts are AMD Deca Core 5GHz with 64GiB of RAM and a Sata Raid0 controller with two WD VelociRaptor HDDs (able to sustain a combined secuential write speed of near 1GiB/s and a 4K random write of 300MiB/s); cost is >ten thousand euros
- Guest: Windows 10 Home with 16GiB of ram and a Virtual disk of 24GiB
Test1: Having the 24GiB virtual disk on the physical harddisks
Test2: Having the 24GiB virtual disk on the Linux host RAM
I am afraid that cleanmgr
is doing something on the windows registry per each file it deletes (accessing the registry is very low).
Monitors i had:
- CPU usage on the Linux host and on the Windows Guest (most time between 0% and 1%, with pikes of 5%, no more)
- HDD usage on the Linux host (near 0% when
cleanmgr
was working, with pikes of 2%), Linux disk cache is really great avoiding dato be sent to real disk - HDD usage on the Windows guest (most time between 2% and 15% when
cleanmgr
was working, with pikes of 28%)
So clearly cleanmgr
is doing a lot of undetectable work, maybe sleep times? Maybe not, if it is accesiing registry, the CPU for that is not counted by Windows monitors, HDD on that is not used (registry is on RAM), etc., and each access to the registry can take more than a second... try your own program to access registry by opening the registry and closing it per each action versus letting the HK* opened... it is a great difference.
So if cleanmgr
does for each file:
- Open registry HK*
- Consult whatever needs and/or do some writes on registry
- Close registry HK*
It can take as much as two or three seconds per operation, and if it does one operation per file, it can take near one hour per each thousand of files... my count of files was just a little bit more than 40000 files, so 40000 files / 8 hours is processing one file each 1.3 seconds... on the other side, deleting them on a script (after knowing wich ones) tooks less than five minutes, that is deleting about 133 per second... a hufe difference.
So definitly cleanmgr
time is not caused by the deletion
it self! What else is it doing? Please M$ improve that speed!
1
This is not an answer to the original question. If you have a new question please ask your own question (referencing this one for context if it helps).
– DavidPostill♦
Feb 28 '17 at 11:43
Why didn't you use the process monitor (docs.microsoft.com/en-us/sysinternals/downloads/procmon) to analyze the actions of windows registry etc?
– cybernard
Apr 11 '18 at 1:22
*immutable sp.
– StingyJack
Sep 8 '18 at 14:07
add a comment |
Just to put fire on the question, i had done on an inmutable virtual machine the next steps:
- Boot a SystemRescueCD and mount the windows partition
- List all files on disk to a log file (less than a minute)
- Reboot onto Windows
- Let
cleanmgr
do its job and take note of the time (more than eight hours) - Reboot onto SystemRescueCD and mount the windows partition
- List all files on disk to another log file (less than a minute)
- Reset back the inmutable virtual machine
- Reboot onto Windows
- Do a FOR /F ... to delete such files in an admin command prompt (cmd) and take note of the time (less than five minutes)
Please note i rebooted onto Linux SystemRescueCd just to be able to list all files, also the ones looked by Window and also to do such listing as fast as possible (no acl check, etc).
Also please note that on cleanmgr
i only count only time after search ends (the search itself also tooks more than six hours).
So deleting the files is not the botle neck (the delete itself only need five minutes but cleanmgr
takes more than eight hours).
The delete it self can go so fast since the host is a Linux, that speed is caused just because Linux caches all writes to the fixed size file that is used as the disk on the virtual machine (24GiB), and since i have 64GiB of RAM and i let to the Windows 16GiB it does not need to use SWAP neither PAGEFILE.SYS; also more, Linux can hold the full file on RAM (i tested with that file on RAM and delete times go done a lot, but cleanmgr
time does not drop down).
Yes, if i put the virtual disk totally on RAM, cleanmgr
time does not drop but if i manaully delete the files, that time drops down just a little (Linux write cache is great when you have 64GiB of RAM on it).
My configuration for the tests:
- Host: Linux 64bits distro over a hardware that main parts are AMD Deca Core 5GHz with 64GiB of RAM and a Sata Raid0 controller with two WD VelociRaptor HDDs (able to sustain a combined secuential write speed of near 1GiB/s and a 4K random write of 300MiB/s); cost is >ten thousand euros
- Guest: Windows 10 Home with 16GiB of ram and a Virtual disk of 24GiB
Test1: Having the 24GiB virtual disk on the physical harddisks
Test2: Having the 24GiB virtual disk on the Linux host RAM
I am afraid that cleanmgr
is doing something on the windows registry per each file it deletes (accessing the registry is very low).
Monitors i had:
- CPU usage on the Linux host and on the Windows Guest (most time between 0% and 1%, with pikes of 5%, no more)
- HDD usage on the Linux host (near 0% when
cleanmgr
was working, with pikes of 2%), Linux disk cache is really great avoiding dato be sent to real disk - HDD usage on the Windows guest (most time between 2% and 15% when
cleanmgr
was working, with pikes of 28%)
So clearly cleanmgr
is doing a lot of undetectable work, maybe sleep times? Maybe not, if it is accesiing registry, the CPU for that is not counted by Windows monitors, HDD on that is not used (registry is on RAM), etc., and each access to the registry can take more than a second... try your own program to access registry by opening the registry and closing it per each action versus letting the HK* opened... it is a great difference.
So if cleanmgr
does for each file:
- Open registry HK*
- Consult whatever needs and/or do some writes on registry
- Close registry HK*
It can take as much as two or three seconds per operation, and if it does one operation per file, it can take near one hour per each thousand of files... my count of files was just a little bit more than 40000 files, so 40000 files / 8 hours is processing one file each 1.3 seconds... on the other side, deleting them on a script (after knowing wich ones) tooks less than five minutes, that is deleting about 133 per second... a hufe difference.
So definitly cleanmgr
time is not caused by the deletion
it self! What else is it doing? Please M$ improve that speed!
1
This is not an answer to the original question. If you have a new question please ask your own question (referencing this one for context if it helps).
– DavidPostill♦
Feb 28 '17 at 11:43
Why didn't you use the process monitor (docs.microsoft.com/en-us/sysinternals/downloads/procmon) to analyze the actions of windows registry etc?
– cybernard
Apr 11 '18 at 1:22
*immutable sp.
– StingyJack
Sep 8 '18 at 14:07
add a comment |
Just to put fire on the question, i had done on an inmutable virtual machine the next steps:
- Boot a SystemRescueCD and mount the windows partition
- List all files on disk to a log file (less than a minute)
- Reboot onto Windows
- Let
cleanmgr
do its job and take note of the time (more than eight hours) - Reboot onto SystemRescueCD and mount the windows partition
- List all files on disk to another log file (less than a minute)
- Reset back the inmutable virtual machine
- Reboot onto Windows
- Do a FOR /F ... to delete such files in an admin command prompt (cmd) and take note of the time (less than five minutes)
Please note i rebooted onto Linux SystemRescueCd just to be able to list all files, also the ones looked by Window and also to do such listing as fast as possible (no acl check, etc).
Also please note that on cleanmgr
i only count only time after search ends (the search itself also tooks more than six hours).
So deleting the files is not the botle neck (the delete itself only need five minutes but cleanmgr
takes more than eight hours).
The delete it self can go so fast since the host is a Linux, that speed is caused just because Linux caches all writes to the fixed size file that is used as the disk on the virtual machine (24GiB), and since i have 64GiB of RAM and i let to the Windows 16GiB it does not need to use SWAP neither PAGEFILE.SYS; also more, Linux can hold the full file on RAM (i tested with that file on RAM and delete times go done a lot, but cleanmgr
time does not drop down).
Yes, if i put the virtual disk totally on RAM, cleanmgr
time does not drop but if i manaully delete the files, that time drops down just a little (Linux write cache is great when you have 64GiB of RAM on it).
My configuration for the tests:
- Host: Linux 64bits distro over a hardware that main parts are AMD Deca Core 5GHz with 64GiB of RAM and a Sata Raid0 controller with two WD VelociRaptor HDDs (able to sustain a combined secuential write speed of near 1GiB/s and a 4K random write of 300MiB/s); cost is >ten thousand euros
- Guest: Windows 10 Home with 16GiB of ram and a Virtual disk of 24GiB
Test1: Having the 24GiB virtual disk on the physical harddisks
Test2: Having the 24GiB virtual disk on the Linux host RAM
I am afraid that cleanmgr
is doing something on the windows registry per each file it deletes (accessing the registry is very low).
Monitors i had:
- CPU usage on the Linux host and on the Windows Guest (most time between 0% and 1%, with pikes of 5%, no more)
- HDD usage on the Linux host (near 0% when
cleanmgr
was working, with pikes of 2%), Linux disk cache is really great avoiding dato be sent to real disk - HDD usage on the Windows guest (most time between 2% and 15% when
cleanmgr
was working, with pikes of 28%)
So clearly cleanmgr
is doing a lot of undetectable work, maybe sleep times? Maybe not, if it is accesiing registry, the CPU for that is not counted by Windows monitors, HDD on that is not used (registry is on RAM), etc., and each access to the registry can take more than a second... try your own program to access registry by opening the registry and closing it per each action versus letting the HK* opened... it is a great difference.
So if cleanmgr
does for each file:
- Open registry HK*
- Consult whatever needs and/or do some writes on registry
- Close registry HK*
It can take as much as two or three seconds per operation, and if it does one operation per file, it can take near one hour per each thousand of files... my count of files was just a little bit more than 40000 files, so 40000 files / 8 hours is processing one file each 1.3 seconds... on the other side, deleting them on a script (after knowing wich ones) tooks less than five minutes, that is deleting about 133 per second... a hufe difference.
So definitly cleanmgr
time is not caused by the deletion
it self! What else is it doing? Please M$ improve that speed!
Just to put fire on the question, i had done on an inmutable virtual machine the next steps:
- Boot a SystemRescueCD and mount the windows partition
- List all files on disk to a log file (less than a minute)
- Reboot onto Windows
- Let
cleanmgr
do its job and take note of the time (more than eight hours) - Reboot onto SystemRescueCD and mount the windows partition
- List all files on disk to another log file (less than a minute)
- Reset back the inmutable virtual machine
- Reboot onto Windows
- Do a FOR /F ... to delete such files in an admin command prompt (cmd) and take note of the time (less than five minutes)
Please note i rebooted onto Linux SystemRescueCd just to be able to list all files, also the ones looked by Window and also to do such listing as fast as possible (no acl check, etc).
Also please note that on cleanmgr
i only count only time after search ends (the search itself also tooks more than six hours).
So deleting the files is not the botle neck (the delete itself only need five minutes but cleanmgr
takes more than eight hours).
The delete it self can go so fast since the host is a Linux, that speed is caused just because Linux caches all writes to the fixed size file that is used as the disk on the virtual machine (24GiB), and since i have 64GiB of RAM and i let to the Windows 16GiB it does not need to use SWAP neither PAGEFILE.SYS; also more, Linux can hold the full file on RAM (i tested with that file on RAM and delete times go done a lot, but cleanmgr
time does not drop down).
Yes, if i put the virtual disk totally on RAM, cleanmgr
time does not drop but if i manaully delete the files, that time drops down just a little (Linux write cache is great when you have 64GiB of RAM on it).
My configuration for the tests:
- Host: Linux 64bits distro over a hardware that main parts are AMD Deca Core 5GHz with 64GiB of RAM and a Sata Raid0 controller with two WD VelociRaptor HDDs (able to sustain a combined secuential write speed of near 1GiB/s and a 4K random write of 300MiB/s); cost is >ten thousand euros
- Guest: Windows 10 Home with 16GiB of ram and a Virtual disk of 24GiB
Test1: Having the 24GiB virtual disk on the physical harddisks
Test2: Having the 24GiB virtual disk on the Linux host RAM
I am afraid that cleanmgr
is doing something on the windows registry per each file it deletes (accessing the registry is very low).
Monitors i had:
- CPU usage on the Linux host and on the Windows Guest (most time between 0% and 1%, with pikes of 5%, no more)
- HDD usage on the Linux host (near 0% when
cleanmgr
was working, with pikes of 2%), Linux disk cache is really great avoiding dato be sent to real disk - HDD usage on the Windows guest (most time between 2% and 15% when
cleanmgr
was working, with pikes of 28%)
So clearly cleanmgr
is doing a lot of undetectable work, maybe sleep times? Maybe not, if it is accesiing registry, the CPU for that is not counted by Windows monitors, HDD on that is not used (registry is on RAM), etc., and each access to the registry can take more than a second... try your own program to access registry by opening the registry and closing it per each action versus letting the HK* opened... it is a great difference.
So if cleanmgr
does for each file:
- Open registry HK*
- Consult whatever needs and/or do some writes on registry
- Close registry HK*
It can take as much as two or three seconds per operation, and if it does one operation per file, it can take near one hour per each thousand of files... my count of files was just a little bit more than 40000 files, so 40000 files / 8 hours is processing one file each 1.3 seconds... on the other side, deleting them on a script (after knowing wich ones) tooks less than five minutes, that is deleting about 133 per second... a hufe difference.
So definitly cleanmgr
time is not caused by the deletion
it self! What else is it doing? Please M$ improve that speed!
answered Feb 27 '17 at 9:27
ClaudioClaudio
211
211
1
This is not an answer to the original question. If you have a new question please ask your own question (referencing this one for context if it helps).
– DavidPostill♦
Feb 28 '17 at 11:43
Why didn't you use the process monitor (docs.microsoft.com/en-us/sysinternals/downloads/procmon) to analyze the actions of windows registry etc?
– cybernard
Apr 11 '18 at 1:22
*immutable sp.
– StingyJack
Sep 8 '18 at 14:07
add a comment |
1
This is not an answer to the original question. If you have a new question please ask your own question (referencing this one for context if it helps).
– DavidPostill♦
Feb 28 '17 at 11:43
Why didn't you use the process monitor (docs.microsoft.com/en-us/sysinternals/downloads/procmon) to analyze the actions of windows registry etc?
– cybernard
Apr 11 '18 at 1:22
*immutable sp.
– StingyJack
Sep 8 '18 at 14:07
1
1
This is not an answer to the original question. If you have a new question please ask your own question (referencing this one for context if it helps).
– DavidPostill♦
Feb 28 '17 at 11:43
This is not an answer to the original question. If you have a new question please ask your own question (referencing this one for context if it helps).
– DavidPostill♦
Feb 28 '17 at 11:43
Why didn't you use the process monitor (docs.microsoft.com/en-us/sysinternals/downloads/procmon) to analyze the actions of windows registry etc?
– cybernard
Apr 11 '18 at 1:22
Why didn't you use the process monitor (docs.microsoft.com/en-us/sysinternals/downloads/procmon) to analyze the actions of windows registry etc?
– cybernard
Apr 11 '18 at 1:22
*immutable sp.
– StingyJack
Sep 8 '18 at 14:07
*immutable sp.
– StingyJack
Sep 8 '18 at 14:07
add a comment |
Deleting 20 files of 5mb in size will take more time to delete than 10 files of 64mb in size. This is because when system deletes files, it doesn't really delete them (as empty space on a drive can be made of "noise" bits) but just overwrites the front part that says, "A file starts here" with gibberish and then it will happily overwrite that and the following parts later when you want to use the space. In reality, deleting is the same as writing otherwise.
The thing with disk cleanup, is the things it cleans are usually LOTS of small files (internet cookies, temporary files, etc.). As such, it does a lot more writing to the disk than a lot of other things, and can take as much time as installing something new, due to the volume being written to disk.
The original question specifically asks about Disk Cleanup.
– liljoshu
Dec 26 '15 at 21:59
add a comment |
Deleting 20 files of 5mb in size will take more time to delete than 10 files of 64mb in size. This is because when system deletes files, it doesn't really delete them (as empty space on a drive can be made of "noise" bits) but just overwrites the front part that says, "A file starts here" with gibberish and then it will happily overwrite that and the following parts later when you want to use the space. In reality, deleting is the same as writing otherwise.
The thing with disk cleanup, is the things it cleans are usually LOTS of small files (internet cookies, temporary files, etc.). As such, it does a lot more writing to the disk than a lot of other things, and can take as much time as installing something new, due to the volume being written to disk.
The original question specifically asks about Disk Cleanup.
– liljoshu
Dec 26 '15 at 21:59
add a comment |
Deleting 20 files of 5mb in size will take more time to delete than 10 files of 64mb in size. This is because when system deletes files, it doesn't really delete them (as empty space on a drive can be made of "noise" bits) but just overwrites the front part that says, "A file starts here" with gibberish and then it will happily overwrite that and the following parts later when you want to use the space. In reality, deleting is the same as writing otherwise.
The thing with disk cleanup, is the things it cleans are usually LOTS of small files (internet cookies, temporary files, etc.). As such, it does a lot more writing to the disk than a lot of other things, and can take as much time as installing something new, due to the volume being written to disk.
Deleting 20 files of 5mb in size will take more time to delete than 10 files of 64mb in size. This is because when system deletes files, it doesn't really delete them (as empty space on a drive can be made of "noise" bits) but just overwrites the front part that says, "A file starts here" with gibberish and then it will happily overwrite that and the following parts later when you want to use the space. In reality, deleting is the same as writing otherwise.
The thing with disk cleanup, is the things it cleans are usually LOTS of small files (internet cookies, temporary files, etc.). As such, it does a lot more writing to the disk than a lot of other things, and can take as much time as installing something new, due to the volume being written to disk.
answered Dec 2 '14 at 13:53
liljoshuliljoshu
1517
1517
The original question specifically asks about Disk Cleanup.
– liljoshu
Dec 26 '15 at 21:59
add a comment |
The original question specifically asks about Disk Cleanup.
– liljoshu
Dec 26 '15 at 21:59
The original question specifically asks about Disk Cleanup.
– liljoshu
Dec 26 '15 at 21:59
The original question specifically asks about Disk Cleanup.
– liljoshu
Dec 26 '15 at 21:59
add a comment |
One way to mitigate this problem and speed up the "Windows Update Cleanup" phase of "Disk Cleanup" a bit is to temporarily set a higher priority for the TiWorker.exe process for the duration of the so-called 'cleanup' activity.
In the Task Manager 'Details' pane, find TiWorker.exe
and right-click to show a pop-up menu. For 'Set Priority," choose "Above Normal." For me, this increased the TiWorker
CPU activity--from averaging around 16%--up to its full potential of 25% (on a 4-core machine).
Aside from the miniscule speedup--and possibly good feeling of accomplishment--this provides, there's little that can be done since apparently "Windows Update Cleanup" is coded in a way that, for some unknown reason, proceeds file-by-file, making the overall work horribly disk-bound.
And also, do know that the process is most probably not hung, and will indeed complete someday. To verify this (and to yet further distract yourself during this annoying wait time), you can check the 'Disk Activity' section of Resource Monitor (run "resmon.exe").
Very nice speed up!
– subjectivist
Sep 17 '18 at 20:04
add a comment |
One way to mitigate this problem and speed up the "Windows Update Cleanup" phase of "Disk Cleanup" a bit is to temporarily set a higher priority for the TiWorker.exe process for the duration of the so-called 'cleanup' activity.
In the Task Manager 'Details' pane, find TiWorker.exe
and right-click to show a pop-up menu. For 'Set Priority," choose "Above Normal." For me, this increased the TiWorker
CPU activity--from averaging around 16%--up to its full potential of 25% (on a 4-core machine).
Aside from the miniscule speedup--and possibly good feeling of accomplishment--this provides, there's little that can be done since apparently "Windows Update Cleanup" is coded in a way that, for some unknown reason, proceeds file-by-file, making the overall work horribly disk-bound.
And also, do know that the process is most probably not hung, and will indeed complete someday. To verify this (and to yet further distract yourself during this annoying wait time), you can check the 'Disk Activity' section of Resource Monitor (run "resmon.exe").
Very nice speed up!
– subjectivist
Sep 17 '18 at 20:04
add a comment |
One way to mitigate this problem and speed up the "Windows Update Cleanup" phase of "Disk Cleanup" a bit is to temporarily set a higher priority for the TiWorker.exe process for the duration of the so-called 'cleanup' activity.
In the Task Manager 'Details' pane, find TiWorker.exe
and right-click to show a pop-up menu. For 'Set Priority," choose "Above Normal." For me, this increased the TiWorker
CPU activity--from averaging around 16%--up to its full potential of 25% (on a 4-core machine).
Aside from the miniscule speedup--and possibly good feeling of accomplishment--this provides, there's little that can be done since apparently "Windows Update Cleanup" is coded in a way that, for some unknown reason, proceeds file-by-file, making the overall work horribly disk-bound.
And also, do know that the process is most probably not hung, and will indeed complete someday. To verify this (and to yet further distract yourself during this annoying wait time), you can check the 'Disk Activity' section of Resource Monitor (run "resmon.exe").
One way to mitigate this problem and speed up the "Windows Update Cleanup" phase of "Disk Cleanup" a bit is to temporarily set a higher priority for the TiWorker.exe process for the duration of the so-called 'cleanup' activity.
In the Task Manager 'Details' pane, find TiWorker.exe
and right-click to show a pop-up menu. For 'Set Priority," choose "Above Normal." For me, this increased the TiWorker
CPU activity--from averaging around 16%--up to its full potential of 25% (on a 4-core machine).
Aside from the miniscule speedup--and possibly good feeling of accomplishment--this provides, there's little that can be done since apparently "Windows Update Cleanup" is coded in a way that, for some unknown reason, proceeds file-by-file, making the overall work horribly disk-bound.
And also, do know that the process is most probably not hung, and will indeed complete someday. To verify this (and to yet further distract yourself during this annoying wait time), you can check the 'Disk Activity' section of Resource Monitor (run "resmon.exe").
answered Apr 11 '18 at 0:55
Glenn SlaydenGlenn Slayden
461411
461411
Very nice speed up!
– subjectivist
Sep 17 '18 at 20:04
add a comment |
Very nice speed up!
– subjectivist
Sep 17 '18 at 20:04
Very nice speed up!
– subjectivist
Sep 17 '18 at 20:04
Very nice speed up!
– subjectivist
Sep 17 '18 at 20:04
add a comment |
Another word of warning: part of what takes up the time is that, when cleaning up WinSxS, Disk Clean-up has first to uncompress a lot of files. So disk usage actually increases for the first part of the clean-up!
add a comment |
Another word of warning: part of what takes up the time is that, when cleaning up WinSxS, Disk Clean-up has first to uncompress a lot of files. So disk usage actually increases for the first part of the clean-up!
add a comment |
Another word of warning: part of what takes up the time is that, when cleaning up WinSxS, Disk Clean-up has first to uncompress a lot of files. So disk usage actually increases for the first part of the clean-up!
Another word of warning: part of what takes up the time is that, when cleaning up WinSxS, Disk Clean-up has first to uncompress a lot of files. So disk usage actually increases for the first part of the clean-up!
answered Sep 24 '18 at 12:06
JonPJonP
1011
1011
add a comment |
add a comment |
Another way to speed up the process is to run the Disk Cleanup for about 5 min. Stop it, then re-start it, and it will whizz through in a jiffy! Also, De-Fragging or Optimizing your HDD/SSD beforehand will speed things up, just remember to de-frag/Optz it again after cleanup.
Please don't defragment your SSD it wears out read and write cycles and has almost no gain.
– Nordlys Jeger
Nov 6 '18 at 10:57
@NordlysJeger Windows itself does defrag for SSDs by design
– magicandre1981
Nov 6 '18 at 15:48
my bad, thank you for the info.
– Nordlys Jeger
Nov 6 '18 at 15:50
add a comment |
Another way to speed up the process is to run the Disk Cleanup for about 5 min. Stop it, then re-start it, and it will whizz through in a jiffy! Also, De-Fragging or Optimizing your HDD/SSD beforehand will speed things up, just remember to de-frag/Optz it again after cleanup.
Please don't defragment your SSD it wears out read and write cycles and has almost no gain.
– Nordlys Jeger
Nov 6 '18 at 10:57
@NordlysJeger Windows itself does defrag for SSDs by design
– magicandre1981
Nov 6 '18 at 15:48
my bad, thank you for the info.
– Nordlys Jeger
Nov 6 '18 at 15:50
add a comment |
Another way to speed up the process is to run the Disk Cleanup for about 5 min. Stop it, then re-start it, and it will whizz through in a jiffy! Also, De-Fragging or Optimizing your HDD/SSD beforehand will speed things up, just remember to de-frag/Optz it again after cleanup.
Another way to speed up the process is to run the Disk Cleanup for about 5 min. Stop it, then re-start it, and it will whizz through in a jiffy! Also, De-Fragging or Optimizing your HDD/SSD beforehand will speed things up, just remember to de-frag/Optz it again after cleanup.
answered Nov 6 '18 at 10:35
BluesdigitalBluesdigital
1
1
Please don't defragment your SSD it wears out read and write cycles and has almost no gain.
– Nordlys Jeger
Nov 6 '18 at 10:57
@NordlysJeger Windows itself does defrag for SSDs by design
– magicandre1981
Nov 6 '18 at 15:48
my bad, thank you for the info.
– Nordlys Jeger
Nov 6 '18 at 15:50
add a comment |
Please don't defragment your SSD it wears out read and write cycles and has almost no gain.
– Nordlys Jeger
Nov 6 '18 at 10:57
@NordlysJeger Windows itself does defrag for SSDs by design
– magicandre1981
Nov 6 '18 at 15:48
my bad, thank you for the info.
– Nordlys Jeger
Nov 6 '18 at 15:50
Please don't defragment your SSD it wears out read and write cycles and has almost no gain.
– Nordlys Jeger
Nov 6 '18 at 10:57
Please don't defragment your SSD it wears out read and write cycles and has almost no gain.
– Nordlys Jeger
Nov 6 '18 at 10:57
@NordlysJeger Windows itself does defrag for SSDs by design
– magicandre1981
Nov 6 '18 at 15:48
@NordlysJeger Windows itself does defrag for SSDs by design
– magicandre1981
Nov 6 '18 at 15:48
my bad, thank you for the info.
– Nordlys Jeger
Nov 6 '18 at 15:50
my bad, thank you for the info.
– Nordlys Jeger
Nov 6 '18 at 15:50
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f847556%2fwhy-does-disk-cleanup-take-so-much-time-and-cpu%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown