The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Выпуск Mcron 1.2, реализации cron от проекта GNU , opennews (ok), 14-Авг-20, (0) [смотреть все]

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


16. "Выпуск Mcron 1.2, реализации cron от проекта GNU "  +/–
Сообщение от Совершенно другой аноним (?), 14-Авг-20, 12:36 
> "вместо постоянного мониторинга времени в Mcron применяется выстраивание заданий в линейную
> очередь c определением задержек между вызовом каждого элемента очереди"
> Да и что-то мне подсказывает, что процесс определения задержек не сильно отличается по
> ресурсам от постоянного мониторинга времени. Там же точность нужна до секунд.

Например, Вы выставили время запуска через 10 минут. В случае постоянного мониторинга процесс будет просыпаться за это время 599 раз, проверять всю очередь (в нашем примере в очередь одно Ваше задание), и запустит его только на 600 раз. В случае их подхода - он проснётся один раз - через 10 минут. А теперь можно посчитать, что будет, если надо запускать раз в неделю или раз в месяц.

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

26. "Выпуск Mcron 1.2, реализации cron от проекта GNU "  +/–
Сообщение от Аноним (8), 14-Авг-20, 13:03 
Планировщик, тоже потребляет ресурсы. В классическом кроне процедура отсчитывающая секунды и проверяющая нет ли заданий для запуска не сильно напрягается.
Ответить | Правка | Наверх | Cообщить модератору

30. "Выпуск Mcron 1.2, реализации cron от проекта GNU "  +2 +/–
Сообщение от Совершенно другой аноним (?), 14-Авг-20, 13:16 
> Планировщик, тоже потребляет ресурсы. В классическом кроне процедура отсчитывающая секунды
> и проверяющая нет ли заданий для запуска не сильно напрягается.

В смысле?
формально там, по ресурсам что-то типа:


sleep_time = calc_time(when);
sleep(sleep_time);
do_job();

в стандартном кроне, что-то вроде:


sleep_time = calc_time(when);
while (sleep_time > 0)
  sleep(1);
do_job();

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

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

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

37. "Выпуск Mcron 1.2, реализации cron от проекта GNU "  –3 +/–
Сообщение от Аноним (8), 14-Авг-20, 13:29 
"Понятно что на самом деле всё гораздо сложнее, но я это в контексте исходной предпосылкой с одним заданием."
Вот именно. Сферические кони весьма хороши в вакууме. На практике же классический что-то никто не выбрасывает, хотя режимы энергосбережения существуют уже десятки лет. Сабж же заявляет, что он лучше в плане энергосбережения, но что-то не видно особых сравнений.
Ответить | Правка | Наверх | Cообщить модератору

40. "Выпуск Mcron 1.2, реализации cron от проекта GNU "  +/–
Сообщение от Совершенно другой аноним (?), 14-Авг-20, 13:44 
> "Понятно что на самом деле всё гораздо сложнее, но я это в
> контексте исходной предпосылкой с одним заданием."
> Вот именно. Сферические кони весьма хороши в вакууме. На практике же классический
> что-то никто не выбрасывает, хотя режимы энергосбережения существуют уже десятки лет.
> Сабж же заявляет, что он лучше в плане энергосбережения, но что-то
> не видно особых сравнений.

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

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

41. "Выпуск Mcron 1.2, реализации cron от проекта GNU "  +/–
Сообщение от Аноним (8), 14-Авг-20, 13:53 
Просто с точки зрения работы ядра, оптимизация крона это такая мелочь по сравнению со всем остальным, что почти никак не повлияет на общее энергосбережение. Надо же один процесс просыпается один раз в секунду, в то время как ядро наносекундами оперирует. Плюс в случае с mcron вы будете иметь n (число заданий) спящих тредов, между которыми нужно будет переключаться, а это тоже ресурсы.
Ответить | Правка | Наверх | Cообщить модератору

46. "Выпуск Mcron 1.2, реализации cron от проекта GNU "  +2 +/–
Сообщение от Crazy Alex (ok), 14-Авг-20, 14:50 
Каких ещё тредов? Один тред, в нём - очередь. Классический вариант для эмбеда того же - не на схеме, понятно, но логика точно эта. Минималистично, удобно, надёжно.
Ответить | Правка | Наверх | Cообщить модератору

