La tubería de subprocesos múltiples paralelos de GNU utiliza poco porcentaje de CPU pero detiene el servidor

La tubería de subprocesos múltiples paralelos de GNU utiliza poco porcentaje de CPU pero detiene el servidor

Utilizo gnu parallelpara ejecutar una tubería en varios archivos en paralelo. Sin embargo, mi código hace lo que debería si especifica el máximo. Número de CPU (en mi caso 64) cada trabajo utiliza <5% de cada CPU (según htop). Además, el número de tareas y thr. (nuevamente basado en htop) atraviesa el techo, lo que eventualmente mata al servidor. Si especifico sólo 30 núcleos en gnu, parallelfunciona bien. ¿Alguien sabe cómo maximizar? ¿Se acabó la energía del servidor?

Mi comando es un conjunto de diferentes herramientas para recortar lecturas genómicas:

parallel --jobs 64 "echo -e '\n'{} processing 1>&2 ; \
gunzip -c {} | scriptA.sh | scriptB.sh -outfmt fasta \
| java -jar scriptC.jar |bgzip \
> ${output}/tmp/{/.}.filtered.tmp.fa.gz " ::: ${input} 2> ${output}/0log_parallel_stderr.log

Respuesta1

Como dice Luciano en el comentario, lo más probable es que la E/S del disco sea la causa.

La razón para obtener más procesos es que su canalización iniciará al menos 5 procesos. Por lo tanto, debería ver que se inician al menos 64*5 procesos. Algunos de estos también pueden iniciar varios hilos.

La E/S de disco en paralelo es muy impredecible (consultehttps://oletange.wordpress.com/2015/07/04/parallel-disk-io-is-it-faster/), y en la práctica es imposible decir cuántos puestos de trabajo en paralelo es el óptimo, porque depende de muchos factores.

Entonces, para optimizar su flujo, ajustaría la cantidad de trabajos hasta que obtenga el máximo rendimiento. Puedes usar --joblog para ayudarte a ver cuánto tiempo se ejecuta cada trabajo.

información relacionada