Bonjour,
Je suis actuellement en train de réaliser des bench NFSv3/4.
rhel 6.5 serveur 192.168.1.2 cat /etc/export -> /tmp/mount_dbench/ (rw,async,no_root_squash)
**rhel 6.5 client* 192.168.1.2:/tmp/mount_dbench on /mnt type nfs (rw,vers=4,addr=172.27.114.16,clientaddr=172.27.114.18)
système de fichiers commun ext4. Ces deux machines sont virtuelles et gérées par un cluster vmware. Les vmdk de ces deux machines sont stockés sur un baie avec classe de stockage sata.
Sur mon client donc /mnt/mount_dbench est un point de montage NFSv4 issu de mon serveur.
J'utilise pour bencher deux commandes. soit
date; cp /tmp/SUU_731_Q32013.ISO /mnt/mount_dbench/ ; date (l'iso fait 8G)
dd if=/dev/zero of=/mnt/mount_dbench/file.data1 bs=1M count=8192 conv=fdatasync #(fichier remplie de zero dont la taille finale est 8G)Avec la commande CP j'obtiens un débit de 40 Mo/s alors qu'avec la commande DD j'obtiens un débit de 150 Mo/s
Systématiquement je vide le cache avec la commande sync ; echo 3 > /proc/sys/vm/drop_caches mais j'obtiens toujours ces mêmes résultats. Du coup je ne sais pas à quelle commande faire confiance pour bencher le débit en écriture.
Quelqu'un peut-il m'expliquer ces différences significative de débit ?
# Conditions différentes
Posté par ✅ ffx . Évalué à 2.
Pourquoi ne pas utiliser le même fichier en entrée dans les deux cas ?
donc dd if=/tmp/SUU…
Je ne connais pas trop ce qui se passe sur nfs, mais on peut imaginer une compression au vol, qui fonctionnerait beaucoup mieux avec un fichier rempli de zéro plutôt qu'avec des données plus aléatoires.
[^] # Re: Conditions différentes
Posté par julienB56 . Évalué à 1.
Je l'ai déjà fait et la encore les résultats sont complétements différents entre la commande DD et la commande CP.
D'après toi la commande DD compresse au vol ?
[^] # Re: Conditions différentes
Posté par ✅ ffx . Évalué à 2.
Non je ne pense pas que dd compresse quoi que ce soit (par contre le réseau, pourquoi pas)
mais si tu dis qu'avec les mêmes fichiers en entrée le résultat reste le même, ce n'est donc pas la raison ici
# CP/DD et mesure de temps
Posté par NeoX . Évalué à 2.
avec DD tu lui dis de prendre des blocs de 1Mo
cp lui fait peut-etre des blocs plus petits.
ensuite plutot que
dateau debut et à la fin pour connaitre la durée du programme, tu devrais utilisertimeau debut, il va ensuite afficher tout seul le resultat.[^] # Re: CP/DD et mesure de temps
Posté par julienB56 . Évalué à 1.
Merci pour l'astuce de time
[^] # Re: CP/DD et mesure de temps
Posté par Zylabon . Évalué à 2. Dernière modification le 28 octobre 2014 à 22:58.
ajout : désolé, en fait mon message sera peu éclairant, j'étais en mode "j'explique au noob"
Tu peux connaitre la taille des blocs utilisé par cp avec strace (en supposant qu'il ne l'adapte pas en fonction des perfs).
Chez moi pour cp : de /dev/urandom vers /dev/null
Pour dd c'est 512 octets. (ça se règle avec l'option bs, par exemple
dd bs=4k, il y a aussi ibs et obs pour régler la taille de bloc pour "input" et "output". À priori c'est le coté réseau le plus important.Si la taille de bloc est trop petite, le cout des appels système est trop important par rapport au cout des copies des données. Au delà d'un certain stade, augmenter ce nombre ne fait que consommer inutilement de la mémoire, puis grève les performance à cause de la perte des effets de cache.
Please do not feed the trolls
[^] # Re: CP/DD et mesure de temps
Posté par julienB56 . Évalué à 1.
Merci de ta réponse.
Effectivement ma commande DD est "reglée" avec un bs=1M car mon montage NFS depuis le poste client est avec les options wsize et rsize de 1M (commande nfsstat -m). Donc effectivement la commande DD est raccord avec avec les options rsize et wsize (surtout wsize :) ) du point de montage donc ça dépote pas mal.
J'aurai du me douter que les BS de la commande CP était différent d’où une baisse de perf.
En revanche merci pour le strace
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.