The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Система распараллеливания shell-скриптов PaSh перешла под крыло Linux Foundation, opennews (??), 27-Сен-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


70. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  –1 +/
Сообщение от Аноним (70), 28-Сен-21, 13:44 
Справедливости ради, я так и не осилил исполнение нескольких фоновых задач по числу ядер на шелле (не считая утилиты вроде xargs и parallel). Зато осилил IPC на шелле (вообще без проблем) и фоновые процессы на шелле (изично, только как завершать их нормально, чтоб слип не провисал, тоже не представляю -- приходится убивать). Эти ребята решили проблему несколько иначе, и шел им просто лишний как по мне. Да и вообще, есть подозрение, что это чисто по фану.
Ответить | Правка | Наверх | Cообщить модератору

74. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  +3 +/
Сообщение от OpenEcho (?), 28-Сен-21, 15:31 
> Справедливости ради, я так и не осилил исполнение нескольких фоновых задач по
> числу ядер на шелле (не считая утилиты вроде xargs и parallel).

how_many_cpu() {
   lscpu | grep 'On-line CPU' | awk -F: '{print $2}'
}

> (изично, только как завершать их нормально, чтоб слип не
> провисал, тоже не представляю -- приходится убивать).

( echo 'Job #1 started...'; sleep 5; ) &
pid=$!;

echo "Do some other stuff in parent's process ...";

echo 'Waiting 4 job#1 to finish gracefully'
tail --pid=$pid -f /dev/null;
echo $?

> Эти ребята решили проблему
> несколько иначе, и шел им просто лишний как по мне. Да
> и вообще, есть подозрение, что это чисто по фану.

Эти ребята классическое представление интерпрайза, где деньги не свои и можно поиграться со всем новеньким и ублажить мэнеджера, что они используют новейшие технологии, а в итоге строют мостра, вместо того чтоб разобраться с инструментом, который они собираются "улучшать"

Ответить | Правка | Наверх | Cообщить модератору

84. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  +/
Сообщение от San (??), 28-Сен-21, 16:10 
>lscpu | grep 'On-line CPU' | awk -F: '{print $2}'

Зачем так сложно? nproc
Можно даже (отсторожно башизм) $(($(nproc)*4)) если хочется по 4 процесса на ядро запустить

Ответить | Правка | Наверх | Cообщить модератору

85. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  –2 +/
Сообщение от Аноним (70), 28-Сен-21, 16:13 
Ах, если бы всё так просто было… Я конечно в порядке развлечения сделал всё на шелле, но вывод я поучил только один: нужны скрипты -- бери питон и не страдай хернёй, особенно, если требуется параллельное исполнение.
Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

87. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  +3 +/
Сообщение от San (??), 28-Сен-21, 16:20 
Кусок давно и успешно работающего кода параллельно запускающего сканирование в 300+ потоков на 6 ядрах процессора:
for th_count in $(seq 1 $threads_run)
do
  domain_scan "$th_count" &
done
joblist="$(jobs -p|sed -e ':a' -e 'N' -e '$!ba' -e 's/\n/ /g')"


Не хочу обидеть никакие языки программирования, но чем дольше работаю с шелом, тем реже возникает желание/надобность что-то к шелу добавлять (даже однострочники на разных ЯП)

Вышеуказанный код позже был переписан с использованием Gnu Parallel (что улучшило работу скрипта), но внедрение нового скрипта  пока затянулось по бюрократическим причинам

Ответить | Правка | Наверх | Cообщить модератору

88. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  +/
Сообщение от Аноним (70), 28-Сен-21, 16:35 
Так это совершенно мимо: ведь задача не наспавнить процессов, а спавнить новые покуда есть данные. При завершении родительского процесса (а ля sigint/sigterm) все порождённые процессы должны быть тут же завершены (включая все эти слипы), а готовые уже результаты сохранены.
Ответить | Правка | Наверх | Cообщить модератору

90. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  +1 +/
Сообщение от San (??), 28-Сен-21, 16:42 
Совсем не мимо. Скрипт именно так и работает: читает из файла 100500мильенов строк входных данных, разбивает входные данные на N частей, параллельно обрабатывает все эти N частей. Обработка результатов запущенной в N потоков ведется другим участком кода, который я не приводил выше, чтоб не захламлять обсуждение кодом
Ответить | Правка | Наверх | Cообщить модератору

91. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  –1 +/
Сообщение от Аноним (70), 28-Сен-21, 16:56 
Я просто не заметил того кода, с которым у меня возникли проблемы в шелле, а именно -- синхронизации процессов и обработки завершения. В лучшем случае у меня получалось так, что под инитом оставалось висеть куча разрозненных провисших процессов после завершения скрипта. Всё же, в питоне куда проще решать такие задачи. И jobs -p это конечно хорошо, но вообще никуда не годится по факту. Я тоже сначала был доволен своим наколенным кодом, повезло, что довольно быстро обнаружил, что тот делает совсем не то, что я ожидал.
Ответить | Правка | Наверх | Cообщить модератору

92. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  +/
Сообщение от San (??), 28-Сен-21, 17:03 
У приведенного мной выше кода есть еще такой минус. Если одни потоки завершаются раньше, то в принципе на их место можно было бы запускать другие, но данные разбиты на части перед распараллеливанием и это невозможно. Поэтому время работы равно времени работы самого долгого из потоков.
В принципе можно было решить эту проблему без использования Gnu Parallels, но я решил с использованием и получил заметное ускорение и уменьшение расхода ресурсов (ну правда изменения не ограничились parallels)
Ответить | Правка | Наверх | Cообщить модератору

94. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  –1 +/
Сообщение от Аноним (70), 28-Сен-21, 17:17 
А как же провисшие процессы? И gnu parallel это perl. Мне не нравится автор и особенности синтаксиса этой утилиты. Теперь использую xargs везде, где можно решить вопрос распараллеливания запуском нескольких копий скрипта в цикле (единственная задача при этом писать скрипт так, чтобы можно было спокойно запускать сколько угодно его копий для разных данных). Для фоновых процессов всё ещё использую ipc через файлы, и завершаю через pkill -g $$. Спасибо, что есть find -print0 и xargs -0, иначе всё было бы очень печально (привет любителям бсд).
Ответить | Правка | Наверх | Cообщить модератору

95. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  +/
Сообщение от San (??), 28-Сен-21, 17:27 
>А как же провисшие процессы?

Что значит провисшие? А, точно я упустил еще одну строчку, которую надо было привести в примере выше (гранд пардон):

joblist="$(jobs -p|sed -e ':a' -e 'N' -e '$!ba' -e 's/\n/ /g')"
echo "$(date +%Y-%m-%d:%H:%M:%S) $th_count threads started"
wait $joblist

wait будет ждать, пока все потоки не обработают свои данные и не завершатся. Только тогда пойдет выполнение дальнейшего кода

Ответить | Правка | Наверх | Cообщить модератору

96. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  –1 +/
Сообщение от Аноним (70), 28-Сен-21, 17:33 
Допустим, там фоновый жоб в таком формате while sleep 600 & wait; do и если скрипт завершить (отправив kill всем фоновым процессам напоследок), то sleep остаётся висеть. Я тогда словил гонку в нескольких местах сразу (и кажется, что работает, а по факту 1/10 раз нет).
Ответить | Правка | Наверх | Cообщить модератору

97. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  +1 +/
Сообщение от San (??), 28-Сен-21, 17:38 
Согласен, подобное может быть проблемой, но не мой случай. Все запущенные в потоках команды/программы сами завершаются в течении 8 секунд по таймауту, если запустивший их процесс убить, но мне никогда не требовалось этого делать пока скрипт со всеми потоками не выполнит свою задачу

Но думаю, что и эта проблема решима, если старательно к ней подойти

Ответить | Правка | Наверх | Cообщить модератору

106. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  +/
Сообщение от Michael Shigorinemail (ok), 28-Сен-21, 19:31 
> Но думаю, что и эта проблема решима, если старательно к ней подойти

help ulimit, однако...

Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

103. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  +/
Сообщение от Аноним (-), 28-Сен-21, 19:25 
> Спасибо, что есть find -print0 и xargs -0, иначе всё
> было бы очень печально (привет любителям бсд).

https://www.freebsd.org/cgi/man.cgi?find(1)


-X      Permit find to be safely used in conjunction with xargs(1).  If a
...
             However, you may wish to consider the -print0 primary in
             conjunction with “xargs -0” as an effective alternative.

-print0
             This primary always evaluates to true.  It prints the pathname of
             the current file to standard output, followed by an ASCII NUL
             character (character code 0).


И тебе привет.

Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

107. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  +/
Сообщение от Аноним (70), 28-Сен-21, 19:49 
Ну норм, это правда findutils. Чё там по coreutils?
Ответить | Правка | Наверх | Cообщить модератору

110. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  +/
Сообщение от Аноним (-), 28-Сен-21, 20:35 
>> Спасибо, что есть find -print0 и xargs -0, иначе всё
>> было бы очень печально (привет любителям бсд).
> Ну норм, это правда findutils. Чё там по coreutils?

Ну норм спрыг. Погоди, щас шнурки поглажу ...


Ответить | Правка | Наверх | Cообщить модератору

111. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  +/
Сообщение от Аноним (70), 28-Сен-21, 20:46 
Отчасти, ты прав конечно, только ведь это одна и та же проблема. Есть ещё прекрасная конструкция for file do (и find тут очень при чём), это вроде башизм же? И тут GPL…
Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

120. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  +/
Сообщение от Аноним (-), 28-Сен-21, 21:04 
> Отчасти, ты прав конечно, только ведь это одна и та же проблема.
> Есть ещё прекрасная конструкция for file do (и find тут очень
> при чём), это вроде башизм же? И тут GPL…

Я нхнп. Особенно - причем тут GPL.

А бсдшный sh (который именно sh, с реализацией в 13 000 sloc) вполне себе переваривает


for f in *; do printf "%s\n" "$f";done

-.o
-.s
[RPF] Обратная сторона Власти.zip


если что.

Ответить | Правка | К родителю #111 | Наверх | Cообщить модератору

121. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  +/
Сообщение от Аноним (70), 28-Сен-21, 21:12 
нет, я имел в виду for file do -> find -c 'for file do;echo $file; done' sh {} +
Ответить | Правка | К родителю #120 | Наверх | Cообщить модератору

161. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  +/
Сообщение от freehckemail (ok), 01-Окт-21, 02:28 
> ведь задача не наспавнить процессов, а спавнить новые покуда есть данные

Именно это xargs -P и делает.

Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

104. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  +/
Сообщение от Michael Shigorinemail (ok), 28-Сен-21, 19:29 
> Не хочу обидеть никакие языки программирования, но чем дольше работаю
> с шелом, тем реже возникает желание/надобность что-то к шелу добавлять
> (даже однострочники на разных ЯП)

А книжку "UNIX: универсальная среда программирования" (Керниган, Пайк) помните?


Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

102. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  +3 +/
Сообщение от Led (ok), 28-Сен-21, 19:24 
>бери питон и не страдай хернёй

Забыл как Мариванна говорила: "На ноль делить нельзя!"

Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

98. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  +/
Сообщение от n00by (ok), 28-Сен-21, 17:56 
>> Справедливости ради, я так и не осилил исполнение нескольких фоновых задач по
>> числу ядер на шелле (не считая утилиты вроде xargs и parallel).
> how_many_cpu() {
>    lscpu | grep 'On-line CPU' | awk -F: '{print
> $2}'
> }

Вот функция, которая составляет список активных ядер. Пример форматирования в комментарии.

/*
* Returns human readable representation of the cpuset. The output format is
* a list of CPUs with ranges (for example, "0,1,3-9").
*/
char *cpulist_create(char *str, size_t len,
            cpu_set_t *set, size_t setsize)

Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

105. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  +2 +/
Сообщение от Michael Shigorinemail (ok), 28-Сен-21, 19:30 
> а в итоге строют мостра, вместо того чтоб разобраться с инструментом,
> который они собираются "улучшать"

На эту тему: http://egorfine.com/ru/articles/worse-than-failure/

Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

108. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  +/
Сообщение от RM (ok), 28-Сен-21, 19:56 
> tail --pid=$pid -f /dev/null;

Это можно даже сказать красивый изврат с tail
Но: как оно себя будет вести если пока
"Do some other stuff in parent's process ...";
фоновый процесс с данным pid завершится и на его место кто-то запустит что-то другое? (гонка)
Не зря же pidfd придумали.

Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

149. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  +/
Сообщение от OpenEcho (?), 29-Сен-21, 16:30 
>> tail --pid=$pid -f /dev/null;
> Это можно даже сказать красивый изврат с tail

- Почему красивый изврат?
- Красота спасет мир ;)


> Но: как оно себя будет вести если пока
> "Do some other stuff in parent's process ...";
> фоновый процесс с данным pid завершится и на его место кто-то запустит
> что-то другое? (гонка)

Ну свой то PID мы знаем ?!
А детишек, свои или нет можно легко проверить на отцовство `ps -o ppid=ххх`
Есть еще куча других методов, но каждый хорош под свою задачу, если здесь добавить обертку на проверки, то смысл примера потеряется

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

> Не зря же pidfd придумали.

Ну свой то PID мы знаем ?!
А детишек, свои или нет можно легко проверить на отцовство `ps -o ppid=ххх`
Можно пошерстить /proc/$PID/fd и проверить уникальный доступ к чему-либо уникальному (хэш созданный на старте к примеру) ...
Есть еще куча других методов, но каждый хорош под свою задачу, если здесь добавить обертку на проверки, то смысл примера потеряется

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

> Не зря же pidfd придумали.

pidfd_getfd() "придумали" всего год назад, (насколько я помню, он доступен только с  5.6 кернелом), а еще есть громадная куча парка машин где принцип "работает, - не трогай" и народ вполне обходился и обходится без pidfd (не я не против pidfd, наоборот, но действительность однако...)

Ответить | Правка | Наверх | Cообщить модератору

191. "Система распараллеливания shell-скриптов PaSh перешла под кр..."  +/
Сообщение от RM (ok), 13-Окт-21, 19:19 
> Ну свой то PID мы знаем ?!
> А детишек, свои или нет можно легко проверить на отцовство `ps -o
> ppid=ххх`

Скорее ps -o pid --ppid=xxx
но идея понятна, согласен.
Хотя еще возможно придется учитывать внуков (потомков потомков), и не факт что ребенок будет жив пока внук работает. shell - он же может форкаться.
Хотя pidfd тут тоже не поможет в лоб.

> Пример то - не продакш, а просто в тему,

А я видел такое в проде, приходилось исправлять.
Вообще, досадно видеть, что есть куча кода, который almost works.

> pidfd_getfd() "придумали" всего год назад, (насколько я помню, он доступен только с
>  5.6 кернелом), а еще есть громадная куча парка машин где
> принцип "работает, - не трогай" и народ вполне обходился и обходится
> без pidfd (не я не против pidfd, наоборот, но действительность однако...)

Мой поинт был в том, что в pidfd была все же потребность.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру