Eine bessere Methode zur Berechnung der Dateigröße von 32 Dateien für die DFS-Ordner-Staging-Größe

Question

Eine gängige Aufgabe beim Einrichten einer DFS-Replik besteht darin, die Größe der 32 größten Dateien im replizierten Ordner zu ermitteln Mindestgröße des Bereitstellungsbereichs gemäß aktueller Best Practice.

Verfahren zu finden, und die Berechnung dieser Top-32-Dateigröße in einem Technet Blog gegeben: https://blogs.technet.microsoft.com/askds/2011/07/13/how-to-determine-the-minimum-staging-area-dfsr-needs-for-a-replicated-folder/

weiterverwenden Get-ChildItem verlässt sich alle Dateien und deren Größe in einem Pfad zu finden, sortiert nach Größe, verwerfen alle aber die 32 größten, und dann berechnen Sie die Summe.

Es ist in Ordnung, wenn Sie eine begrenzte Anzahl von Dateien in Ihrem Pfad haben, aber es gibt schwerwiegende Nachteile beim Indexieren eines Ordners mit Hunderttausenden, wenn nicht Millionen von Dateien. Der Prozess speichert während der Ausführung alles in den Speicher - in meinem Beispiel verbraucht er mehr als 2 GB virtuellen Speicher - und benötigt viel Zeit, selbst wenn die einzelnen Dateien sehr klein sind. Der Speicher bleibt zugewiesen, bis die PS-Instanz geschlossen wird.

PS C:\> measure-command { (get-childitem F:\Folder\with\966693\items -recurse | 
sort-object length -descending | select-object -first 32 | 
measure-object -property length -sum).sum } 
Days    : 0 
Hours    : 0 
Minutes   : 6 
Seconds   : 6 
Milliseconds  : 641 
Ticks    : 3666410633 
TotalDays   : 0.00424353082523148 
TotalHours  : 0.101844739805556 
TotalMinutes  : 6.11068438833333 
TotalSeconds  : 366.6410633 
TotalMilliseconds : 366641.0633 

Answer 1

Mit einem leichten Zwicken - ein System.Collections.ArrayList Instanziieren der Liste der Dateilängen zu speichern - die Zeit, die Abfrage über das gleiche Verzeichnis auszuführen ist nahezu halbiert. Du bist not constantly creating/destroying a standard fixed-sized array, während du ein neues Element hinzufügst.

Die Speicherauslastung für den Powershell-Prozess für dieses Beispiel bleibt unter 900 MB. Ich mag auch, dass eine Variable auf $ null gesetzt wird, wenn ich die PS-Konsole wiederverwenden möchte.

measure command { $total = New-Object System.Collections.ArrayList; 
gci F:\Folder\with\966693\items -file -r | 
ForEach { $total.Add($_.length)>$null } ; 
(($total | sort -descending | select -first 32 |measure-object -sum).sum/1GB) } 
Days    : 0 
Hours    : 0 
Minutes   : 3 
Seconds   : 34 
Milliseconds  : 215 
Ticks    : 2142159038 
TotalDays   : 0.00247935073842593 
TotalHours  : 0.0595044177222222 
TotalMinutes  : 3.57026506333333 
TotalSeconds  : 214.2159038 
TotalMilliseconds : 214215.9038 

aufgeräumter mehrzeiligen Version:

$total = New-Object System.Collections.ArrayList 
gci F:\Folder\with\966693\items -file -r | ForEach { $total.Add($_.length)>$null } 
($total | sort -descending | select -first 32 | measure-object -sum).sum/1GB 

Answer 2

Ich wäre überrascht, wenn Sie viel Get-ChildItem beschleunigen könnte, es sei denn, Sie vermeiden könnte [IO.FileInfo] Objekte für jede Datei den Bau (.NET Directory vielleicht?) .

Aber Sie könnten in der Lage sein, die Speicheranforderungen zu reduzieren, indem Sie nicht alle Ergebnisse behalten, nur die laufenden N größten, 100 in diesem Beispiel, aber anpassen, um Speicher/Leistung z.

$BufferSize = 100 
$FileSizes = New-Object System.Collections.ArrayList 

Get-ChildItem 'd:\downloads' -Force -Recurse -File | ForEach { 

    $null = $FileSizes.Add($_.Length) 
    if ($FileSizes.Count -gt $BufferSize) 
    { 
     $FileSizes.Sort() 
     $FileSizes.RemoveRange(0, ($BufferSize-32)) 
    } 
} 
($FileSizes[0..31] | measure-object -Sum).Sum/1GB 

Added -Force Parameter bei einigen der größten Dateien GCI sind versteckt.