Un script PowerShell pour trouver la taille du fichier et le nombre de fichiers d'un dossier avec des millions de fichiers?

Le but du script est le suivant:

Imprimer le nombre de fichiers de manière récursive trouvé à l'intérieur d'un répertoire
(en omettant les dossiers eux-mêmes)
Imprimer le total de la somme de la taille du fichier de l'annuaire
Pas le plantage de l'ordinateur en raison du massif de l'utilisation de la mémoire.

Jusqu'à présent (3) est la partie la plus difficile.

Voici ce que j'ai écrit et testé jusqu'à présent. Cela fonctionne parfaitement bien sur les dossiers avec une centaines, voire un millier de fichiers:

$hostname=hostname
$directory = "foo"
$dteCurrentDate = Get-Date –f "yyyy/MM/dd"

$FolderItems = Get-ChildItem $directory -recurse
$Measurement = $FolderItems | Measure-Object -property length -sum
$colitems = $FolderItems | measure-Object -property length -sum
"$hostname;{0:N2}" -f ($colitems.sum / 1MB) + "MB;" + $Measurement.count + " files;" + "$dteCurrentDate"

Sur les dossiers avec des millions de fichiers, cependant, la $colitems variable devient tellement énorme de la collecte de l'information des millions de fichiers qu'il rend le système instable. Est-il un moyen plus efficace pour attirer et de stocker cette information?

InformationsquelleAutor Stephen Wood | 2011-08-16

powershell sum

36

Si vous utilisez le streaming et le pipelining, vous devriez réduire le problème avec (3) beaucoup, parce que lorsque le flux de, chaque objet est transmis le long de la conduite et, lorsqu'ils sont disponibles et ne prennent pas beaucoup de mémoire et vous devriez être en mesure de traiter des millions de fichiers (même s'il faudra du temps).
```
Get-ChildItem $directory -recurse | Measure-Object -property length -sum
```
Je ne crois pas @Stej déclaration de l' Get-ChildItem probably reads all entries in the directory and then begins pushing them to the pipeline., c'est vrai. Le Pipelining est un concept fondamental de PowerShell (fournir les applets de commande, scripts, etc. soutenir). Il assure à la fois que les objets traités sont transmis le long de la canalisation, un par un comme et quand ils sont disponibles et aussi, seulement quand ils sont nécessaires. Get-ChildItem ne va pas se comporter différemment.

Un grand exemple de ceci est donné dans La compréhension du Pipeline de Windows PowerShell.

Citer, de:

L'Hôte de Pagination commande est utile élément de pipeline à chaque fois que vous
avoir de longues sortie que vous souhaitez afficher lentement. Il est
particulièrement utile si l'opération est très gourmand en temps PROCESSEUR. Parce que
le traitement est transféré à l'ordinateur Hôte cmdlet quand il a un
page complète prête à l'affichage, des applets de commande qui la précèdent dans le
pipeline en interrompre le fonctionnement jusqu'à ce que la page suivante de la sortie est disponible.
Vous pouvez voir ceci si vous utilisez le Gestionnaire des Tâches de Windows pour surveiller CPU
et l'utilisation de la mémoire par Windows PowerShell.

Exécutez la commande suivante: Get-ChildItem C:\Windows -Recurse.
Comparer le CPU et la mémoire d'utilisation de cette commande: Get-ChildItem C:\Windows -Recurse | Out-Host -Paging.

De référence sur l'utilisation de Get-ChildItem sur c:\ (environ 179516 des fichiers, pas des millions mais assez bien):

L'utilisation de la mémoire après l'exécution de $a = gci c:\ -recurse (et ensuite de faire $a.count) a été 527,332K.

L'utilisation de la mémoire après l'exécution de gci c:\ -recurse | measure-object était 59,452K et n'est jamais allé au-dessus autour de 80,000K.

(Mémoire de Travail Privé - de TaskManager, voir mémoire de la powershell.exe processus. Initialement, il était sur le 22,000K.)

J'ai aussi essayé avec deux millions de fichiers (il m'a fallu un certain temps pour les créer!)

Expérience similaire:

L'utilisation de la mémoire après l'exécution de $a = gci c:\ -recurse ( et ensuite de faire $a.count ) a été 2,808,508K.

L'utilisation de la mémoire lors de l'exécution de gci c:\ -recurse | measure-object était 308,060K et n'est jamais allé au-dessus autour de 400,000K. Après avoir fini, il fallait faire un [GC]::Collect() pour retourner à la 22,000K niveaux.

Je suis toujours convaincu que Get-ChildItem et pipelining, vous pouvez obtenir en grande mémoire des améliorations, même pour des millions de fichiers.
- Get-ChildItem effectivement se comporte différemment.
- Vous pouvez ajouter la -force drapeau à Get-ChildItem de sorte qu'il sera lu système et les fichiers cachés (je déteste cette "fonctionnalité").
- J'ai comparé l'utilisation de la mémoire. Pouvez-vous essayer la même chose, depuis ma mise à jour de réponse?
- L'utilisation de la mémoire est presque constante pour les ..|measure-object. Mais c'est vrai pour le cas où les répertoires n'ont pas des milliers/millions de fichiers. gci à l'intérieur d'appels standard .NET GetFiles et qui est assez bon marché (dans l'utilisation de la mémoire) pour nos conditions. Cependant, il est beaucoup plus différent que les conditions qui s'appliquent pour @stephen mesures (en millions de fichiers dans un répertoire).
InformationsquelleAutor manojlds
10