52. "Выпуск Mcron 1.2, реализации cron от проекта GNU "  +1 +/–
Сообщение от n00by (ok), 14-Авг-20, 15:34 
С точки зрения ядра всё складывается из вот таких "почти".
Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

76. "Выпуск Mcron 1.2, реализации cron от проекта GNU "  +/–
Сообщение от Экономный Анон (?), 14-Авг-20, 17:59 
> Просто с точки зрения работы ядра, оптимизация крона это такая мелочь по
> сравнению со всем остальным, что почти никак не повлияет на общее
> энергосбережение. Надо же один процесс просыпается один раз в секунду, в
> то время как ядро наносекундами оперирует. Плюс в случае с mcron
> вы будете иметь n (число заданий) спящих тредов, между которыми нужно
> будет переключаться, а это тоже ресурсы.

У меня как у нуба вот какой вопрос: в системе уже стоит cron, на него ещё всякие компоненты системы могут полагаться, может ли mcron полностью заменить его во всех аспектах?
Потому что если его ставить дополнительно, в том же дебиане с зависимостями он ещё 47 Мб пространства отжирает

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

91. "Выпуск Mcron 1.2, реализации cron от проекта GNU "  +1 +/–
Сообщение от Ordu (ok), 14-Авг-20, 21:39 
> Просто с точки зрения работы ядра, оптимизация крона это такая мелочь по сравнению со всем остальным, что почти никак не повлияет на общее энергосбережение. Надо же один процесс просыпается один раз в секунду, в то время как ядро наносекундами оперирует.

Система в спячке, но раз в секунду её надо вывести из спячки, дать поработать процессу, и отправить систему обратно спать. Чёт мне не кажется, что это будет так уж бесплатно, как ты описываешь.

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

Откуда ты вычитал про спящие треды? Как я понял из описания, он закидывает в единый список структурки типа { .wake_time = ???, .cmd = "???" }, сортирует их по wake_time, выбирает первый, и уходит в сон, пока не придёт время запускать первый .cmd.

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

80. "Выпуск Mcron 1.2, реализации cron от проекта GNU "  +/–
Сообщение от rshadow (ok), 14-Авг-20, 18:43 
Уже сейчас можно посмотреть powertop например.
Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

47. "Выпуск Mcron 1.2, реализации cron от проекта GNU "  +5 +/–
Сообщение от Аноним (45), 14-Авг-20, 14:56 
>На практике же классический что-то никто не выбрасывает

Про tickless kernel слышал? Это примерно то же самое, 10 лет уже используют.

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

88. "Выпуск Mcron 1.2, реализации cron от проекта GNU "  +1 +/–
Сообщение от Ordu (ok), 14-Авг-20, 20:52 
> Сферические кони весьма хороши в вакууме. На практике же классический что-то никто не выбрасывает, хотя режимы энергосбережения существуют уже десятки лет.

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

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

121. "Выпуск Mcron 1.2, реализации cron от проекта GNU "  +/–
Сообщение от rvs2016 (ok), 18-Авг-20, 22:35 
> sleep_time = calc_time(when);
> sleep(sleep_time);
> do_job();

В таком кроне если кто-то выключил систему во время выполнения команды sleep(sleep_time), а потом включил её до истечения времени sleep_time, то команду do_job() уже будет некому запустить.

А в стандартном кроне если выполнение команды назначено на 5-тысячный год от рождества Христова, то на оставшиеся 3 тысячи лет ноутбук можно выключить и надеяться на то, что потомки его ко времени назначенного задания таки включат и в этом случае задание выполняться таки начнёт! Нужно оно там будет потомкам или не нужно - это другой вопрос. :-)

ps:
Ноутбук за это время скорее всего уже несколько раз "сгниёт". Но потомки его создадут заново. Причём может быть уже в соседней галактике. А может быть даже внутри VirtualBox и вообще только ради исторического и археологического интереса, ну и как дань уважения предкам :-).

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

122. "Выпуск Mcron 1.2, реализации cron от проекта GNU "  +/–
Сообщение от Совершенно другой аноним (?), 19-Авг-20, 11:37 
>> sleep_time = calc_time(when);
>> sleep(sleep_time);
>> do_job();
> В таком кроне если кто-то выключил систему во время выполнения команды sleep(sleep_time),
> а потом включил её до истечения времени sleep_time, то команду do_job()
> уже будет некому запустить.

