Eu uso o gnu parallelpara executar um pipe em vários arquivos em paralelo. Meu código faz o que deveria, no entanto, se especificar o máximo. número de CPU (no meu caso 64) cada trabalho usa <5% de cada CPU (com base em htop). Além disso, o número de tarefas e thr. (novamente com base em htop) atravessa o telhado, o que eventualmente mata o servidor. Se eu especificar apenas 30 núcleos no GNU, paralleltudo funcionará bem. Alguém sabe como max. fora o poder do servidor?
Meu comando é um conjunto de ferramentas diferentes para cortar leituras 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
Responder1
Como Luciano diz no comentário, a E/S do disco é provavelmente a causa.
A razão para obter mais processos é que seu pipeline iniciará pelo menos 5 processos. Portanto, você deverá ver pelo menos 64*5 processos sendo iniciados. Alguns deles também podem iniciar vários threads.
A E/S de disco paralelo é muito imprevisível (consultehttps://oletange.wordpress.com/2015/07/04/parallel-disk-io-is-it-faster/), e na prática é impossível dizer quantos trabalhos em paralelo é o ideal, porque depende de muitos fatores.
Portanto, para otimizar seu fluxo, eu ajustaria o número de trabalhos até obter o máximo rendimento. Você pode usar --joblog para ajudar a ver quanto tempo cada trabalho é executado.