The OpenNET Project / Index page

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




Версия для распечатки Пред. тема | След. тема
Новые ответы [ Отслеживать ]
Параллельное исполнение в bash, !*! Аноним, 08-Окт-20, 19:15  [смотреть все]
С год назад хотел организовать параллельное исполнение, но что-то не вышло, и я оставил всё на одном ядре. Очень медленно. Как лучше его сделать? Хотя бы без синхронизации (синхронизация фоновых жобов развлечение ещё то, не хочу городить грязь, где она не нужна).

Один. Нужно просто запускать ещё 1 процесс по процессу на ядро как только завершился предыдущий и пока есть работа.

Два. Нужно организовать вывод из всех скриптов, разделить экран по числу ядер в tmux или можно придумать что-нибудь ещё?

Жду ваших советов и предложений, спасибо.

  • Параллельное исполнение в bash, !*! Аноним, 19:41 , 08-Окт-20 (1) –3
    Как лучше сделать? Загуглить решение, очевидно же. Научиться гуглить и читать документацию.
  • Параллельное исполнение в bash, !*! Licha Morada, 20:55 , 08-Окт-20 (3)
    > С год назад хотел организовать параллельное исполнение, но что-то не вышло, и
    > я оставил всё на одном ядре. Очень медленно. Как лучше его
    > сделать?

    У Вивека посмотрите.
    https://www.cyberciti.biz/faq/how-to-run-command-or-code-in-.../

    • Параллельное исполнение в bash, !*! Аноним, 21:10 , 08-Окт-20 (4)
      Мне нужен раздельный вывод (т.е. табы или разделить одно окно и пулять выхлоп каждого процесса раздельно), мне нужно произвольное число процессов (по числу ядер). Это основное. Если синхронизация только в родительском процессе, нужно контролировать статус фоновых процессов и опционально управлять ими посредством сигналов (достаточно будет получить код завершения, текстовый ipc через фс я уже сделал и тут мне не нужно передавать данные между процессами). Управление фоновыми процессами через job/wait показалось мне очень не надёжным, как пример, после завершения родителя порождённые процессы не спешат умирать и нет никакой возможности узнать их пиды для убийства (я решил этот вопрос, но не совсем так, как хотелось бы), постоянные проблемы с состоянием гонки и синхронизацией (необходимо это учитывать, если где-то в процессе исполнения возникла ошибка).
      • Параллельное исполнение в bash, !*! Аноним, 21:32 , 08-Окт-20 (5)
        Да, от файлов с выводом, который я буду читать в основном процессе, тоже хотелось бы отказаться в идеале, я правда не представляю как.
      • Параллельное исполнение в bash, !*! Аноним, 22:36 , 08-Окт-20 (6)
        Чтобы такое сделать, вам нужно книжку по шелл-скриптингу прочитать. На самом деле только научиться перенаправлять вывод. Например, ./run > file$x.out &
        Пид лежит в специальной переменной, которую можно прочитать после запуска.

        Если не хотите все это изучать - наймите того, кто уже это сделал.

        • Параллельное исполнение в bash, !*! Аноним, 22:43 , 08-Окт-20 (8)
          Невозможно узнать идентификаторы потомков потомка, если только они сами не запишут их в какой-нибудь файл. Давайте по существу. И мне нужен выводу в реальном времени, а не после завершения.
          • Параллельное исполнение в bash, !*! Аноним, 03:42 , 09-Окт-20 (11)
            > Невозможно узнать идентификаторы потомков потомка, если только они сами не запишут их
            > в какой-нибудь файл. Давайте по существу. И мне нужен выводу в
            > реальном времени, а не после завершения.

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

            • Параллельное исполнение в bash, !*! Аноним, 04:13 , 09-Окт-20 (12)
              Извините, а где я кого-то учил? И из чего можно сделать выводы о моей компетенции? Вот о Вашей уже сложилось определённое мнение на основании ответов в данной теме.
              • Параллельное исполнение в bash, !*! Аноним, 11:45 , 09-Окт-20 (13)
                > Извините, а где я кого-то учил?

                Ну вот же вы утверждаете, что нельзя узнать пид, если он не был сохранен в файл самим процессом. Кто-то может перенять заблуждение.

                Прочитайте документацию по башу. Будете знать и как пид запущенного процесса получить, и как параллельно процессы запускать.

                • Параллельное исполнение в bash, !*! Аноним, 19:05 , 09-Окт-20 (15)
                  > Ну вот же вы утверждаете, что нельзя узнать пид, если он не
                  > был сохранен в файл самим процессом. Кто-то может перенять заблуждение.
                  > Прочитайте документацию по башу. Будете знать и как пид запущенного процесса получить,
                  > и как параллельно процессы запускать.

                  Так это было указание на очевиднейшую безграмотность, я не пытался ничему учить. Но, раз настаиваете… Если сейчас покажете, как получить идентификатор потомка дочернего процесса (чтобы тому можно было отправить сигнал, например), я признаю, что часами долбился в глазки, вместо того, чтобы больше экспериментировать и найти всё-таки подходящий способ. Поскольку единственное решение, найденное мной, заключается в убийстве себя, и тогда все потомки, включая деток и внучек, отправляются на тот свет вместе с нами достаточно быстро, но только в случае, если те ещё не успели разбежаться во все стороны (потому что тогда они уже успешно демонизируются и сделать с ними ничего не получится, а сигналы они замечательно проигнорируют в одном случае из 10). И упомянутая мной запись всех айди в файл и управление ими из мейна тоже не самый универсальный метод -- если sigint прийдёт не вовремя, программа в лучшем случае устроит что-то в духе rm -rf *, а дочерним процессам прилетят случайные сигналы (или не прилетят вовсе, если те уже перестали быть дочерними). В противном случае, дверь вон в той стороне, выйдите вон, и по возможности больше не отвечайте на вопросы, в которых ни черта не смыслите, или хотя бы не делайте вид, что в чём-то разбираетесь. Спасибо.

                  • Параллельное исполнение в bash, !*! Аноним, 21:56 , 09-Окт-20 (22)
                    Пиды процессов внуков только через системные утилиты, работающие с процессами.
                    Либо вы шлете сигнал дочке, а она его обрабатывает, делая что-то с внуками. Но проще так не делать и перепроектировать логику.

                    Скрипт, который будет делать то, что вам надо, это примерно строк 10, может быть 20. В нем будут такие вещи, как for in, nproc, &, wait, возможно $!, trap. Отлично гуглятся все вопросы, которые могут возникнуть при написании. Во всяком случае, по-английски все документировано и разжевано.

                    Вам принципиально, чтобы какой-то русскоязычный васёк за вас скрипт написал? Фетиш какой-то? Уже два дня побираетесь, можно было уже пару раз перечитать доку по башу вдоль и поперек.

                    • Параллельное исполнение в bash, !*! Аноним, 22:32 , 09-Окт-20 (23)
                      Проблема в том, что "системные утилиты, работающие с процессами", не могут предоставить информации, не имеющейся у ядра. А сканирование всех процессов на предмет ближайшего предка (если он ещё не потерян!) -- это не самое лучшее решение, подверженное всё той же гонке и случайным плавающим багам. Все мои попытки передавать сигнал по цепочке завершились тем, что в одном случае из десяти (или ста), процессы их игнорировали и успешно демонизировались. Перепроектировать логику не получится. Если тот же sleep запущен, он будет продолжать висеть под инитом, пока его не убьют, или он не закончится сам.

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

                      • Параллельное исполнение в bash, !*! Аноним, 18:42 , 12-Окт-20 (25)
                        Выдумываете себе проблемы, чтобы потом героически их превозмогать. Сраному скрипту в кроне - нужны данные о процессах уровня ядра! Линукс Торвальдс должен срочно сделать новые апи, чтобы вы смоги решить свои задачи...

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

                        • Параллельное исполнение в bash, !*! Аноним, 19:19 , 12-Окт-20 (26)
                          Там задача была ждать данные в основном потоке и накапливать, валидировать, и сбрасывать на диск каждые N времени в дополнительном фоновом основываясь на ряде условий. Какой ещё крон? Использовать тут крон это напрашиваться на проблемы -- при убийстве скрипта некому будет его отключить. Полагаю, ваши скрипты очень грязные.

                          Но это не имеет никакого отношения к текущей проблеме. Сейчас меня интересует организация красивого вывода с индикацией работы скрипта (без ncurses). Простое "решение" у меня и так есть, это find . -name "*" -print0 | xargs -0 -n 1 -P "$(nproc)" -I '{}' script '{}' однако вывод превращаеся в мешанину. "Классическое" решение это отключить вывод, но меня оно не устраивает.

        • Параллельное исполнение в bash, !*! Аноним, 22:43 , 08-Окт-20 (9) +1

          > Если не хотите все это изучать - наймите того, кто уже это
          > сделал.

          Вот этого нельзя допустить !

          Держи друг Аноним
          https://github.com/dustinblackman/tcon

  • Параллельное исполнение в bash, !*! system, 15:33 , 09-Окт-20 (14)
    > С год назад хотел организовать параллельное исполнение, но что-то не вышло, и
    > я оставил всё на одном ядре. Очень медленно. Как лучше его
    > сделать? Хотя бы без синхронизации (синхронизация фоновых жобов развлечение ещё то,
    > не хочу городить грязь, где она не нужна).
    > Один. Нужно просто запускать ещё 1 процесс по процессу на ядро как
    > только завершился предыдущий и пока есть работа.
    > Два. Нужно организовать вывод из всех скриптов, разделить экран по числу ядер
    > в tmux или можно придумать что-нибудь ещё?
    > Жду ваших советов и предложений, спасибо.

    пишешь простейший Makefile + make -jX

    • Параллельное исполнение в bash, !*! Аноним, 19:16 , 09-Окт-20 (16)
      Это заявка на победу, я думаю, стоит уже взять parallel в таком случае. Но мне хотелось бы решить это без perl. Я могу всё это сделать красиво в python, там и ipc есть нормальный, и самые разные варианты запускать процессы, но задача обойтись средствами баша. Собственно, в ОП перечислен алгоритм моего питон однострочника запускающего окно и направляющего выводы youtube-dl в него. Там проблема, что он запускался только под conemu, а мне сейчас нужно что-то более универсальное (хотя вариант с konsole готов рассмотреть, хотелось бы переключать на соседний таб с разделением на области, но, полагаю, принудительный запуск дополнительного окна с tmux тоже не плохой вариант).
      • Параллельное исполнение в bash, !*! pavel_simple., 19:23 , 09-Окт-20 (17)
        > Это заявка на победу, я думаю, стоит уже взять parallel в таком
        > случае. Но мне хотелось бы решить это без perl. Я могу
        > всё это сделать красиво в python, там и ipc есть нормальный,
        > и самые разные варианты запускать процессы, но задача обойтись средствами баша.
        > Собственно, в ОП перечислен алгоритм моего питон однострочника запускающего окно и
        > направляющего выводы youtube-dl в него. Там проблема, что он запускался только
        > под conemu, а мне сейчас нужно что-то более универсальное (хотя вариант
        > с konsole готов рассмотреть, хотелось бы переключать на соседний таб с
        > разделением на области, но, полагаю, принудительный запуск дополнительного окна с tmux
        > тоже не плохой вариант).

        xargs + screen/tmux

        • Параллельное исполнение в bash, !*! Аноним, 19:49 , 09-Окт-20 (18)
          > xargs + screen/tmux

          Я вспомнил, чем мне не подошёл этот вариант. Там вроде бы можно было только отправлять команду на исполнение в панели, т.е. запуск новых процессов нонстоп (это то, что я использовал в конечном итоге, но тут это не подходит, хотя и можно набросать отдельный однострочник, запускающий этот скрипт -- мне как раз хотелось отказаться от по-файлового исполнения, слишком много времени на запуск уходит, особенно на "нелинуксе"). Либо добавлять текст (вывод) в панель уже после завершения, но нельзя было прицепить stderr/stdout/stdin запущенного процесса (и его потомков) к панели tmux и переключать его на вывод следующего процесса после завершения первого.

          • Параллельное исполнение в bash, !*! Аноним, 20:06 , 09-Окт-20 (19)
            В связи с чем вопрос. Можно ли как-то подцепить вывод форка себя (и автоматом всех потомков форка) к шеллу, запущенному в панели tmux?
            • Параллельное исполнение в bash, !*! Аноним, 20:37 , 09-Окт-20 (20)
              > В связи с чем вопрос. Можно ли как-то подцепить вывод форка себя
              > (и автоматом всех потомков форка) к шеллу, запущенному в панели tmux?

              Так, допустим, можно перенаправить все три потока для каждого процесса в именованные трубы (не проверял ввод, но вывод определённо будет работать), т.е. нам как минимум всё ещё необходимо сохранить список дочерних процессов (может и работать, при условии, что те не будут рекурсивно форкать себя и терять потомков), но мы всё ещё подвержены состояниям гонки и неадекватной реакции на сигналы. Тут тут возникает вопрос с тем, что tmux сам по себе и он может обидеться, когда мы начинаем взаимодействовать с шеллом в обход него, т.е. у tmux надо как-то отнять контроль над выводом (вводом) запущенных им шеллов.

  • Параллельное исполнение в bash, !*! Аноним, 03:14 , 11-Окт-20 (24)
    Какая же гадость этот parallel. Он поддерживает вывод в tmux (казалось бы что ещё нужно!) но запускает при этом 100 раз одновременно и ломает вывод консоли. Ещё и наспамила в консоль своим бредом сначала, автор очевидный аутист.

    Ну в принципе вот это наверное, да. Утянул себе нужное, надо закончить и посмотреть, как будет, а то xargs конечно нормально работает, но мешанина вывода совершенно нечитаемая. https://gist.github.com/mlgill/ad2693f17aaa720ef777




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

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