web-dev-qa-db-fra.com

Copier des téraoctets de centaines de milliers de fichiers dans le dossier lent

Je suis actuellement en cours d'exécution freenas et en utilisant SMB 3 sur les machines Windows pour copier des dossiers avec 80000 fichiers d'environ 35 Mo chacun. Voici la configuration

Freenas

  • Connexions 2x40GBPS liées
  • connexion SMB Partager avec SMB 3.1 activé
  • 1 noyau de Xeon 8 avec 512 Go de RAM
  • 400To de stockage RAID Z1 utilisant des lecteurs de 4 To pour plus d'iops
  • 23 groupes de 5 lecteurs par groupe RAID
  • 3x LSI 3008 SAS 3.0 Adpators de bus hôte 12 Go/s
  • SIMILIAR CONFIG peut être effectué sur Thinkmate.com à l'aide du serveur Superstorage 6048R-E1CR72L comme base, puis ajoutez au châssis d'expansion
  • Cadres Jumbo activés
  • pendant les transferts L'utilisation du processeur est d'environ 50%
  • pendant les transferts RAM L'utilisation est à 60%

Postes de travail

  • Windows 10 Pro
  • i7 3.6 GHz et 16 Go de RAM
  • 512GB m.2 Drive
  • Carte 40gbps dans la machine à sous PCI 3.0 16x
  • Cadres Jumbo activés
  • TCP Déchargement désactivé
  • RAID externe 0 (disque 3 ou 4) Les lecteurs sont connectés via USB-C
  • L'utilisation du processeur pendant les transferts est de 20%
  • L'utilisation de la RAM pendant les transferts est à 15%

J'ai donc ces disques RAID 0 avec environ 4 To de fichiers chacun, et chaque fichier est de 35 Mo. Chaque dossier a environ 80000 fichiers. 8 transferts simultanés, sur 8 postes de travail.

Lorsque j'utilise Robocopy pour copier les fichiers. Je reçois environ 1,8 Gbps les transférer. Ensuite, au fil du temps et la copie devient plus profonde et plus profonde dans ces fichiers que la vitesse tombe à environ 600 Mbps. Cela se produit si j'utilise ou non/mt: 10 de/mt: 1 sur robocopy. EmCopy n'a pas bien fermé, et FreefileSync veut mourir après environ 3 heures. Je veux que cela reste au moins stable à 1,8 Gbps au lieu de tomber constamment. Il devient également insensible à parcourir les actions sur les postes de travail pendant ces transferts. Quelqu'un d'autre a-t-il vécu cela?

7
cohortq

Ok on dirait que le problème est résolu maintenant. Voici la solution.

Dans le /etc/samba/smb-shares.conf.local

Cette ligne a été ajoutée à la part que nous utilisons

case sensitive = yes

Maintenant, nous transférons à un stabilité de 200 Mbps. Bien que pas la vitesse idéale, il ne diminue pas dans les heures supplémentaires de la vitesse. Cela corrige le problème décroissant de la vitesse.

3
cohortq

Sans profilage étendu sur les deux Source et destination, il est difficile de donner une réponse définitive. Cela dit, je ne pense pas que la source NVME Drive est le goulot d'étranglement; Après tout, vous lisez des fichiers assez volumineux, avec une quantité considérable ou des lectures séquentielles.

En raison du nombre élevé de fichiers impliqués, je me penche davantage vers des inefficacités dans NTFS et/ou le SMB Protocol lui-même.

Je vous suggère d'essayer ce qui suit:

  • sur l'hôte de destination, créez un jeu de données dédié avec la synchronisation désactivée, la somme de contrôle et la compression (c'est-à-dire: zfs set sync=disabled <dataset>, etc). Remarque: vous devez considérer cela comme un test et/ou une solution temporaire uniquement, je le fait non Suggez pour exécuter définitivement ces paramètres;

  • sur l'hôte source, essayez de démarrer avec un CD/USB Linux en direct et de transférer des fichiers avec le protocole NFS (plutôt que SMB). Vous devriez essentiellement faire ce qui suit:

    • démarrer avec le CD Live;
    • installez les utilitaires NFS et NTFS-3G;
    • montez le système de fichiers NTFS (c'est-à-dire: dans /mnt/localdir);
    • configurez une exportation NFS sur la destination;
    • montez-le sur l'hôte source (c'est-à-dire: mount x.x.x.x:/dstdir /mnt/localdir);
    • utilisez cp ou rsync pour transférer ces fichiers;
    • sur un autre terminal, essayez de courir dstat -d -f -n ON les deux Hôtes pour surveiller le transfert de fichier.
2
shodanshok