ディスククリーンアップに時間とCPUがかかるのはなぜですか？
ただの好奇心の質問です。ディスククリーンアップは私のコアの1つの100％をかなり長い間費やしていて、まだ行っています。特にWindows Updateのクリーンアップに多くの時間を費やしているようです。
なぜファイルを削除するのがそんなに集中的な活動であるべきか理解できません。特にそれはすでにそれが削除できるものを計算するのにかなりの時間を費やしたので。
ディスククリーンアップに時間とCPUがかかるのはなぜですか？それはそれが何をするのですか？
Windowsは、置き換えられた更新を削除し、アンインストールできず、差分に使用されていないファイルを圧縮することによって、WinSxSフォルダを圧縮します。これは多くのCPUパワーを必要とし、それであなたは高いCPU使用率を見る理由です。
これを確認するには、 xperf/WPA を使用してCPU使用率を分析します。
私は、Windows Updates Cleanupがほぼ100％のCPU使用率を要することを確認できます。それは、WinSxSの圧縮と更新プログラムの再統合に関するすべてです。
私はWindowsのインストール後に初めてクリーンアップを始めました、そしてそれは50％を終えるのに2時間かかりました。グラフから、ディスクから小さなファイルを最初に読み込むとき（2番目のグラフ）、そして100％のCPU使用率が圧縮された後などにわかります。
この問題を軽減し、「ディスクのクリーンアップ」の「Windows Updateのクリーンアップ」フェーズを少しスピードアップする1つの方法は、一時的にTiWorker.exeプロセスの優先順位を高く設定することです。いわゆる「クリーンアップ」活動の期間。
タスクマネージャの[詳細]ウィンドウで、TiWorker.exeを見つけて右クリックし、ポップアップメニューを表示します。 「優先順位の設定」で、「通常より上」を選択します。私にとっては、これによってTiWorkerのCPU使用率が平均約16％から最大で25％（4コアマシンの場合）まで増加しました。
非常に速いスピードアップ、そしておそらく達成感の良さを除けば、明らかに "Windows Update Cleanup"は何らかの理由でファイルごとに処理されるようにコーディングされているので、できることはほとんどありません。全体的な作業をひどくディスクバウンドにします。
そしてまた、そのプロセスがおそらくnotハングしていて、確かにいつの日か完了することを知っていますか。これを確認するには（そしてこの厄介な待ち時間の間にさらに気を散らすために）、Resource Monitorの "Disk Activity"セクションをチェックします（ "resmon.exe"を実行します）。
問題に火を付けるために、私は次のステップで不変の仮想マシンでやっていました：
- SystemRescueCDを起動してwindowsパーティションをマウントします
- ディスク上のすべてのファイルをログファイルに一覧表示します（1分以内）
- Windowsで再起動
cleanmgrに任せ、時間を記録してください（8時間以上）。- SystemRescueCDを再起動してwindowsパーティションをマウントします。
- ディスク上のすべてのファイルを別のログファイルに一覧表示する（1分以内）
- 不変仮想マシンをリセットします。
- Windowsで再起動
- FOR/F ...を実行して、管理コマンドのプロンプトでそのようなファイルを削除し（cmd）、時間を記録してください（5分以内）。
私はLinux SystemRescueCdを再起動して、すべてのファイルをリストできるようにするために、またWindowによって見られるものもできるようにし、そしてそのようなリストをできるだけ速くすることもできるようにしました。
また、cleanmgrでは、検索終了後の時間のみをカウントします（検索自体も6時間以上かかります）。
そのため、ファイルを削除するのはボトルネックではありません（削除自体は5分で済みますが、cleanmgrは8時間以上かかります）。
HostはLinuxなので、自分で削除するのは非常に高速です。Linuxは仮想マシン（24GiB）のディスクとして使用されている固定サイズのファイルにすべての書き込みをキャッシュしているからです。 RAMと私はそれがSWAPもPAGEFILE.SYSもSWAPを使用する必要はないWindows 16GiBにしましょう。さらに、LinuxはRAMにフルファイルを保持できます（私はRAMでそのファイルをテストしましたが、削除回数は多くなりますが、cleanmgr時間は短くなりません）。
はい、仮想ディスクを完全にRAMに配置してもcleanmgrの時間は短くなりませんが、手動でファイルを削除すると、その時間は少しだけ短くなります（64 GBのRAMがある場合、Linuxの書き込みキャッシュは素晴らしいです）それに）。
テスト用の私の設定：
- ホスト：Linux 64ビットは、主要部分が64GiBのRAMを備えたAMD Deca Core 5GHz、および2台のWD VelociRaptor HDDを備えたSata Raid0コントローラー（約1GiB/sの合計安全書き込み速度を維持できる） 300MiB/sの4Kランダム書き込み。費用は> 1万ユーロ
- ゲスト：16 GBのRAMと24 GBの仮想ディスクを備えたWindows 10 Home
テスト1：24GiBの仮想ディスクを物理ハードディスクに配置するテスト2：24GiBの仮想ディスクをLinuxホストRAMに配置する
私はcleanmgrがそれが削除する各ファイルごとにwindowsレジストリで何かをしていることを恐れています（レジストリへのアクセスは非常に低いです）。
私が持っていたモニター：
- LinuxホストおよびWindowsゲストでのCPU使用率（ほとんどの時間は0％から1％の間で、5％のパイクで、これ以上はなし）
- LinuxホストでのHDD使用率（
cleanmgrが動作しているときは0％近く、2％の上昇率で）、Linuxディスクキャッシュはデータが実際のディスクに送信されるのを避けて本当に素晴らしいです - WindowsゲストでのHDD使用量（
cleanmgrが機能していたときの時間は2％から15％の間で、最大28％）。
それで明らかにcleanmgrは検出できない仕事をたくさんしています、おそらく睡眠時間ですか？たぶん、それがアクセスしているレジストリであるならば、そのためのCPUはWindowsモニタによって数えられません、その上のHDDは使われません（レジストリはRAMにあります）、そしてレジストリへの各アクセスは1秒以上かかることができます。あなた自身のプログラムを試してみましょう。レジストリを開いて、各アクションごとにそれを閉じるのではなく、HK *を開かせて...それは大きな違いです。
cleanmgrが各ファイルに対して行うと、
- オープンレジストリHK *
- どんなニーズにも相談したり、レジストリに書き込みをしたりします。
- レジストリを閉じるHK *
1回の操作で最大2、3秒かかることがありますが、ファイルごとに1回操作すると、1,000ファイルごとに1時間近くかかることがあります。私のファイル数は、40000ファイルを少し上回る程度でした。つまり、40000ファイル/ 8時間は1.3秒ごとに1つのファイルを処理しています。反対側では、スクリプトでそれらを削除すると（5分以内に）5分もかからず、毎秒133個ほど削除されます。差。
だからcleanmgr時間は絶対にdeletionが原因ではありません。他に何をしていますか？ M $そのスピードを上げてください！
サイズが5MBのファイルを20個削除すると、サイズが64MBのファイルを10個削除するよりも時間がかかります。これは、システムがファイルを削除しても、実際には削除されないためです（ドライブの空きスペースに「ノイズ」ビットが含まれる可能性があるため）。 「ファイルはここから始まります」と書かれている前の部分をちょっとぎこちない文字で上書きするだけで、あとでスペースを使いたいときに、それ以降の部分がうまく上書きされます。実際には、削除は他の方法で書くのと同じです。
ディスクのクリーンアップに関することは、それがきれいにするものが通常小さいファイル（インターネットクッキー、一時ファイルなど）がたくさんあることです。そのため、他の多くのことよりもディスクへの書き込みが多くなり、ボリュームがディスクに書き込まれるため、何か新しいものをインストールするのと同じくらいの時間がかかります。
もう1つの警告：時間がかかるのは、WinSxSをクリーンアップするとき、最初にディスククリーンアップが多くのファイルを解凍することです。そのため、クリーンアップの最初の部分でディスク使用量が実際に増えます。