правильное параллельное использование xargs


9

Я использую 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?


6
Скорее всего, вы пострадали от ввода-вывода: система не может прочитать файлы достаточно быстро. Попробуйте запустить более 40: так будет хорошо, если некоторым процессам придется ждать ввода-вывода.
Оле Танге

Какую обработку выполняет скрипт? Какие-либо базы данных / сети / IO вовлечены? Как долго это работает?
Фокс

1
Я второй @OleTange. Это ожидаемое поведение, если вы запускаете столько процессов, сколько у вас ядер, а ваши задачи связаны с IO. Сначала ядра будут ожидать ввода-вывода для своей задачи (сна), затем они будут обрабатываться, а затем повторяться. Если вы добавите больше процессов, то дополнительные процессы, которые в настоящее время не выполняются на физическом ядре, будут запускать параллельные операции ввода-вывода, что по окончании исключит или, по крайней мере, сократит периоды ожидания на ваших ядрах.
PSkocik

1- Есть ли у вас включена поддержка гиперпоточности? 2 - в том, что у вас есть, log.txt фактически перезаписывается при каждом вызове convert.py ... не уверен, является ли это предполагаемым поведением или нет.
Бичой

xargs -Pи >открывается для условий гонки из-за проблемы с половиной линии gnu.org/software/parallel/… Использование GNU Parallel вместо этого не будет иметь этой проблемы.
Оле Танге

Ответы:


4

Я был бы готов поспорить, что ваша проблема в питоне . Вы не сказали, какая обработка выполняется для каждого файла, но предполагая, что вы просто выполняете обработку данных в памяти, во время выполнения будет преобладать запуск 30 миллионов виртуальных машин (интерпретаторов) Python.

Если вы сможете реструктурировать свою программу на Python, чтобы она заняла список файлов, а не один, вы получите огромное улучшение производительности. Затем вы все равно можете использовать xargs для дальнейшего улучшения производительности. Например, 40 процессов, каждый из которых обрабатывает 1000 файлов:

find ./data -name "*.json" -print0 |
  xargs -0 -L1000 -P 40 python Convert.py

Нельзя сказать, что питон - плохой / медленный язык; это просто не оптимизировано для времени запуска. Вы увидите это на любом языке виртуальной машины или интерпретируемом языке. Ява, например, была бы еще хуже. Если бы ваша программа была написана на C, все равно стоило бы запустить отдельный процесс операционной системы для обработки каждого файла, но это было бы намного меньше.

Оттуда вы можете поиграть, -Pчтобы узнать, сможете ли вы выжать немного больше скорости, возможно, увеличив число процессов, чтобы использовать преимущества незанятых процессоров во время чтения / записи данных.


1

Итак, во-первых, рассмотрим ограничения:

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

Мое понимание этих вещей заключается в том, что GNU Parallel позволит вам лучше контролировать очередь заданий и т. Д.

Смотрите GNU параллельно против & (я имею в виду фон) против xargs -P для более подробного объяснения того, как они различаются.


0

Как уже говорили другие, проверьте, связаны ли вы с I / O. Кроме того, справочная страница xargs предлагает использовать -nс -P, вы не упоминаете количество Convert.pyпроцессов, которые вы видите, работающих параллельно.

В качестве предложения, если вы привязаны к вводу / выводу, вы можете попробовать использовать блочное устройство SSD или попробовать выполнить обработку в tmpfs (конечно, в этом случае вам следует проверить наличие достаточного объема памяти, избегая подкачки из-за tmpfs). давление (я думаю), и накладные расходы на копирование данных в первую очередь).

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.