92 votos

¿La opción "bs" de "dd" mejora realmente la velocidad?

De vez en cuando me dicen que para aumentar la velocidad de un "dd" debo elegir cuidadosamente un "tamaño de bloque" adecuado.

Incluso aquí, en ServerFault, alguien más escribió que " ...el tamaño de bloque óptimo depende del hardware... " (iain) o " ...el tamaño perfecto dependerá del bus del sistema, del controlador del disco duro, de la unidad en sí y de los controladores de cada uno de ellos... " (chris-s)

Como mi sensación era un poco diferente ( BTW: Me pareció que el tiempo necesario para afinar el parámetro bs era mucho mayor que la ganancia recibida, en términos de tiempo ahorrado, y que el valor por defecto era razonable. ), hoy me he limitado a repasar algunos puntos de referencia rápidos y sucios.

Para rebajar las influencias externas, decidí leer:

  • desde una tarjeta MMC externa
  • de una partición interna

y:

  • con los sistemas de archivos relacionados desmontados
  • enviando la salida a /dev/null para evitar problemas relacionados con la "velocidad de escritura";
  • evitar algunos problemas básicos del almacenamiento en caché del disco duro, al menos cuando se trata del disco duro.

En la siguiente tabla, he reportado mis hallazgos, leyendo 1GB de datos con diferentes valores de "bs" ( puede encontrar las cifras brutas al final de este mensaje ):

enter image description here

Básicamente resulta que:

  • MMC: con un bs=4 (¡sí! 4 bytes), alcancé un throughput de 12MB/s. Unos valores no tan lejanos wrt al máximo 14.2/14.3 que conseguí con bs=5 y superiores;

  • HDD: con un bs=10 alcancé 30 MB/s. Seguramente inferior a los 95,3 MB conseguidos con el bs=512 por defecto pero... significativo también.

Además, estaba muy claro que el tiempo de sistema de la CPU era inversamente proporcional al valor de bs (pero esto parece razonable, ya que cuanto menor es bs, mayor es el número de llamadas al sistema generadas por dd).

Dicho todo lo anterior, ahora la pregunta: ¿puede alguien explicar (¿un hacker del kernel?) cuáles son los principales componentes/sistemas implicados en tal rendimiento, y si realmente merece la pena el esfuerzo de especificar un bs superior al predeterminado?


Caso MMC - cifras brutas

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

Carcasa del disco duro - cifras brutas

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 (desplazamiento de la lectura, para evitar el almacenamiento en caché)

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 (desplazamiento de la lectura, para evitar el almacenamiento en caché)

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 (desplazamiento de la lectura, para evitar el almacenamiento en caché)

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

0 votos

Sólo he jugado con el bs para facilitar los cálculos al crear un archivo de intercambio ( dd if=/dev/zero of=/swapfile bs=8K count=524288 para un archivo de intercambio 4G (o 8096 para sistemas que no tienen la sintaxis no-posix)). La dirección velocidad consideración es muy interesante.

0 votos

@user186340 quieres decir desde el dispositivos utilizar dd en un único dispositivo es imposible.

1 votos

@warren - para conseguir 4G también puedes hacer bs=8k count=512K o bs=1M count=4K No recuerdo potencias de 2 más allá de 65536

38voto

user313114 Puntos 138

Lo que has hecho es sólo una prueba de velocidad de lectura. Si estás copiando bloques a otro dispositivo, se producen pausas en la lectura mientras el otro dispositivo está aceptando los datos que quieres escribir. Cuando esto ocurre, puedes tener problemas de latencia rotacional en el dispositivo de lectura (si es un disco duro), por lo que a menudo es mucho más rápido leer trozos de 1M del disco duro, ya que de esta forma te enfrentas menos a la latencia rotacional.

Sé cuando estoy copiando discos duros obtengo una tasa más rápida especificando bs=1M que utilizando bs=4k o por defecto. Estoy hablando de mejoras de velocidad del 30 al 300 por ciento. No hay necesidad de ajustarlo al máximo absoluto a menos que sea lo único que hagas cada día. pero elegir algo mejor que el predeterminado puede recortar horas al tiempo de ejecución.

Cuando lo uses de verdad, prueba con varios números diferentes y envía el dd procesar a SIGUSR1 para que emita un informe de estado y puedas ver cómo va.

 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

0 votos

Macbook Pro Retina de 2014 copiando en una memoria USB3 a 90 MB/s de escritura: $ sudo dd if=~/Downloads/Qubes-R4.0-rc4-x86_64.iso of=/dev/rdisk2 status=progress muestra 6140928 bytes (6.1 MB, 5.9 MiB) copied, 23 s, 267 kB/s . Lo he cancelado porque tardaba demasiado. Ahora especificando el bytesize: $ sudo dd if=~/Downloads/Qubes-R4.0-rc4-x86_64.iso of=/dev/rdisk2 bs=1M status=progress muestra 4558159872 bytes (4.6 GB, 4.2 GiB) copied, 54 s, 84.4 MB/s

3 votos

Si alguien está interesado en Mac terminal, la señal SIGUSR1 para comprobar el estado es CTRL + t

11voto

Matthew Ife Puntos 12680

Con respecto al disco duro interno, al menos -- cuando se está leyendo del dispositivo la capa de bloque como mínimo tiene que recuperar un sector de 512 bytes.

Por lo tanto, al manejar una lectura de 1 byte en realidad sólo has leído del disco en la recuperación de bytes alineados con el sector. Las 511 veces restantes son servidas por la caché.

Puede demostrarlo de la siguiente manera, en este ejemplo sdb es un disco de interés:

# 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 cuarta columna (que cuenta las lecturas) indica que sólo se ha producido 1 lectura, a pesar de haber solicitado lecturas de 1 byte. Este es el comportamiento esperado ya que este dispositivo (un disco SATA 2) tiene que como mínimo devolver el tamaño de su sector. El núcleo simplemente está almacenando en caché todo el sector.

El mayor factor en juego en estas solicitudes de tamaño es la sobrecarga de emitir una llamada al sistema para una lectura o escritura. De hecho, realizar la llamada para < 512 es ineficiente. Las lecturas muy grandes requieren menos llamadas al sistema a costa de utilizar más memoria para ello.

4096 suele ser un número "seguro" para la lectura porque:

  • Cuando se lee con la caché activada (por defecto) una página ocupa 4k. Llenar una página con lecturas < 4k es más complicado que mantener el mismo tamaño de lectura y de página.
  • La mayoría de los tamaños de bloque del sistema de archivos están configurados a 4k.
  • No es un número lo suficientemente pequeño (puede que para los SSD lo sea ahora) como para causar sobrecarga en el sistema, pero tampoco lo suficientemente grande como para consumir mucha memoria.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X