Get-ChildItem probablement lit toutes les entrées dans le répertoire, puis commence à le pousser à la conduite. Dans le cas où Get-ChildItem ne fonctionne pas bien, essayez de passer .NET 4.0 et l'utilisation de EnumerateFiles et EnumeratedDirectories:
```
function Get-HugeDirStats($directory) {
    function go($dir, $stats)
    {
        foreach ($f in [system.io.Directory]::EnumerateFiles($dir))
        {
            $stats.Count++
            $stats.Size += (New-Object io.FileInfo $f).Length
        }
        foreach ($d in [system.io.directory]::EnumerateDirectories($dir))
        {
            go $d $stats
        }
    }
    $statistics = New-Object PsObject -Property @{Count = 0; Size = [long]0 }
    go $directory $statistics

    $statistics
}

#example
$stats = Get-HugeDirStats c:\windows
```
Ici la partie la plus coûteuse est l'un avec de l' New-Object io.FileInfo $f, parce que EnumerateFiles retourne uniquement les noms de fichiers. Donc, si seulement le comte de fichiers est assez, vous pouvez mettre en commentaire la ligne.

Voir Débordement de Pile question Comment puis-je lancer PowerShell avec le .NET 4 runtime?
pour apprendre à l'utiliser .NET 4.0.

Vous pouvez également utiliser de la plaine de vieilles méthodes qui sont aussi rapides, mais à lire tous les fichiers dans le répertoire. Donc, cela dépend de vos besoins, il suffit de l'essayer. Plus tard, il y a comparaison de toutes les méthodes.
```
function Get-HugeDirStats2($directory) {
    function go($dir, $stats)
    {
        foreach ($f in $dir.GetFiles())
        {
            $stats.Count++
            $stats.Size += $f.Length
        }
        foreach ($d in $dir.GetDirectories())
        {
            go $d $stats
        }
    }
    $statistics = New-Object PsObject -Property @{Count = 0; Size = [long]0 }
    go (new-object IO.DirectoryInfo $directory) $statistics

    $statistics
}
```
Comparaison:
```
Measure-Command { $stats = Get-HugeDirStats c:\windows }
Measure-Command { $stats = Get-HugeDirStats2 c:\windows }
Measure-Command { Get-ChildItem c:\windows -recurse | Measure-Object -property length -sum }
TotalSeconds      : 64,2217378
...

TotalSeconds      : 12,5851008
...

TotalSeconds      : 20,4329362
...
```
@manojlds: le Pipelining est un concept fondamental. Mais en tant que concept, il n'a rien à voir avec les fournisseurs. Le fournisseur de système de fichiers s'appuie sur l' .NET mise en œuvre (.NET 2.0) qui n'a pas de paresseux capacités en matière d'évaluation (~ agents recenseurs). Vérifiez que vous-même.
- une bonne solution de mettre être prudent de changer de .Net comme dans ce thread - vous êtes standard\PowerShell v2 ne fonctionne pas avec toutes les fonctionnalités (y compris l'accès distant). Mieux de copier le dossier et de faire les changements, l'appel de cette PS uniquement lorsque vous avez besoin d'utiliser la v4. Ils font un travail en parallèle.
- - Je exécuter PowerShell sous .NET 4.0 pour des mois et n'ont aucun problème. (modifié le fichier de config)
- l'accès distant fonctionne ok? c'est cool. J'ai eu des questions à propos de 3-4 mois - je me demande si je n'étais pas à l'aide de la dernière version de .net v4.
- J'ai utiliser l'accès distant de temps à autre entre Win7<->Win server 2008 et ça fonctionne 🙂 à Essayer de nouveau, j'espère que ce sera ok.
- Comme un C# dev, je suis d'accord avec vous et c'est comment j'allais le faire en C#. Mais je voudrais voir si Get-childItem peut en effet faire le travail. Pouvez-vous essayer les commandes que j'ai fait dans ma mise à jour de réponse et à mesure de l'utilisation de la mémoire?
- Aussi, je crois que le temps n'est pas aussi beaucoup d'inquiétude que l'utilisation de la mémoire et du PROCESSEUR. Au moins à partir de (3) que l'opération mentionnée.
InformationsquelleAutor stej
1

La fonction suivante est assez cool et est rapide à calculer la taille d'un dossier, mais il ne fonctionne pas toujours (surtout quand il y a un problème de permission ou d'un trop long chemin d'accès au dossier).
```
Function sizeFolder($path) # Return the size in MB.
{
    $objFSO = New-Object -com  Scripting.FileSystemObject
    ("{0:N2}" -f (($objFSO.GetFolder($path).Size) / 1MB))
}
```
- Est-il un moyen de contourner les limitations?
InformationsquelleAutor fretman92

Vous devez vous connecter pour publier un commentaire.