Параллельная GNU не полностью использует мои процессоры
Я выполняю команду, подобную этой, на моем 36-главном сервере (EC2 c4.8xlarge/Amazon Linux).
find . -type f | parallel -j 36 mycommand
Количество обрабатываемых файлов составляет ~1000 000, и это занимает десятки минут. Он должен запустить 36 процессов одновременно. Однако из результата topМаксимум 10 процессов, а 70% бездействуют. ps показывает больше процессов, но большинство из них несуществующие.
Я догадался, что это потому, что каждый mycommand закончил так быстро, parallel не мог догнать нерест новых процессов. Так я попробовалparallel --nice 20 выделить больше процессорного времени для parallel сам, но это не сработало.
У кого-нибудь есть идея улучшить это?
$ parallel --version
GNU parallel 20151022
3 ответа
Количество обрабатываемых файлов составляет ~1000 000, и это занимает десятки минут.
Таким образом, вы выполняете около 600 заданий в секунду. Издержки для одного задания GNU Parallel составляют порядка 2-5 мс, поэтому, когда вы получаете более 200 заданий в секунду, GNU Parallel не будет работать лучше без настройки.
Твик должен иметь больше parallelНеработающие рабочие места параллельно. С https://www.gnu.org/software/parallel/man.html
cat myinput | parallel --pipe -N 100 --round-robin -j50 parallel -j100 your_prg
Таким образом, вы получите 50 GNU Parallel, которые могут порождать 100 заданий в секунду.
Эх, если я понял ваши вопросы, вы хотите обрабатывать все файлы одновременно? parallel запустит несколько экземпляров mycommand не несколько find экземпляров.
Вы пытаетесь открыть миллион файлов по 36 за раз. Даже если ваша команда может работать на полную мощность на одном процессоре, вы все равно будете вынуждены открывать эти файлы. Ввод / вывод является одной из самых дорогостоящих операций на компьютере. Лучше всего было бы заранее загрузить как можно больше этих файлов в оперативную память вашего компьютера и максимально поработать в оперативной памяти. В зависимости от того, сколько у вас ОЗУ, это может значительно повысить производительность, поскольку после начала чтения последующие чтения имеют тенденцию использовать кеширование, если они выполняются сразу один за другим. Возможно, вы также захотите убедиться, что ваша файловая система размещает файлы эффективным способом кеширования, а также что это хороший fs, когда дело доходит до нескольких последующих чтений.
Я не думаю parallel очень поможет вам с этим рефакторингом.