¿Por qué la transferencia de archivos multiproceso mejora el rendimiento?

Question

RichCopy, una herramienta mejor que robocopy con GUI de Microsoft, parece ser la herramienta actual de elección para copiar archivos. Una de sus características principales, resaltada en TechNet article presenting the tool, es que copia varios archivos en paralelo. En su configuración predeterminada, tres archivos se copian simultáneamente, lo cual se puede ver muy bien en la GUI: [Progreso: xx% del archivo A, yy% del archivo B, ...]. Hay una gran cantidad de blogentries alabando esta herramienta y afirmando que esto acelera el proceso de copiado.

Mi pregunta es: ¿Por qué esta técnica mejora el rendimiento? Hasta donde yo sé, al copiar archivos en sistemas informáticos modernos, el disco duro es el cuello de botella, no la CPU o la red. Mi suposición sería que copiar varios archivos a la vez hace que todo el proceso sea más lento, ya que el HDD necesita ir y venir entre diferentes archivos en lugar de simplemente reproducir un archivo de manera secuencial. Desde RichCopy es más rápido, tiene que haber algún error en mis suposiciones ...

Answer 1

La herramienta está haciendo mejoras en el uso de hardware que puede optimizar de lectura y escritura de múltiples peticiones mucho mejores.

Al copiar un archivo a la vez, el hardware no sabrá que el bloque de datos que actualmente está pasando debajo del cabezal de lectura (o cerca) será necesario para una lectura subsiguiente porque el software no tiene puesto en cola esa solicitud todavía.

Una sola copia de archivos en estos días no es una tarea muy exigente para los subsistemas de discos modernos. Al darles más trabajo a estos sistemas de hardware, la herramienta aprovecha sus características de optimización mejoradas.

Answer 2

Supongo que los cabezales de lectura de lectura HDD pasan la mayor parte del tiempo inactivos y esperan que el bloque de memoria correcto del disco aparezca debajo de ellos, cuanta más memoria se copie significa menos tiempo en reposo y la mayoría de los programadores de disco modernos deberían cuidar de los saltos (por un bajo número de archivos/fragmentos)

Answer 3

por lo que yo sé, al copiar archivos en sistemas informáticos modernos, el disco duro es el cuello de botella, no la CPU o la red.

Creo que esas suposiciones son demasiado simplistas.

Primero, mientras que las LAN funcionan a 100Mb/1Gbit. Las redes de larga distancia tienen una velocidad de datos máxima que es menor que la velocidad máxima del enlace más lento.

En segundo lugar, el rendimiento efectivo de la transmisión de TCP/IP a través de Internet a menudo está dominado por el tiempo necesario para los mensajes de ida y vuelta y los reconocimientos. Por ejemplo, tengo un enlace de 8 + Mbit, pero mi tasa de transferencia de datos rara vez supera los 1Mbits por segundo cuando descargo contenido desde EE. UU. Por lo tanto, si puede ejecutar varias transmisiones en paralelo, una transmisión puede esperar un acuse de recibo mientras que otra está transfiriendo paquetes. (Pero si intenta enviar demasiado, comienza a tener congestión, tiempos de espera, retroceso y tasas de transferencia globales más bajas).

Finalmente, los sistemas operativos son buenos para realizar una variedad de tareas de E/S en paralelo con otros trabajo. Si está descargando 2 o más archivos en paralelo, el O/S puede leer/procesar paquetes de red para una descarga y escribir en el disco para otra ... al mismo tiempo.

Answer 4

Una aplicación ingenua de "copiar varios archivos" copiará un archivo y luego esperará a que se complete antes de copiar el siguiente.

Esto significa que un archivo individual NO PUEDE copiarse más rápido que la latencia de la red, incluso si está vacío (0 bytes). Debido a que probablemente haga varias llamadas al servidor de archivos, (abrir, escribir, cerrar), esto puede ser varias veces la latencia.

Para copiar archivos de manera eficiente, desea tener un servidor y un cliente que utilicen un protocolo que tenga un canalización; es decir, el cliente NO espera a que se guarde el primer archivo antes de enviar el siguiente, y de hecho, varios o muchos archivos pueden estar "conectados" a la vez.

Por supuesto, hacer eso requeriría un servidor personalizado, no un servidor de archivos SMB (o similar). Por ejemplo, rsync hace esto y es muy bueno para copiar grandes cantidades de archivos a pesar de ser de un solo hilo.

Así que mi suposición es que el multihilo ayuda porque es una solución para el hecho de que el servidor no admite pipelining en una sola sesión.

Una implementación de un solo subproceso que utilizaba un protocolo sensato sería lo mejor en mi opinión.

Answer 5

En largas distancias, las redes pueden escribir mucho más rápido de lo que pueden leer. Con el multihilo, tener "lectores" adicionales significa que los datos pueden transmitirse de manera más eficiente y no atascarse en los buffers.

Answer 6

Es una herramienta de red, por lo que el cuello de botella es la red, no el HDD. Hasta un punto (bajo) puede obtener más rendimiento de un enlace TCP utilizando algunas conexiones en paralelo. Esto (a) es paralelo a los apretones de manos TCP; (b) puede hacer un mejor uso del producto de retardo de ancho de banda si es alto; y (c) no hace que una conexión sea arbitrariamente lenta la ruta crítica si por alguna razón encuentra una alta RTT o tasa de falla.

Otra forma de hacerlo (b) es utilizar un enorme búfer de recepción de socket TCP, pero eso no siempre es conveniente.

Varias de las otras respuestas sobre la unidad de disco duro son incorrectas. Prácticamente cualquier disco duro hará una lectura anticipada en el supuesto de acceso secuencial, y cualquier caché de sistema operativo inteligente también lo hará.