93 votes

Damiano Verzulli avatar

L'option "bs" dans "dd" améliore-t-elle vraiment la vitesse ?

Demandé el 8 de Décembre, 2014
Quand la question a-t-elle été
150993 affichage
Nombre de visites la question a
2 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

De temps en temps, on me dit que pour augmenter la vitesse d'un "dd", je dois choisir soigneusement une "taille de bloc" appropriée.

Même ici, sur ServerFault, quelqu'un d'autre a écrit que " ...la taille optimale des blocs dépend du matériel... " (iain) ou " ...la taille idéale dépendra de votre bus système, du contrôleur de disque dur, du disque lui-même et des pilotes pour chacun d'entre eux... " (chris-s)

Comme mon sentiment était un peu différent ( BTW : J'ai pensé que le temps nécessaire pour régler en profondeur le paramètre bs était beaucoup plus élevé que le gain obtenu, en termes de temps économisé, et que la valeur par défaut était raisonnable. ), aujourd'hui, je me suis contenté d'effectuer quelques tests de référence rapides et simples.

Afin de diminuer les influences extérieures, j'ai décidé de lire :

  • à partir d'une carte MMC externe
  • à partir d'une partition interne

et :

  • avec les systèmes de fichiers associés démontés
  • envoyer la sortie vers /dev/null pour éviter les problèmes liés à la "vitesse d'écriture" ;
  • éviter certains problèmes de base de la mise en cache du disque dur, du moins lorsqu'elle implique le disque dur.

Dans le tableau suivant, j'ai reporté mes résultats, en lisant 1GB de données avec différentes valeurs de "bs" ( vous pouvez trouver les chiffres bruts à la fin de ce message ):

enter image description here

En gros, il en ressort que :

  • MMC : avec un bs=4 (oui ! 4 bytes), j'ai atteint un débit de 12MB/s. Une valeur pas si lointaine par rapport aux 14.2/14.3 maximum que j'ai obtenu avec bs=5 et plus ;

  • HDD : avec un bs=10 j'ai atteint 30 MB/s. C'est certainement moins que les 95,3 Mo obtenus avec le bs=512 par défaut mais... c'est aussi significatif.

De plus, il était très clair que le temps sys du CPU était inversement proportionnel à la valeur de bs (mais cela semble raisonnable, car plus bs est faible, plus le nombre d'appels sys générés par dd est élevé).

Ayant dit tout ce qui précède, maintenant la question : quelqu'un peut-il expliquer (un hacker du noyau ?) quels sont les principaux composants/systèmes impliqués dans un tel débit, et si cela vaut vraiment la peine de spécifier un bs plus élevé que le défaut ?

Affaire MMC - chiffres bruts

bs=1M

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=1M count=1000
1000+0 record dentro
1000+0 record fuori
1048576000 byte (1,0 GB) copiati, 74,1239 s, 14,1 MB/s

real    1m14.126s
user    0m0.008s
sys     0m1.588s

bs=1k

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=1k count=1000000
1000000+0 record dentro
1000000+0 record fuori
1024000000 byte (1,0 GB) copiati, 72,7795 s, 14,1 MB/s

real    1m12.782s
user    0m0.244s
sys     0m2.092s

bs=512

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=512 count=2000000
2000000+0 record dentro
2000000+0 record fuori
1024000000 byte (1,0 GB) copiati, 72,867 s, 14,1 MB/s

real    1m12.869s
user    0m0.324s
sys     0m2.620s

bs=10

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=10 count=100000000
100000000+0 record dentro
100000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 70,1662 s, 14,3 MB/s

real    1m10.169s
user    0m6.272s
sys     0m28.712s

bs=5

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=5 count=200000000
200000000+0 record dentro
200000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 70,415 s, 14,2 MB/s

real    1m10.417s
user    0m11.604s
sys     0m55.984s

bs=4

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=4 count=250000000
250000000+0 record dentro
250000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 80,9114 s, 12,4 MB/s

real    1m20.914s
user    0m14.436s
sys     1m6.236s

bs=2

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=2 count=500000000
500000000+0 record dentro
500000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 161,974 s, 6,2 MB/s

real    2m41.976s
user    0m28.220s
sys     2m13.292s

bs=1

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=1 count=1000000000
1000000000+0 record dentro
1000000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 325,316 s, 3,1 MB/s

real    5m25.318s
user    0m56.212s
sys     4m28.176s

Boîtier de disque dur - chiffres bruts

bs=1

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=1 count=1000000000
1000000000+0 record dentro
1000000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 341,461 s, 2,9 MB/s

real    5m41.463s
user    0m56.000s
sys 4m44.340s

bs=2

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=2 count=500000000
500000000+0 record dentro
500000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 164,072 s, 6,1 MB/s

real    2m44.074s
user    0m28.584s
sys 2m14.628s

bs=4

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=4 count=250000000
250000000+0 record dentro
250000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 81,471 s, 12,3 MB/s

real    1m21.473s
user    0m14.824s
sys 1m6.416s

bs=5

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=5 count=200000000
200000000+0 record dentro
200000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 66,0327 s, 15,1 MB/s

real    1m6.035s
user    0m11.176s
sys 0m54.668s

bs=10

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=10 count=100000000
100000000+0 record dentro
100000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 33,4151 s, 29,9 MB/s

real    0m33.417s
user    0m5.692s
sys 0m27.624s

bs=512 (décalage de la lecture, pour éviter la mise en cache)

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=512 count=2000000 skip=6000000
2000000+0 record dentro
2000000+0 record fuori
1024000000 byte (1,0 GB) copiati, 10,7437 s, 95,3 MB/s

real    0m10.746s
user    0m0.360s
sys 0m2.428s

bs=1k (décalage de la lecture, pour éviter la mise en cache)

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=1k count=1000000 skip=6000000
1000000+0 record dentro
1000000+0 record fuori
1024000000 byte (1,0 GB) copiati, 10,6561 s, 96,1 MB/s

real    0m10.658s
user    0m0.164s
sys 0m1.772s

bs=1k (décalage de la lecture, pour éviter la mise en cache)

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=1M count=1000 skip=7000
1000+0 record dentro
1000+0 record fuori
1048576000 byte (1,0 GB) copiati, 10,7391 s, 97,6 MB/s

real    0m10.792s
user    0m0.008s
sys 0m1.144s
Demandé el 8 de Décembre, 2014 par Damiano Verzulli

Réponses

Trop de publicités?

38voto

user313114 avatar
user313114 Points 548

Ce que vous avez fait n'est qu'un test de vitesse de lecture. Si vous copiez réellement des blocs sur un autre périphérique, vous aurez des pauses dans la lecture pendant que l'autre périphérique accepte les données que vous voulez écrire, lorsque cela se produit, vous pouvez rencontrer des problèmes de latence rotationnelle sur le périphérique de lecture (si c'est un disque dur) et il est donc souvent beaucoup plus rapide de lire des morceaux de 1M sur le disque dur car vous rencontrez moins souvent la latence rotationnelle de cette façon.

Je sais quand je suis copie disques durs, j'obtiens un taux plus rapide en spécifiant bs=1M qu'en utilisant bs=4k ou par défaut. Je parle d'améliorations de la vitesse de 30 à 300 %. Il n'est pas nécessaire de le régler au mieux, sauf si c'est ce que vous faites tous les jours. Mais choisir quelque chose de mieux que la valeur par défaut peut réduire le temps d'exécution de plusieurs heures.

Lorsque vous l'utiliserez pour de vrai, essayez plusieurs numéros différents et envoyez les résultats de l'enquête. dd traiter un SIGUSR1 signal pour qu'il émette un rapport d'état afin que vous puissiez voir comment ça se passe.

 killall -SIGUSR1 dd
1811+1 records in
1811+1 records out
1899528192 bytes (1.9 GB, 1.8 GiB) copied, 468.633 s, 4.1 MB/s
Répondu el 9 de Décembre, 2014 par user313114 (548 Points )

11voto

Matthew Ife avatar
Matthew Ife Points 22370

En ce qui concerne le disque dur interne, au moins - lorsque vous lisez sur le périphérique, la couche de bloc al menos doit récupérer un secteur qui représente 512 octets.

Ainsi, lors de la lecture d'un octet, vous n'avez réellement lu du disque que sur la récupération de l'octet aligné sur le secteur. Les 511 fois restantes sont servies par le cache.

Vous pouvez le prouver comme suit, dans cet exemple sdb est un disque d'intérêt :

# grep sdb /proc/diskstats
8      16 sdb 767 713 11834 6968 13710 6808 12970792 6846477 0 76967 6853359
...
# dd if=/dev/sdb of=/dev/null bs=1 count=512
512+0 records in
512+0 records out
512 bytes (512 B) copied, 0.0371715 s, 13.8 kB/s
# grep sedb /proc/diskstats
8      16 sdb 768 713 11834 6968 13710 6808 12970792 6846477 0 76967 6853359
...

La quatrième colonne (qui compte les lectures) indique qu'une seule lecture a eu lieu, malgré le fait que vous ayez demandé des lectures de 1 octet. C'est un comportement attendu puisque ce périphérique (un disque SATA 2) doit au minimum retourner sa taille de secteur. Le noyau met simplement en cache le secteur entier.

Le principal facteur en jeu dans ces demandes de taille est la surcharge liée à l'émission d'un appel système pour une lecture ou une écriture. En fait, l'émission de l'appel pour < 512 est inefficace. Les très grandes lectures nécessitent moins d'appels système, au prix d'une plus grande utilisation de la mémoire.

4096 est généralement un nombre "sûr" pour la lecture, car.. :

  • Lors de la lecture avec la mise en cache activée (par défaut), une page fait 4k. Remplir une page avec des lectures de < 4k est plus compliqué que de garder la même taille de lecture et de page.
  • La plupart des tailles de bloc du système de fichiers sont définies sur 4k.
  • Ce n'est pas un nombre assez petit (peut-être que pour les SSDs ça l'est maintenant) pour causer des surcharges de syscall mais pas un nombre assez grand pour consommer beaucoup de mémoire.
Répondu el 12 de Janvier, 2015 par Matthew Ife (22370 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X