La vitesse de copie SMB chute avec des milliers de petits fichiers : que devez-vous tester en premier ?
Testez si c’est le nombre de fichiers, et non la vitesse du lien, qui déclenche le problème avant de modifier les paramètres SMB ou réseau.
Sur un NAS domestique, des milliers de petits fichiers obligent le client et le serveur à répéter la recherche de chemin, les vérifications de permissions, les ouvertures, créations, mises à jour des métadonnées, fermetures, et le scan côté application pour chaque objet. Un lien gigabit ou 2,5 GbE peut rester majoritairement inactif alors que la copie avance au ralenti, donc la première étape utile est un test A/B qui maintient un volume total de données similaire mais modifie le nombre d’objets, suivi de tests de stockage, client et outil de copie dans un ordre fixe.
Comparez Un Gros Fichier Avec le Même Volume en Petits Fichiers
Créez deux ensembles de test sur le même stockage source : un gros fichier et un dossier contenant des milliers de petits fichiers d’une taille totale approximativement identique. Copiez les deux vers le même partage NAS en utilisant le même client, chemin SMB et fenêtre temporelle.
Un rapport d’utilisateur TrueNAS montre le schéma caractéristique du ralentissement SMB avec petits fichiers tandis que les gros fichiers restent proches de la vitesse réseau normale. Ce contraste est plus utile qu’un simple chiffre de vitesse car il prouve que la nature de la charge modifie le goulot d’étranglement.
Notez le temps écoulé, le nombre total de fichiers, le total d’octets, les fichiers par seconde, la moyenne en Mo/s, et si le ralentissement commence immédiatement ou seulement après le remplissage du cache. Si les deux ensembles sont lents, examinez d’abord le réseau ou le chemin de stockage général ; si seul l’ensemble de petits fichiers ralentit, poursuivez avec des tests centrés sur les métadonnées.
Distinguez la Capacité Réseau du Travail Par Fichier
Effectuez un test réseau mémoire-à-mémoire entre le même client et le NAS, puis comparez-le avec le résultat SMB du gros fichier. Un test réseau propre et une copie rapide de gros fichier montrent que le lien peut transporter les données même si la charge de petits fichiers ne peut pas le saturer.
Les petits fichiers transforment la copie en un travail répété de requêtes et réponses. Eclectic Light a documenté comment les sauvegardes SMB lourdes en métadonnées peuvent durer étonnamment longtemps même lorsque peu de données utiles circulent.
Ne réagissez pas à ce résultat en modifiant d’abord le MTU, le duplex ou l’agrégation de liens. Suivez plutôt les fichiers par seconde et la latence chargée ; la question suivante utile est de savoir si le travail répété attend la source, la destination NAS, ou une inspection côté client.
Testez Séparément la Latence des Métadonnées Source et Destination
Copiez l’ensemble de petits fichiers depuis la source vers un autre dossier local sur le client, puis créez ou extrayez le même ensemble localement sur le NAS. Ces deux tests isolent les lectures source et les créations NAS sans SMB entre les deux.
Une discussion directe sur Unraid a mesuré des opérations lentes par fichier qui n’étaient pas visibles lors des transferts de gros fichiers. Le signal important est de savoir si la création locale de destination est déjà lente avant que le réseau n’intervienne.
Si la copie locale client est lente, inspectez le disque source, le système de fichiers, le chiffrement et la disposition des fichiers. Si la création locale NAS est lente, inspectez le pool de destination, le niveau de cache, le chemin de parité, la fragmentation de l’espace libre, le dispositif de métadonnées et le comportement d’écriture synchrone avant d’ajuster SMB.
Mesurez le Scan de Sécurité et l’Indexation sur les Deux Points
Antivirus, protection des points de terminaison, génération de vignettes, indexation de contenu, observateurs de synchronisation et scanners médias peuvent inspecter chaque nouveau fichier. Leur coût fixe par objet peut dominer une charge qui crée rapidement des milliers d’éléments.
Effectuez un test contrôlé en excluant temporairement le scan et l’indexation en temps réel uniquement pour le dossier de test dédié, puis rétablissez immédiatement la protection. Le but n’est pas de laisser la sécurité désactivée, mais de déterminer si le ralentissement suit l’inspection par fichier.
Si les fichiers par seconde augmentent fortement, créez une exclusion à long terme plus sûre uniquement pour la mise en scène de sauvegarde de confiance ou les données de cache générées, ou planifiez le scan après le transfert. Si le résultat ne change pas, restaurez les paramètres d’origine et passez au comportement de l’outil de copie plutôt que d’accumuler des exceptions inexpliquées.
Comparez les Outils de Copie et la Concurrence Sans Modifier le Jeu de Données
Explorateur de fichiers, Finder, Robocopy, rsync, clients de sauvegarde et outils d’archivage peuvent utiliser différentes profondeurs de file d’attente, appels de métadonnées, règles de réessai et parallélisme. Comparez deux outils sur le même arbre source et la même destination plutôt que de comparer des charges non liées.
La discussion de Resilio sur les scans de très grands nombres de fichiers illustre pourquoi un travail peut rester lié aux métadonnées même lorsque peu de contenu change. Plus de threads peuvent masquer une partie de la latence, mais ils peuvent aussi surcharger le NAS avec des créations concurrentes.
Augmentez la concurrence étape par étape et arrêtez-vous lorsque les fichiers par seconde cessent de s’améliorer, que la latence augmente fortement, ou que le NAS commence à mettre en file d’attente les écritures. Conservez le réglage qui améliore de manière constante la charge réelle, pas la valeur la plus élevée autorisée par l’outil.
Utilisez le Schéma de Résultat pour Choisir la Solution la Plus Petite
Le diagnostic doit pointer vers une étape dominante : capacité réseau, lectures source, créations NAS, scan des points de terminaison, comportement des requêtes SMB, ou outil de copie. Ne combinez pas tous les réglages possibles dans une seule expérience car le changement final de vitesse n’expliquera plus la cause.
L’explication de ZimaSpace sur la façon dont le nombre de fichiers augmente le travail sur NAS fournit la raison sous-jacente pour laquelle les fichiers par seconde peuvent compter plus que les Mo/s pour cette charge.
Acceptez la correction uniquement lorsque le même ensemble de petits fichiers s’améliore sur des exécutions répétées sans nuire à la vitesse des gros fichiers, aux permissions, au comportement de restauration ou à la réactivité du NAS. Lorsque la récupération individuelle n’est pas nécessaire, empaqueter les petits fichiers immuables dans une archive peut réduire la surcharge d’objets, mais c’est une décision de flux de travail plutôt qu’une réparation universelle SMB.
Produits recommandés
Assistance et conseils
Plus à lire
Plex peut-il partager un GPU avec un autre conteneur Docker ?
Plex et un autre conteneur peuvent souvent accéder au même GPU, mais vous devez tester la prise en charge des pilotes, le mappage des...
Comment déterminer si une erreur Plex vient du client ou du serveur
Reproduisez le même élément sur un autre client, comparez le chemin de session, puis recueillez les preuves côté serveur uniquement après que la portée...
Comment configurer le cache de Plex et le stockage temporaire du transcodage
Protégez l’état persistant de Plex en plaçant les fichiers temporaires de transcodage sur un stockage local adapté, puis vérifiez le nettoyage, l’espace libre et...
