Параллельная приостановка и возобновление?

GPG нужны некоторые случайные байты для шифрования. Если у Вас заканчивается энтропия в пуле, который заставит GPG приостанавливаться.

--quick-random будет использовать низкокачественные случайные числа, делая шифрование небезопасным (и поэтому бесполезный, так используйте его только, чтобы протестировать, является ли это проблемой, не в производстве), но не закончится. При использовании --quick-random не приостановится, затем это - причина Вашей проблемы.

Как Ole Tange записал, gpg нужны случайные данные из /dev/random, который может замедлиться вполне быстро, если существует недостаточно энтропии.

Хорошее решение этой проблемы является haveged. При необходимости это предоставляет новую энтропию ядру (и поэтому/dev/random).

Гипотеза Ole Tange, что Gpg блокируется на чтении к /dev/random хороший. Можно подтвердить, что это путем рассмотрения одного из gpg обрабатывает, в то время как это заблокировано и проверяющий, на чем это заблокировано:

lsof -p1234
strace -s9999 -tt -p1234

(где 1234 является PID процесса gpg). Если Вы видите что-то вроде этого

…
gpg     1234 naftuli   4r   CHR    1,8      0t0       0 /dev/random
…
read(4, …

затем это - проблема.

Gpg не имеет никакой опции использовать /dev/urandom вместо /dev/random. Различие между теми двумя устройствами - это /dev/urandom никогда блоки (даже при редких обстоятельствах, когда это должно), тогда как /dev/random часто блоки (даже в общих падежах, где это не было должно). Для длинной истории читайте, рэнд от/dev/urandom, безопасного для ключа входа в систему?

Быстрое обходное решение должно было бы сделать копию gpg двоичного файла, замены /dev/random /tmp/random (или что-либо еще с той же длиной, которая, к сожалению, исключает /dev/urandom), и создайте символьную ссылку /tmp/random -> /dev/urandom.

Подкачка, ввод-вывод?

На что похож 1 из потоков? Мой первый инстинкт - то, что система ожидает некоторого ресурса для становления доступной, возможно, диски? подкачка?

Встроенная задержка?

Другая мысль - это gpg может иметь некоторые задержки, встроенные ни по какой другой причине, чем добавить к расходу создания ключей, и таким образом, задержки вызывают Ваше затишье в использовании ЦП.

Они были бы формой NOOP, где алгоритм генерации ключей ожидает неактивный в течение некоторого промежутка времени для передачи перед продолжением.

Также можно получить сведения о том, что продолжается путем выполнения 1 из gpg использование процессов strace видеть то, какие системные вызовы делаются.

Пример

$ strace gpg --encrypt --recipient "me@mail.com" "..."

Буфер?

Другая вещь, к которой я был бы подозрителен, буферизует. Возможно, существует буфер в Вашем конвейере, который исчерпывается быстрее, чем можно пополнить, таким образом, gpg процессы оголодали, чтобы работа сделала.

Вы могли использовать инструмент такой как pv выведать эту проблему путем помещения его после вывода от find.

Пример

$ find .... | sort | pv | ...

Я посмотрел бы на эти переключатели:

   -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.