Прошу прощения, не совсем понял о чём Вы. Если Если выключить во время выполнения sleep(), а потом включить до его истечения - так cron при включении ведь заново запуститься, и рассчитает время ожидания исходя из текущего времени запуска. вроде как с этой стороны проблем быть не должно.

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

126. "Выпуск Mcron 1.2, реализации cron от проекта GNU "  +/–
Сообщение от rvs2016 (ok), 23-Авг-20, 00:45 
> Прошу прощения, не совсем понял о чём Вы. Если Если выключить во
> время выполнения sleep(), а потом включить до его истечения - так
> cron при включении ведь заново запуститься, и рассчитает время ожидания исходя
> из текущего времени запуска. вроде как с этой стороны проблем быть
> не должно.

А. Ну да. Если в случае перезапуска крона предусмотрен перасчёт времени до ближайшего задания, то тогда всё нормально.

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

31. "Выпуск Mcron 1.2, реализации cron от проекта GNU "  +/–
Сообщение от Совершенно другой аноним (?), 14-Авг-20, 13:20 
> Планировщик, тоже потребляет ресурсы. В классическом кроне процедура отсчитывающая секунды
> и проверяющая нет ли заданий для запуска не сильно напрягается.

прошу прощения, не дописал. А отредактировать не могу. Для крона получится:


sleep_time = calc_time(when);
while (sleep_time > 0)
{ sleep(1);
  sleep_time--;
}
do_job();
[/codee]
Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

100. "Выпуск Mcron 1.2, реализации cron от проекта GNU "  –1 +/–
Сообщение от draw1 (?), 15-Авг-20, 01:20 
А в стандартном кроне реально подобным образом сделано? Или это домыслы на основании новости?

Я не пытаюсь подъ@%нуть, если что.
Просто мысль отсортировать задания по времени до наступления события, как минимум, чтоб не проверять каждый раз всю очередь - вроде бы настолько очевидна, что как-то сомнительно что до этого не додумались за столько лет. А если очередь заданий сортировать, то уж практически сразу приходит мысль, что зачем "просыпаться" периодически для бесполезных проверок, если тупо по первому элементу сразу видно через сколько наступит ближайшее событие и раньше просыпаться большого смысла нет...
Либо есть что-то ещё, для чего надо "просыпаться" даже заведомо "зная", что задания выполнять не понадобится, либо стандартный крон все-таки устроен не так примитивно, мне так кажется.

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

108. "Выпуск Mcron 1.2, реализации cron от проекта GNU "  +1 +/–
Сообщение от Forth (ok), 15-Авг-20, 11:33 
А почему никто не удосужился просто посмотреть? Это же проще всего.
Ubuntu 20.04, vixie cron 3.0pl1-136ubuntu1
Выдача strace:
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=60, tv_nsec=0}, 0x7ffc840b1930) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1535, ...}) = 0
stat("crontabs", {st_mode=S_IFDIR|S_ISVTX|0730, st_size=4096, ...}) = 0
stat("/etc/crontab", {st_mode=S_IFREG|0644, st_size=1042, ...}) = 0
stat("/etc/cron.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/etc/cron.d/popularity-contest", {st_mode=S_IFREG|0644, st_size=190, ...}) = 0
stat("/etc/cron.d/anacron", {st_mode=S_IFREG|0644, st_size=285, ...}) = 0
stat("/etc/cron.d/sysstat", {st_mode=S_IFREG|0644, st_size=396, ...}) = 0
stat("/etc/cron.d/atop", {st_mode=S_IFREG|0644, st_size=217, ...}) = 0
stat("/etc/cron.d/e2scrub_all", {st_mode=S_IFREG|0644, st_size=201, ...}) = 0
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f85d0b9eb10) = 3867
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=59, tv_nsec=0}, {tv_sec=58, tv_nsec=996789973}) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3867, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG, NULL) = 3867
wait4(-1, 0x7ffc840b1314, WNOHANG, NULL) = -1 ECHILD (Нет дочерних процессов)
rt_sigreturn({mask=[]})                 = -1 EINTR (Прерван системный вызов)
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1535, ...}) = 0
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=59, tv_nsec=0}, 0x7ffc840b1930) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1535, ...}) = 0
stat("crontabs", {st_mode=S_IFDIR|S_ISVTX|0730, st_size=4096, ...}) = 0
stat("/etc/crontab", {st_mode=S_IFREG|0644, st_size=1042, ...}) = 0
stat("/etc/cron.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/etc/cron.d/popularity-contest", {st_mode=S_IFREG|0644, st_size=190, ...}) = 0
stat("/etc/cron.d/anacron", {st_mode=S_IFREG|0644, st_size=285, ...}) = 0
stat("/etc/cron.d/sysstat", {st_mode=S_IFREG|0644, st_size=396, ...}) = 0
stat("/etc/cron.d/atop", {st_mode=S_IFREG|0644, st_size=217, ...}) = 0
stat("/etc/cron.d/e2scrub_all", {st_mode=S_IFREG|0644, st_size=201, ...}) = 0
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=60, tv_nsec=0},
----------
Делайте выводы сами, все понятно :)
Ответить | Правка | Наверх | Cообщить модератору

