Performances lentes sur le lecteur NTFS avec un grand nombre de fichiers

Je regarde cette configuration:

• Windows Server 2012
• Disque NTFS 1 To, grappes de 4 Ko, ~ 90% plein
• ~ 10 millions de fichiers stockés dans 10 000 dossiers = ~ 1 000 fichiers / dossier
• Fichiers généralement assez petits <50 Ko
• Disque virtuel hébergé sur une baie de disques

Lorsqu'une application accède à des fichiers stockés dans des dossiers aléatoires, il faut 60 à 100 ms pour lire chaque fichier. Avec un outil de test, il semble que le retard se produit lors de l'ouverture du fichier. La lecture des données ne prend alors qu'une fraction du temps.

En résumé, cela signifie que la lecture de 50 fichiers peut facilement prendre de 3 à 4 secondes, ce qui est beaucoup plus que prévu. L'écriture se fait en batch donc les performances ne sont pas un problème ici.

J'ai déjà suivi les conseils sur SO et SF pour arriver à ces chiffres.

• Utilisation de dossiers pour réduire le nombre de fichiers par dossier ( Stockage d'un million d'images dans le système de fichiers )
• Exécuter contigpour défragmenter les dossiers et fichiers ( /programming//a/291292/1059776 )
• 8.3 noms et dernière heure d'accès désactivés ( Configuration du système de fichiers NTFS pour les performances )

Que faire des heures de lecture?

• Considérez que 60 à 100 ms par fichier sont corrects (ce n'est pas le cas, n'est-ce pas?)
• Des idées sur la façon dont la configuration peut être améliorée?
• Existe-t-il des outils de surveillance de bas niveau qui peuvent indiquer à quoi exactement le temps est consacré?

METTRE À JOUR

1. Comme mentionné dans les commentaires, le système exécute Symantec Endpoint Protection. Cependant, sa désactivation ne modifie pas les temps de lecture.

2. PerfMon mesure 10-20 ms par lecture. Cela signifierait que tout fichier lu prend ~ 6 opérations de lecture d'E / S, non? Serait-ce une recherche MFT et des contrôles ACL?

3. Le MFT a une taille de ~ 8,5 Go, ce qui est plus que la mémoire principale.

Le serveur n'avait pas assez de mémoire. Au lieu de mettre en cache les données du métafichier NTFS en mémoire, chaque accès aux fichiers nécessitait plusieurs lectures de disque. Comme d'habitude, le problème est évident une fois que vous le voyez. Permettez-moi de partager ce qui a obscurci ma perspective:

• Le serveur a montré 2 Go de mémoire disponible à la fois dans le Gestionnaire des tâches et RamMap. Ainsi, Windows a décidé que la mémoire disponible n'était pas suffisante pour contenir une partie significative des données du métafichier. Ou une restriction interne ne permet pas d'utiliser le dernier bit de mémoire pour les données de métafichier.

• Après la mise à niveau, le gestionnaire de tâches RAM n'afficherait pas plus de mémoire utilisée. Cependant, RamMap a signalé que plusieurs Go de données de métafichier étaient conservés en tant que données de secours. Apparemment, les données de secours peuvent avoir un impact substantiel.

Outils utilisés pour l'analyse:

• fsutil fsinfo ntfsinfo driveletter:pour afficher la taille NTFS MFT (ou NTFSInfo )
• RamMap pour afficher l'allocation de mémoire
• Moniteur de processus pour montrer que chaque fichier lu est précédé d'environ 4 opérations de lecture sur le lecteur: \ $ Mft et le lecteur: \ $ Directory. Bien que je n'aie pas pu trouver la définition exacte de $ Directory, elle semble également être liée à la MFT .