LINUX.ORG.RU

как ограничить количество 100%-сpu процессов по количеству ядер (LD_PRELOAD? приоритеты?)


0

3

достаточно однопользовательского linux-only решения

пример: в цикле я делаю

ddjvu $1 -1 -format=tiff -page $i out0/$1.$((1000+$i)).tif &

надо, чтобы (активных) процессов ddjvu было не больше, чем ядер

первое, что приходит в голову — LD_PRELOAD и в нем проверять, имеет ли процесс право жрать процессор; если не имеет — то спать допустим 100мс и проверить снова

а может есть особый самый низкий приоритет, который даже не допускает *запуска* конкурирующих процессов на этом приоритете? это было бы идеально

З.Ы. решение сделать скрипт-обертку типа

run "ddjvu $1 -1 -format=tiff -page $i out0/$1.$((1000+$i)).tif"

возможно, но выглядит как-то не очень красиво... да и будет оно так работать правильно?

А смысл в этом какой? Какая вам разница, имеют ли не выполняющиеся нити статус running или sleeping?

anonymous
()

Ну и костыли! Смотрите аналоги Grand Central Dispatch, если таковые есть.

frey ★★
()
from subprocess import Popen
import time

jobs = []
MAX_JOBS = 4

def start_new_job(i):
    return Popen("echo %d started && sleep 2 && echo %d done" % (i, i), shell=True)

for i in range(20):
    if len(jobs) < MAX_JOBS:
        jobs.append(start_new_job(i))

    is_removed = False
    for j in jobs[:]:
        if j.poll() is not None:
           jobs.remove(j)
           is_removed = True

    if not is_removed:
        time.sleep(1)
baverman ★★★
()

блин...
есть 2 ядра
есть 10 процессов
берём их пиды
первые два оставляем (можно привязать каждый к своему ядру)
остальным говорим «Спать!»
проверяем периодически
если в первых двух (кол-во ядер) есть спящий(т.е. один из первых 2-х завершился) говорим «Работать, негр!»

ещё короче:
есть список пидов
и каждые n-секунд посылается сигнал «Работать» только первым двум, остальным говорим «Спать!»
элементарно, Ватсон!

megabaks ★★★★
()
Ответ на: комментарий от anonymous

> А смысл в этом какой? Какая вам разница, имеют ли не выполняющиеся нити статус running или sleeping?

чтобы кэш не засирали, и своп

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

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от baverman

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

если его чуть улучшить, то видимо получится тот самый скрипт run

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от www_linux_org_ru

что привязано к конкретному языку программирования

bash, python, какая разница?

и подозрительной константой 20

Для примера же.

то видимо получится тот самый скрипт run

Дешево и сердито.

baverman ★★★
()

запустить N процессов, по числу ядер, каждому задать affinity на конкретное ядро; ждать завершения любого процесса; запустить следующий с той же affinity, что и у завершившегося процесса

первое, что приходит в голову — LD_PRELOAD

Какая фигня тебе приходит в голову

tailgunner ★★★★★
()

в результате беседы всплыло смутное впечатление, что в гну утилитах это есть

и правда — вот например

yes | xargs -I dummy -P 3 xterm

держит открытыми ровно 3 окна xterm

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от megabaks

в общем вот как надо это делать (отладочный вариант)

seq 1 100 | xargs -I %i -P 3 xterm -e 'echo «ddjvu file -1 -format=tiff -page %i out0/file.$((1000+%i)).tif»; sleep 10'

что в твоём понимании костыли? сначала ответь

«костыли» означает, что существует (но возможно мне неизвестно) более короткое, понятное и общее решение

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от legolegs

охренеть какой код людям не лень писать, читать и сопровождать

З.Ы. моя фигня (пока что) прерывается по контрол-С

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

> запустить N процессов, по числу ядер, каждому задать affinity на конкретное ядро; ждать завершения любого процесса; запустить следующий с той же affinity, что и у завершившегося процесса

я так полагаю, что само ядро разберется, не? если у нас процессов по числу ядер

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от www_linux_org_ru

> я так полагаю, что само ядро разберется, не?

Ядро разберется из с 100 процессами, но ты зачем-то хочешь планировать в ручном режиме. Правда, 'sleep 10' в твоем примере намекает на то, что ты и сам не знаешь, чего хочешь.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Правда, 'sleep 10' в твоем примере намекает на то, что ты и сам не знаешь, чего хочешь.

бугага

он там затем, чтобы xterm не закрывался немедленно

xterm там тоже только для отладки, если что

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

> Ядро разберется из с 100 процессами, но ты зачем-то хочешь планировать в ручном режиме.

ну запущу я 500 процессов — они скорее всего засрут оперативку, кэш, и возможно даже своп

и нафига?

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от www_linux_org_ru

Если тебе просто нужно ограничить число процессов, то нужную опцию xargs ты уже нашел. Правда, непонятно, почему ты хочешь ограничить число процессоров числом ядер (без выставления affinity забота о кэше выглядит несерьезно) - я бы поставил, скажем, N+2 или N+3.

tailgunner ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> ну запущу я 500 процессов

500 - это, пожалуй, перебор.

они скорее всего засрут оперативку

Free memory is wated memory

кэш

См. выше про affinity

и возможно даже своп

Принимается, хотя, если система не уйдет в thrashing, тоже ничего страшного.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> 500 - это, пожалуй, перебор.

это *не* перебор, это типовое число страниц в книжке (а бывает даже больше)

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

насчет affinity — про это должно озабочиваться ядро линукса), или если уж оно совсем тупое (или я тупой, и не понимаю, почему оно не может раскидать 4 100%-цпу процесса по 4 ядрам) — то тогда уже про это должно озабочиваться xargs

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от www_linux_org_ru

>охренеть какой код людям не лень писать, читать и сопровождать

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

legolegs ★★★★★
()
Ответ на: комментарий от tailgunner

>я бы поставил, скажем, N+2 или N+3.

Эта задача - CPU-bound .

legolegs ★★★★★
()
Ответ на: комментарий от legolegs

у меня есть щас что почитать

а вот когда че-то новое будет, надо будет БЫСТРО

да и вообще образование полезно

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от www_linux_org_ru

> и еще насчет affinity — чем посмотреть ее?

taskset

tailgunner ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>чтобы кэш не засирали, и своп


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

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

Если не хотите все сразу, то запускайте часть.

anonymous
()
Ответ на: комментарий от anonymous

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

из постановки задачи ясно, что лучше вообще не запускать, но как вариант можно и просто усыплять лишние

Если не хотите все сразу, то запускайте часть.

спасибо, К.О.

в этом и был вопрос

ответ, как выяснилось xargs -P

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от megabaks

> более красивого не найдёшь гарантия 99,9% 0.1% оставим - может я чего не знаю...

xargs уже достаточно приемлемый костыль

но настоящим решением было бы настроить планировщик процессов

www_linux_org_ru ★★★★★
() автор топика
Ответ на: комментарий от megabaks

размышление [s]над планировщиком[/s] показало, что костылем xargs -Р следует ограничится

собственно, планировщик хотелось для того, чтобы 2-й xargs не ждал завершения 1-го xargs

но запустить 2 xargs параллельно нельзя, т.к. файлы-аргументы 2-го могут быть просто не готовы

это решаемо, но уже не на уровне юникса

www_linux_org_ru ★★★★★
() автор топика

Любопытная задача, и про решение с xargs я не знал. В первую очередь подумал про make, затем вспомнил про condor, хоть это уже явно чересчур.

unC0Rr ★★★★★
()

Ну не знаю, у меня heretic I стабильно занимает 100% CPU одного ядра, но не более.

ZenitharChampion ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.