производительность для многопроцессорной обработки xarg и python + подпроцесс

У меня есть вопрос о масштабируемости производительности с помощью xargs. В настоящее время у меня есть программа пакетной обработки, написанная на python с многопроцессорной обработкой и подпроцессом. Каждый процесс порождает независимый subprocess.popen() для выполнения внешней команды. Недавно я понял, что весь процесс можно переделать с помощью xargs. Тем не менее, мне интересно, стоит ли использовать xargs для обработки файлов размером более 10 000, поскольку я никогда раньше не делал чего-то такого масштаба только с помощью инструментов командной строки. Учитывая мой тест с небольшими наборами данных, на самом деле неплохая идея, если все, что я делаю, это пакетный запуск группы команд, поскольку это позволяет избежать многих циклов накладных расходов, связанных с модулями Python, но я хотел бы узнать больше от любого, кто может иметь больше опыта работы с xargs и python. В частности, есть ли какой-либо предел буфера, который мне нужно настроить, чтобы xargs потреблял большое количество входных данных? Спасибо.


person ttback    schedule 25.10.2013    source источник
comment
ericlippert.com/2012/12/17/performance-rant Если вы у вас есть две лошади, и вы хотите знать, какая из двух быстрее, чем мчаться на своих лошадях. Не пишите кратких описаний лошадей, не размещайте их в Интернете и не просите случайных незнакомцев угадать, кто быстрее!   -  person Christian Ternus    schedule 25.10.2013
comment
Я предполагаю, что стоимость xargs или subprocess будет настолько мала, что вы не заметите разницы. Или, если есть разница, это будет больше о том, какой из них лучше всего разделяет набор аргументов, а не о том, какой из них имеет наименьшие накладные расходы. Но, как говорит Кристиан Темус, зачем гадать, если можно на самом деле знать ответ?   -  person abarnert    schedule 25.10.2013
comment
я не спрашиваю случайных незнакомцев, а для людей, которые могут иметь опыт с подобными проблемами. спасибо за время в любом случае.   -  person ttback    schedule 25.10.2013


Ответы (1)


Программа xargs соберет несколько аргументов из стандартного ввода и соединит их вместе, чтобы получилась одна длинная командная строка. Если имеется много-много-много аргументов, слишком длинных для одной командной строки, тогда он создаст и выполнит несколько командных строк столько, сколько необходимо.

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

Судя по вашему описанию проблемы, это хороший кандидат для этого. 10К вещей с относительно короткой обработкой для каждой. xargs может ускорить процесс.

Однако, по моему опыту, выполнение любой нетривиальной работы в сценариях оболочки приносит боль. Если у вас есть какие-либо имена каталогов или имена файлов, в которых может быть пробел, малейшая ошибка в заключении ваших переменных в кавычки приведет к сбою вашего сценария, поэтому вам нужно тщательно протестировать свой сценарий, чтобы убедиться, что он будет работать для всех возможных входных данных. По этой причине я делаю свои нетривиальные системные скрипты на Python.

Поэтому, если у вас уже есть ваша программа, работающая на Python, ИМХО, вы были бы сумасшедшим, если бы попытались переписать ее как сценарий оболочки.

Теперь вы все еще можете использовать xargs, если хотите. Просто используйте subprocess для запуска xargs и передайте все аргументы через стандартный ввод. Это приносит все преимущества и не причиняет боли. Вы можете использовать Python, чтобы вставить байт NUL chr(0) в конце каждого аргумента, а затем использовать xargs --null, и он будет надежным с именами файлов, в которых есть пробелы.

В качестве альтернативы вы можете использовать ' '.join() для создания собственных очень длинных командных строк, но я не вижу причин делать это, когда вы можете просто запустить xargs, как описано выше.

person steveha    schedule 25.10.2013
comment
да, я уже делаю метод subprocess + xargs с одной из операций. Сама операция очень проста, стоимость менее 1 с. Я предполагаю, что это не вопрос с практическими рекомендациями, но с точки зрения масштаба я не нашел никакого документа о том, существует ли какой-либо предел ввода для xargs. Похоже, он просто зацикливает ввод и может выполнять команды порциями. Зависит ли это от чего-то вроде буфера, который мне нужно настроить, чтобы он потреблял длинный список ввода? - person ttback; 25.10.2013
comment
Насколько я понимаю, xargs просто продолжает потреблять аргументы из стандартного ввода и добавлять их в командную строку до тех пор, пока строка не наткнется на предел или стандартный ввод не будет исчерпан. Как только он достигает предела, он запускает команду, а затем начинает создавать другую командную строку для запуска. Существует возможность установить ограничение, но я думаю, что встроенный по умолчанию работает довольно хорошо. Таким образом, xargs может обрабатывать любое количество входных аргументов, но может выполнить свою команду несколько раз, когда это произойдет. Подробнее здесь: offbytwo.com/2011/ 26/06/things-you-didnt-know-about-xargs.html - person steveha; 25.10.2013
comment
да, я читал это вчера. Так что я делаю находку | xargs, я немного запутался, нужен ли мне флаг -s или -L (лимит символов против лимита строки) - person ttback; 25.10.2013
comment
Ну, я не думаю, что вам действительно нужны флаги -s или -L. Просто попробуйте со встроенными настройками по умолчанию и посмотрите, как пойдет. Если программа, которую вы вызываете с помощью xargs, не имеет необычного ограничения на длину командной строки, которую она может обрабатывать, вам не нужно об этом беспокоиться. - person steveha; 25.10.2013