O GNU paralelo não utiliza plenamente meus processadores

Question

Estou executando um comando como este no meu 36 servidor principal (EC2 c4.8xlarge / Amazon Linux).

find . -type f | parallel -j 36 mycommand

O número de arquivos a processar é de aproximadamente 1.000.000 e leva dezenas de minutos. Deve executar 36 processos simultaneamente. No entanto, do resultado de top , existem cerca de 10 processos no máximo e 70% estão inativos. ps mostra mais processos, mas a maioria deles é extinta.

Eu acho que foi porque cada mycommand terminou tão rapidamente, parallel não conseguiu recuperar novos processos. Então eu tentei parallel --nice 20 para alocar mais tempo de CPU para parallel , mas isso não funcionou.

Alguém tem uma ideia para melhorar isso?

$ parallel --version GNU parallel 20151022

    

Answer 1

The number of files to process is ~1,000,000, and it takes dozens of minutes.

Então você está correndo cerca de 600 empregos por segundo. A sobrecarga para um único trabalho Paralelo GNU é da ordem de 2 a 5 ms, portanto, quando você está obtendo mais de 200 trabalhos por segundo, o GNU Parallel não terá um desempenho melhor sem ajustes.

O ajuste é ter mais parallel s tarefas de spawining em paralelo. De link

cat myinput | parallel --pipe -N 100 --round-robin -j50 parallel -j100 your_prg

Desta forma, você terá 50 Paralelamente GNU que podem gerar 100 empregos por segundo.

    

Answer 2

Eh, se eu entendi suas perguntas, você quer processar todos os arquivos simultaneamente? O% parallel lançará várias instâncias de mycommand , não várias find instâncias.

    

Answer 3

Você está tentando abrir um milhão de arquivos, 36 por vez. Mesmo que o seu comando possa funcionar com potência máxima em uma CPU, você ainda incorreria na sobrecarga de abrir esses arquivos em primeiro lugar. AE / S é uma das operações mais dispendiosas em computadores. Sua melhor aposta seria carregar quantos desses arquivos antes na RAM da sua máquina, e trabalhar na RAM o máximo possível. Dependendo da quantidade de RAM que você tem, isso pode melhorar significativamente o desempenho, porque uma vez que uma leitura é iniciada, as leituras subseqüentes tendem a aproveitar o armazenamento em cache se forem feitas imediatamente uma após a outra. Você também pode querer certificar-se de que seu sistema de arquivos coloca os arquivos no modo cache-efficient, e também que é um bom fs quando se trata de múltiplas leituras subseqüentes.

Eu não acho que parallel vai te ajudar muito com essa refatoração.