49. "Выпуск Mcron 1.2, реализации cron от проекта GNU "  –1 +/–
Сообщение от CAE (ok), 14-Авг-20, 15:04 
Это если заданий немного. Да и то есть сомнения, что при малом кол-ве заданий выигрыш заметен.
Кроме того, надо хотя бы раз в минуту проверять сдвиг реального времени от синхронизации. То есть просыпаться, даже если заданий почти нет. И вести пересчёт таймеров ожидания запуска в списке, если сдвиг произошёл. Плюс если локалтайм сменился - добро пожаловать в ад :)
Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

50. "Выпуск Mcron 1.2, реализации cron от проекта GNU "  +1 +/–
Сообщение от Совершенно другой аноним (?), 14-Авг-20, 15:18 
> Это если заданий немного. Да и то есть сомнения, что при малом
> кол-ве заданий выигрыш заметен.
> Кроме того, надо хотя бы раз в минуту проверять сдвиг реального времени
> от синхронизации. То есть просыпаться, даже если заданий почти нет. И
> вести пересчёт таймеров ожидания запуска в списке, если сдвиг произошёл. Плюс
> если локалтайм сменился - добро пожаловать в ад :)

В clock_nanosleep() есть TIMER_ABSTIME - можно ждать сразу до назначенного времени (времени ближайшего к выполнению задания), а дальше это уже больше проблемы ядра. По поводу localtime-а - тут, наверное, действительно может быть проблема.

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

55. "Выпуск Mcron 1.2, реализации cron от проекта GNU "  –1 +/–
Сообщение от CAE (ok), 14-Авг-20, 15:59 
Сигнал, EINTR и отсутствие remain. Мммм... Не уверен, что ABSTIME хороший выбор для планировщика.
Конечно, сигнал крону - это скорее редкость, хотя и не такая уж, crontab всяко должен сказать "reload plz".
upd. can restarted я не прочёл, прежде чем написал, да, ABSTIME можно.
Ответить | Правка | Наверх | Cообщить модератору

101. "Выпуск Mcron 1.2, реализации cron от проекта GNU "  –1 +/–
Сообщение от draw1 (?), 15-Авг-20, 01:58 
Если задания отсортированы, то не надо пересчитывать весь список - можно реализовать так, что будет достаточно пересчитать только время до первого элемента списка. Можно ли "немного про#@$ть" время запуска ближайшего задания в угоду экономии "пробуждений" - вопрос...

Смена локалтайма может доставить проблем независимо от того сортировано оно или нет. Часто ли меняется локалтайм? Но даже если часто - если есть задания с высокой периодичностью то это спокойно отловится и скомпенсируется при выполнении ближайшего задания и будет условно "незаметно". Если все задания с низкой периодичностью, то относительная ошибка может быть тоже условно "незаметна" (относительная погрешность времени запуска будет малой). Тут снова тот же компромисс: либо оперативная компенсация всяких "чудес" с текущим временем, либо экономия на "холостых" пробуждениях. "Насколько важна точность по времени запуска заданий" - ответ на этот вопрос, имхо, и определяет как лучше делать планировщик.
Можно, например, как вариант, штатный запуск заданий делать на основе сортировки (точно зная через сколько надо просыпаться), но если время до ближайшего задания больше какого-то порога (компромисс = точность времени запуска заданий), то планировать дополнительное "холостое" пробуждение для анализа не изменилась ли обстановка и т. п.

Можно с ходу придумать с десяток всяких подобных вариаций, ухищрений и оптимизаций. Это относительно несложно реализовать и вроде бы довольно очевидно, поэтому мне кажется что уж, как минимум, до подобного всяко додумались ещё в незапамятные времена (и, думаю, неоднократно).

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

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

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




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

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