Eu tenho uma coisa muito estranha que estou vendo enquanto executo 8 tarefas de criptografia GPG com o GNU paralelo:
Ocomandoqueexecuteiéeste:
find.-typef-not-iname"*.gpg" | sort |parallel --gnu -j 8 --workdir "$PWD" '
echo "Encrypting {}..." ;
gpg --encrypt --recipient "[email protected]" "{}"
'
Por que os trabalhos parecem começar e parar e começar e parar ao invés de simplesmente ocupar todo o tempo da CPU?
O GPG precisa de alguns bytes aleatórios para criptografar. Se você ficar sem entropia no pool, isso fará com que o GPG pause.
--quick-random usará números aleatórios de baixa qualidade, tornando a criptografia insegura (e, portanto, inútil, portanto, use-a apenas para testar se esse é o problema, não na produção), mas não se esgotará. Se o uso de --quick-random não for pausado, esse é o motivo do seu problema.
Como Ole Tange escreveu , o gpg precisa de dados aleatórios de /dev/random , o que pode diminuir muito rapidamente se não há entropia suficiente.
Uma boa solução para esse problema é haveged . Se necessário, ele fornece nova entropia para o kernel (e, portanto, para / dev / random).
A hipótese de Ole Tange que o Gpg está bloqueando em uma leitura para /dev/random é bom. Você pode confirmar isso olhando para um dos processos gpg enquanto ele está bloqueado e verificando o que está bloqueado:
lsof -p1234
strace -s9999 -tt -p1234
(onde 1234 é o PID do processo gpg). Se você vir algo assim
…
gpg 1234 naftuli 4r CHR 1,8 0t0 0 /dev/random
…
read(4, …
então este é o problema.
O Gpg não tem opção de usar /dev/urandom em vez de /dev/random . A diferença entre esses dois dispositivos é que /dev/urandom nunca bloqueia (mesmo nas raras circunstâncias em que deveria), enquanto /dev/random geralmente bloqueia (mesmo nos casos comuns em que não deveria). Para a longa história, leia É um rand de / dev / urandom seguro para uma chave de login?
Uma solução rápida seria fazer uma cópia do binário gpg, substituir /dev/random por /tmp/random (ou qualquer outra coisa com o mesmo tamanho, que infelizmente exclui /dev/urandom ) e criar um link simbólico /tmp/random -> /dev/urandom .
Como é um desses tópicos? Meu primeiro instinto é que o sistema está esperando algum recurso disponível, talvez discos? trocar?
O outro pensamento é que gpg pode ter alguns atrasos embutidos apenas para aumentar a despesa de criar chaves, e assim os atrasos estão causando sua trégua no uso da CPU.
Estes seriam uma forma de um NOOP, onde o algoritmo de geração de chaves espera inativo por algum período de tempo para passar antes de prosseguir.
Além disso, você pode obter informações sobre o que está acontecendo executando 1 dos processos gpg usando strace para ver quais chamadas de sistema estão sendo feitas.
$ strace gpg --encrypt --recipient "[email protected]" "..."
A outra coisa que eu suspeitaria é de buffer. Talvez haja um buffer em seu pipeline que está sendo exaurido mais rápido do que pode ser reabastecido, portanto, os processos gpg estão sendo carentes de trabalho para fazer.
Você pode usar uma ferramenta como pv para descobrir esse problema, colocando-o após a saída de find .
$ find .... | sort | pv | ...
Eu olharia para essas opções:
-a, --average-rate
Turn the average rate counter on. This will display the average
rate of data transfer so far.
-b, --bytes
Turn the total byte counter on. This will display the total
amount of data transferred so far.
Tags gpg cpu-usage gnu-parallel