ディスククリーンアップに時間がかかるのはなぜですか？

好奇心の質問です。ディスククリーンアップは、かなり長い間、コアの1つを100％使用し続けています。特にWindows Updateのクリーンアップに多くの時間を費やしているようです。

ファイルの削除がこのような集中的なアクティビティである理由を理解することはできません。特に、削除できるものを計算するのにすでにかなりの時間を費やしていたためです。

ディスククリーンアップに時間がかかるのはなぜですか？それは何がそんなに集中的ですか？

Windowsは、置き換えられた更新を削除してWinSxSフォルダーを圧縮し、アンインストールできず、差分に使用されていないファイルを圧縮します。これには多くのCPUパワーが必要であるため、CPU使用率が高くなります。

あなたはできるXperfは/ WPAとCPUの使用状況を分析し、これを検証します。

Windows Updates CleanupのCPU使用率はほぼ100％であり、WinSxSの圧縮と更新の再統合がすべてであることを確認できます。

Windowsのインストール後に初めてクリーンアップを開始し、50％を完了するのに2時間かかりました。グラフから、ディスクからの小さなファイルの最初の読み取り（2番目のグラフ）、および圧縮のためのCPU使用率が100％になった後などがわかります。

質問に火をつけるために、不変の仮想マシンで次のステップを実行しました。

1. SystemRescueCDを起動し、Windowsパーティションをマウントします
2. ディスク上のすべてのファイルをログファイルに一覧表示する（1分未満）
3. Windowsを再起動します
4. させて cleanmgrその仕事をして時間をメモを取る（8時間以上）
5. SystemRescueCDを再起動し、Windowsパーティションをマウントします
6. ディスク上のすべてのファイルを別のログファイルにリストする（1分未満）
7. 不変の仮想マシンをリセットして戻す
8. Windowsを再起動します
9. FOR / F ...を実行して、管理コマンドプロンプト（cmd）でそのようなファイルを削除し、時間（5分未満）をメモします。

Linux SystemRescueCdを再起動すると、すべてのファイルを一覧表示できるようになります。また、Windowで表示されたファイルも一覧表示し、可能な限り高速に一覧表示できるようになりました（aclチェックなしなど）。

また、cleanmgriでは検索が終了した後のみ時間をカウントすることに注意してください（検索自体も6時間以上かかりました）。

そのため、ファイルを削除するのはそれほど難しいことではありません（削除自体は5分しか必要ありませんが、cleanmgr8時間以上かかります）。

ホストはLinuxであるため、削除自体は非常に高速に実行できます。その速度は、Linuxが仮想マシン（24GiB）のディスクとして使用される固定サイズファイルへのすべての書き込みをキャッシュするためです。 RAMと私はWindows 16GiBにSWAPもPAGEFILE.SYSも使用する必要はありません。さらに、LinuxはRAM上のファイル全体を保持できます（RAM上のそのファイルでテストし、削除時間は非常に多くなりますが、cleanmgr時間は落ちません）。

はい、仮想ディスクを完全にRAMに置いてcleanmgrも時間は減りませんが、ファイルを手動で削除すると、その時間は少し下がります（64GiBのRAMがある場合、Linuxの書き込みキャッシュは素晴らしいです）。

テスト用の私の構成：

• ホスト：64GiBのRAMを搭載したAMD Deca Core 5GHzと2つのWD VelociRaptor HDDを搭載したSata Raid0コントローラー（1GiB / sに近い連続書き込み速度と4Kのランダム書き込みを維持できる） 300MiB / s）; 費用は1万ユーロを超える
• ゲスト：16GiBのRAMと24GiBの仮想ディスクを備えたWindows 10 Home

Test1：物理ハードディスクに24GiB仮想ディスクを配置Test2：LinuxホストRAMに24GiB仮想ディスクを配置

私はcleanmgrそれが削除するファイルごとにWindowsレジストリで何かをしていることを恐れています（レジストリへのアクセスは非常に低いです）。

私が持っていたモニター：

