79 votos

¿El "bs" opción en "dd" realmente mejorar la velocidad?

Cada ahora y entonces, me han dicho que para aumentar la velocidad de un "dd" que debo elegir cuidadosamente un "tamaño de bloque".

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

Como mi sensación fue un poco diferente (por CIERTO: pense que el tiempo necesario para profundamente ajustar el bs parámetro fue mucho mayor que la ganancia recibida, en términos de tiempo de guardar, y que el defecto era razonable), hoy acabo de ir a través de algunas rápida y sucia puntos de referencia.

Con el fin de reducir las influencias externas, me decidí a leer:

  • desde el exterior de la tarjeta MMC
  • a partir de una partición interna

y:

  • relacionados con los sistemas de ficheros umounted
  • el envío de la salida a /dev/null para evitar problemas relacionados con la "velocidad de escritura";
  • evitar algunos de los problemas básicos de disco duro de almacenamiento en caché, al menos cuando se trataba de la unidad de disco duro.

En la tabla siguiente, me he informado a mis conclusiones, la lectura de 1GB de datos con diferentes valores de "b" (puede encontrar los números al final de este mensaje):

enter image description here

Básicamente se cames que:

  • MMC: con un bs=4 (¡sí! 4 bytes), me alcanzó un rendimiento de 12 MB/s. Un no tan lejano valores wrt para el máximo 14.2/14.3 que tengo desde bs=5 y superior;

  • HDD: con un bs=10 he llegado a 30 MB/s. Seguramente menor que el 95,3 MB consiguió con el valor de bs=512 pero... significativo.

También, fue muy claro que la CPU sys-el tiempo es inversamente proporcional al valor de bs (pero esto suena razonable, como la parte baja de la bs, el mayor número de sys-llamadas generadas por dd).

Dicho todo lo anterior, ahora la pregunta: ¿puede alguien explicar (un kernel hacker?) ¿cuáles son los principales componentes/sistemas involucrados en tal rendimiento, y si realmente vale la pena el esfuerzo en la especificación de un título mayor que el predeterminado?


Caso de MMC - números

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

HDD caso - números

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 (compensación 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 (compensación 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 (compensación 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

33voto

user313114 Puntos 138

Lo que han hecho es sólo una velocidad de lectura de la prueba. si en realidad la copia de los bloques a otro dispositivo que haya una pausa en la lectura, mientras que el otro dispositivo está aceptando los datos que desea escribir, cuando esto sucede, usted puede golpear de rotación de los problemas de latencia en la lectura del dispositivo (si es un disco duro) y es tan a menudo significativamente más rápido para leer 1M pedazos la unidad de disco duro como usted viene para arriba en contra de la rotación de la latencia de menos a menudo de esa manera.

Sé que cuando estoy copiando discos duros puedo conseguir un ritmo más rápido especificando bs=1M de bs=4k o el valor predeterminado. Estoy hablando de las mejoras de velocidad de 30 a 300 por ciento. No hay necesidad de ajustar para mejor, a menos que es lo que haces cada día. pero recogiendo algo mejor que el defecto puede cortar horas fuera del tiempo de ejecución.

Cuando usted lo está utilizando para real pruebe con diferentes números y enviar el dd proceso de una SIGUSR1 de la señal para llegar a emitir un informe de estado para que pueda ver cómo va.

10voto

Matthew Ife Puntos 12680

Con respecto al disco duro interno, al menos, durante la lectura del dispositivo de la capa de bloque por lo menos tiene que recuperar un sector que es de 512 bytes.

Así, cuando el manejo de un 1 byte leído que has realmente sólo se leen desde el disco en el sector alineados byte de recuperación. El resto de 511 veces son servidos por la caché.

Usted puede probar esto 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 lee) indica que sólo 1 leer ocurrido, a pesar del hecho de que usted solicitó de 1 byte, se lee. Este es el comportamiento esperado ya que este dispositivo (un disco SATA 2) en un mínimo de retorno de su sector, tamaño. El núcleo, simplemente es el almacenamiento en caché todo el sector.

El mayor factor en juego en estos el tamaño de las peticiones es la sobrecarga de la emisión de una llamada al sistema para leer o escribir. De hecho, la emisión de la convocatoria para < 512 es ineficiente. Muy grande lee requieren menos llamadas al sistema en el costo de los más memoria que se usa para hacerlo.

4096 es típicamente un 'seguro' número para leer porque:

  • Cuando se lee con el almacenamiento en caché (el valor predeterminado) una página es de 4 kb. Llenar una página con < 4k lee es más complicado que el de mantener la lectura y el tamaño de página de la misma.
  • La mayoría de bloque de sistema de archivos tamaño de 4 kb.
  • Su no un pequeño número suficiente (tal vez para unidades de estado sólido es ahora) a causa de syscall sobrecarga, pero no un número lo suficientemente grande 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: