Я использую xargsдля вызова сценария Python для обработки около 30 миллионов небольших файлов. Я надеюсь использовать xargsдля распараллеливания процесса. Я использую команду:
find ./data -name "*.json" -print0 |
xargs -0 -I{} -P 40 python Convert.py {} > log.txt
По сути, Convert.pyпрочитает небольшой файл json (4 КБ), выполнит некоторую обработку и запишет в другой файл 4 КБ. Я работаю на сервере с 40 ядрами процессора. И никакой другой процесс, интенсивно использующий процессор, не выполняется на этом сервере.
Наблюдая за htop (кстати, есть ли другой хороший способ отслеживать производительность процессора?), Я обнаружил, что -P 40это не так быстро, как ожидалось. Иногда все ядра замораживаются и уменьшаются почти до нуля в течение 3-4 секунд, затем восстанавливаются до 60-70%. Затем я пытаюсь уменьшить количество параллельных процессов до -P 20-30, но это все еще не очень быстро. Идеальным поведением должно быть линейное ускорение. Есть предложения по параллельному использованию xargs?
источник
xargs -Pи>открывается для условий гонки из-за проблемы с половиной линии gnu.org/software/parallel/… Использование GNU Parallel вместо этого не будет иметь этой проблемы.Ответы:
Я был бы готов поспорить, что ваша проблема в питоне . Вы не сказали, какая обработка выполняется для каждого файла, но предполагая, что вы просто выполняете обработку данных в памяти, во время выполнения будет преобладать запуск 30 миллионов виртуальных машин (интерпретаторов) Python.
Если вы сможете реструктурировать свою программу на Python, чтобы она заняла список файлов, а не один, вы получите огромное улучшение производительности. Затем вы все равно можете использовать xargs для дальнейшего улучшения производительности. Например, 40 процессов, каждый из которых обрабатывает 1000 файлов:
Нельзя сказать, что питон - плохой / медленный язык; это просто не оптимизировано для времени запуска. Вы увидите это на любом языке виртуальной машины или интерпретируемом языке. Ява, например, была бы еще хуже. Если бы ваша программа была написана на C, все равно стоило бы запустить отдельный процесс операционной системы для обработки каждого файла, но это было бы намного меньше.
Оттуда вы можете поиграть,
-Pчтобы узнать, сможете ли вы выжать немного больше скорости, возможно, увеличив число процессов, чтобы использовать преимущества незанятых процессоров во время чтения / записи данных.источник
Итак, во-первых, рассмотрим ограничения:
Какое ограничение на каждую работу? Если это ввод-вывод, вы, вероятно, можете обходиться несколькими заданиями на ядро ЦП до тех пор, пока не достигнете предела ввода-вывода, но если он потребляет много ресурсов ЦП, будет хуже, чем бессмысленное выполнение большего количества заданий одновременно, чем у ядер ЦП.
Мое понимание этих вещей заключается в том, что GNU Parallel позволит вам лучше контролировать очередь заданий и т. Д.
Смотрите GNU параллельно против & (я имею в виду фон) против xargs -P для более подробного объяснения того, как они различаются.
источник
Как уже говорили другие, проверьте, связаны ли вы с I / O. Кроме того, справочная страница xargs предлагает использовать
-nс-P, вы не упоминаете количествоConvert.pyпроцессов, которые вы видите, работающих параллельно.В качестве предложения, если вы привязаны к вводу / выводу, вы можете попробовать использовать блочное устройство SSD или попробовать выполнить обработку в tmpfs (конечно, в этом случае вам следует проверить наличие достаточного объема памяти, избегая подкачки из-за tmpfs). давление (я думаю), и накладные расходы на копирование данных в первую очередь).
источник