• LinuxホストおよびWindowsゲストでのCPU使用率（ほとんどの時間は0％から1％の間、5％のパイクで、それ以上ではありません）
• LinuxホストでのHDD使用量（動作していたとき0％近くcleanmgr、2％のパイク）、Linuxディスクキャッシュは、実ディスクに送信されるデータを回避するのに非常に優れています
• WindowsゲストでのHDD使用量（ほとんどの時間cleanmgrは作業中に2％から15％の間で、28％のパイクがありました）

明らかにcleanmgr、多くの検出できない仕事をしているのでしょうか、おそらく睡眠時間ですか？レジストリにアクセスしている場合、そのためのCPUはWindowsモニター、使用されていないHDD（レジストリはRAM上にある）などによってカウントされず、レジストリへの各アクセスには1秒以上かかる場合があります。 。独自のプログラムを試してレジストリにアクセスし、各アクションごとにレジストリを開いて、HK *を開いてください...これは大きな違いです。

したがってcleanmgr、各ファイルで次のようになります：

1. レジストリHK *を開く
2. ニーズを調べたり、レジストリに何らかの書き込みを行ったりします
3. レジストリHK *を閉じる

1つの操作につき2〜3秒かかることがあり、ファイルごとに1つの操作を行う場合、1000ファイルごとに1時間近くかかることがあります。ファイルの数は40000ファイルを少し超えていました。したがって、40000ファイル/ 8時間で1.3秒ごとに1つのファイルが処理されます...反対側では、スクリプトでそれらを削除する（ファイルを知った後）には5分もかかりませんでした。差。

したがって、cleanmgr時間はそれ自体によって引き起こされるわけではありませんdeletion！他に何をしていますか？M $でその速度を改善してください！

この問題を軽減し、「ディスククリーンアップ」の「Windows Updateクリーンアップ」フェーズを少しスピードアップする1つの方法は、いわゆる「クリーンアップ」アクティビティの期間、TiWorker.exeプロセスの一時的に高い優先度を設定することです。

でタスクマネージャー「詳細」ペイン、見つけTiWorker.exeて、ポップアップメニューを表示するには右クリックします。「優先度の設定」で「通常より上」を選択します。私にとっては、これによりTiWorkerCPUアクティビティが増加し、平均で約16％から最大の潜在能力である25％（4コアマシン上）になりました。

わずかな高速化（およびおそらく達成感が良い）を別にすれば、「Windows Updateクリーンアップ」は何らかの理由でファイルごとに処理されるようにコーディングされているため、できることはほとんどありません。全体の作業がひどくディスクに縛られています。

また、プロセスはおそらくハングしておらず、実際にいつか完了することを知っています。これを確認するには（そして、この厄介な待ち時間中にさらに気を散らすために）、リソースモニターの「ディスクアクティビティ」セクションを確認できます（「resmon.exe」を実行します）。

サイズが5 MBの20個のファイルを削除すると、サイズが64 MBの10個のファイルよりも削除に時間がかかります。これは、システムがファイルを削除するとき、実際にはそれらを削除しないためです（ドライブの空のスペースは「ノイズ」ビットで構成されているため）。後でスペースを使用するときに、その部分と次の部分を上書きします。実際には、削除はそれ以外の場合の書き込みと同じです。

ディスククリーンアップで問題になるのは、通常、大量の小さなファイル（インターネットCookie、一時ファイルなど）がクリーンアップされることです。そのため、ディスクへの書き込みは他の多くのものよりもはるかに多く、ボリュームがディスクに書き込まれるため、何か新しいものをインストールするのと同じくらい時間がかかります。

警告の別の言葉：時間を要することの一部は、WinSxSをクリーンアップするとき、ディスククリーンアップは最初に多くのファイルを圧縮解除する必要があるということです。したがって、クリーンアップの最初の部分でディスク使用量が実際に増加します！

プロセスを高速化する別の方法は、ディスククリーンアップを約5分間実行することです。停止してから再起動してください。また、事前にHDD / SSDのデフラグまたは最適化を行うと速度が向上します。クリーンアップ後に再度デフラグ/オプトすることを忘れないでください。