.png)
En Windows 8.1, estoy usando Robocopy para guardar los datos de 2 servidores en el espacio de almacenamiento de una PC dedicada. El volumen de datos es de 147.314 archivos en 4.110 carpetas (66.841.845.760 bytes).
Las 3 PC involucradas cuentan con una CPU i7 con 4 núcleos y están en una red de 1 Gb. El espacio de almacenamiento del objetivo (reflejado y rayado en D:) se logra utilizando una caja JBOD de 4 x 4 TB.
Debido a los 4 núcleos de las CPU y al hyperthreading, esperaba que el conmutador Robocopy /MT:8 funcionara mejor y que más de 8 subprocesos serían excesivos debido a una gestión de subprocesos no beneficiaria.
Probé esto. Aquí enumero los datos de la cuarta serie de pruebas (duración en mm:ss):
1 thread: 59:19
2 threads: 39:12
4 threads: 29:13
8 threads: 24:36
16 threads: 24:19
32 threads: 24:27
Por supuesto, los pocos segundos que usan 16 subprocesos son insignificantes, peroson consistentesen todas las series de pruebas, es decir, no debido a una mayor carga de trabajo en la prueba de menos de 16 subprocesos (a menos que este fuera el caso en las 4 series de pruebas). También tenga en cuenta que 32 subprocesos son casi siempre un poco más rápidos que 8 subprocesos.
Pregunta: ¿qué razón técnica es responsable de que el uso de 16 subprocesos sea más eficiente que 8 subprocesos en un i7 con 4 núcleos hiperprocesados?
Respuesta1
TL;versión dr: si estuviera haciendo algo que requiere un uso intensivo de la CPU, como transcodificar video usando Handbrake, entonces no querrá usar más núcleos que CPU, ya que no habría ningún lugar donde realizar el trabajo. En este caso, donde la mayoría de los subprocesos pasarán el 90% de su tiempo dormidos esperando lecturas o escrituras, tener más subprocesos funciona.parausted en lugar de en contra.
Copiar archivos no es una tarea particularmente vinculada a la CPU. Si bien tener más núcleos puede ayudar a evitar que otras tareas bloqueen su herramienta de copia, es poco probable que cada subproceso se ejecute cerca del 100% en cada núcleo.
Cada hilo de copia enviará una solicitud de lectura al disco duro y luego entrará en suspensión mientras espera que se cumpla la solicitud de lectura. Su disco oxidado giratorio generalmente tiene un tiempo de búsqueda de 9 milisegundos, prácticamente una eternidad en términos de CPU, y la tarea de copia no giraría simplemente diciendo "¿ya está listo?" y desperdiciar ciclos de CPU. Hacerlo bloquearía ese hilo al 100% de la CPU y desperdiciaría recursos. No, lo que sucede es que el hilo emite una lectura y el hilo se pone en suspensión hasta que se completa la lectura y los datos están listos para el siguiente paso.
Mientras tanto, otro hilo hace lo mismo, se bloquea en una lectura y se pone en suspensión. Esto sucede para los 16 hilos. (En realidad, tus lecturas y escrituras se realizarán en momentos aleatorios a medida que se desincronicen, pero ya entiendes la idea)
Once one of the threads has data ready for it then Windows reschedules it and it starts processing it for being written. As far as the thread is concerned the process is the same. It says "write this data to file x at location y" and Windows takes the data and deschedules the thread. Windows does the background work to figure out where the file is, moves the data (potentially across the network adding more milliseconds to the delay) and then returns control to the thread once the write succeeded.
No one thread will be burning all the time on a CPU core and so more threads than you have CPUs is not a problem. No thread will be awake long enough for it to be a problem.
If you only had a single CPU with lots of other threads running then you could be bottlenecking on the CPU, but in a multicore system with this kind of workload I would be surprised if the CPU is the problem.
You are more likely to be bottlenecked on hard drive performance and are hitting the queue depth for the read or write buffers on the drives. By using more threads you are pushing something to its limits, be it disk or network, and the only way to find out what is the best number of threads is to do what you have done and experiment with it.
On a system with SSD to SSD copying I would suspect that a lower number of threads might be better as there would be less latency than copying files from spinning rust HDDs, pushing across the network and writing to spinning rust, but I have no evidence to support that supposition.