Bug 3193 - [FR] [5.0] (ana)cron'ed jobs could behave better
Summary: [FR] [5.0] (ana)cron'ed jobs could behave better
Status: CLOSED WORKSFORME
Alias: None
Product: Sisyphus
Classification: Development
Component: crontabs (show other bugs)
Version: unstable
Hardware: all Linux
: P3 enhancement
Assignee: placeholder@altlinux.org
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on: 4245
Blocks: 17728
  Show dependency tree
 
Reported: 2003-10-22 16:13 MSD by Michael Shigorin
Modified: 2020-09-07 22:03 MSK (History)
15 users (show)

See Also:


Attachments
load-sensitive cronjob wrapper (813 bytes, text/plain)
2007-09-17 19:25 MSD, Michael Shigorin
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Shigorin 2003-10-22 16:13:40 MSD
Было бы замечательно перевести дистрибутивные cronjobs на запуск из-под batch(1)
или функционально эквивалентный для обеспечения их запуска в "удобное" время, а
не вскоре после загрузки системы (при недоступности ее в 4 часа ночи и
включенном anacron).  Или как минимум -- запускать anacron из-под nice(1).

Некоторые ссылки по теме:
http://www.altlinux.ru/pipermail/community/2001-February/003398.html
http://www.altlinux.ru/pipermail/community/2001-February/003403.html
http://www.altlinux.ru/pipermail/sisyphus/2003-October/029323.html
http://www.altlinux.ru/pipermail/sisyphus/2003-October/029350.html
Comment 1 Michael Shigorin 2006-02-17 16:41:13 MSK
Было бы здорово иметь такую фичу к 3.1...
Comment 2 Michael Shigorin 2007-09-17 19:25:45 MSD
Created attachment 2202 [details]
load-sensitive cronjob wrapper

пример использования:
--- /etc/cron.daily/slocate.cron на основе исходного из Black Cat 6.02
/usr/local/bin/relax -l 0.1 -t 3 --once /usr/bin/slocate -u -e /tmp -e
"/var/tmp,/usr/tmp,/afs,/net,/proc"
---
Comment 4 Michael Shigorin 2008-03-16 23:23:39 MSK
Тж. http://www.opennet.ru/tips/info/1620.shtml (taskset -b)
Comment 5 Michael Shigorin 2008-10-21 14:29:37 MSD
Просьба заценить http://git.altlinux.org/people/mike/packages/?p=idlewrap.git в качестве обёртки для запуска updatedb, makewhatis и osec.  Скрипт несовершенен и может быть доработан в сторону /etc/sysconfig/idlewrap, но будто работает.
Comment 6 Dmitry V. Levin 2008-11-13 01:32:42 MSK
2mike: Посмотри service-0.5.17-alt1 и vixie-cron-4.1.20060426-alt4-3-g3f23a87,
это проект дистрибутивного решения.
Для тех cronjob'ов, запуск которых можно вообще пропустить при определённых условиях, нужен какой-то другой подход.
Comment 7 Michael Shigorin 2008-11-20 01:46:49 MSK
Дим, почитав 0.5.18, мне вспомнилась та картинка о проекте создания качелей под деревом.  Фундамент для пакетного и администраторского наведения порядка по nice/ulimit для сервисов понравился (много откуда гвозди или вынимание единственного nice value из sysconfig можно будет вынимать), но:

- я-то предлагал не сервисы оборачивать, а задачи -- именно потому,
  что обобщить все cronjob'ы до одних требований обычно не получается
  (например, osec важнее slocate и тем более makewhatis);
- предложенная обёртка по имени idlewrap проста как двери (и даже 
  не проверяет ionice -t, согласен) -- но при этом содержит ещё одну
  мелкую приятную фичу, которая тут оказалась выплеснута с младенцем:
  idle CPU scheduling (schedtool -D), и одну побольше -- про питание.

Попробую проверить на себе и стенде (в т.ч. стареньком железе и используя anacron), хватит ли для crond NICE_PRIORITY=10 или idle prio заметно лучше.

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

2 legion: спасибо за участие!
Comment 8 Alexey Gladkov 2008-11-20 13:28:52 MSK
(In reply to comment #7)
> - я-то предлагал не сервисы оборачивать, а задачи -- именно потому,
>   что обобщить все cronjob'ы до одних требований обычно не получается
>   (например, osec важнее slocate и тем более makewhatis);

Но все эти задачи не должны иметь большой nice и ionice, если только запуск задач по cron не прямая задача сервера... но и это укладывается в идею общего выставления лимитов на crond.

Сначала реализация лимитов была только для задач cronjob'ов, но после обсуждения с Димой мы пришли к выводу, что лучше не городить огород для каждого сервиса, а обобщить ограничение ресурсов на все сервисы.

> - предложенная обёртка по имени idlewrap проста как двери (и даже 
>   не проверяет ionice -t, согласен) -- но при этом содержит ещё одну
>   мелкую приятную фичу, которая тут оказалась выплеснута с младенцем:
>   idle CPU scheduling (schedtool -D), и одну побольше -- про питание.

Я не стал добавлять schedtool в limited, потому что меня смутил его man-страница:

SCHED_IDLEPRIO [ patch needed ] SCHED_IDLEPRIO is similar to SCHED_BATCH, but was explicitely designed to consume only the time the CPU is idle. No iteractive boosting is done. If you used SCHED_BATCH in the -ck kernels this is what you want since 2.6.16

Я согласен с Димой, что задача по пропуску некоторых cronjob'ов отличается от задачи лимитов и это нужно ещё придумать как реализовать. Я бы вынес её отдельным багом.
Comment 9 Michael Shigorin 2008-11-20 16:08:59 MSK
Лёш, я вот про этот сюжет: http://www.intuit.ru/department/se/intuml/1/01_02.gif

Эта бага повешена аккурат о той задаче, которая отличается от решённой.  И детский набросок решения для _исходной_ задачи (вместе с более современным наброском idlewrap) тоже доступен.  Осталось поправить запускалки кронджобов.

Если охота повесить багу для успешно (IMHO) реализованного в service-0.5.17+ -- ну... можно :-)  И сразу закрыть.

---

schedtool(8) можешь особо не смущаться -- там о том, что в -ck семантика IDLE была присуща классу BATCH; смержен CFS scheduler был ещё в 2.6.23 и на M41/2.6.25 -D работает.

Для M40/2.6.18 можно сделать откат на -B или просто оставить nice 10..20, это не столь важно -- а ionice -c3 там уже работало.

http://lkml.indiana.edu/hypermail/linux/kernel/0603.1/0930.html
http://kerneltrap.org/node/8059

---

В limited поддержка schedtool и ionice мне _пока_ кажется бесцельной, хотя для больших систем возможность организовать affinity и отодвинуть третьестепенные сервисы совсем в фон может быть и интересной -- это лучше поговорить с support@ и заказчиками, эксплуатирующими такие системы.
Comment 10 Alexey Gladkov 2008-11-20 18:29:08 MSK
(In reply to comment #9)
> Эта бага повешена аккурат о той задаче, которая отличается от решённой.  И
> детский набросок решения для _исходной_ задачи

Ещё раз, в исходной задаче описано две проблемы:
1. запуск cronjob'ов с высоким приоритетом;
2. пропуск не существенных cronjob'ов при определённых условиях.

Первую задачу limited решает. Я предлагал, вторую задачу вынести в отдельный баг, а не первую :)

> (вместе с более современным
> наброском idlewrap) тоже доступен.  Осталось поправить запускалки кронджобов.

Мне кажется задача #2 не так проста и не глядя запускать cronjob'ы через idlewrap нельзя. Вместе с тем, критерии какие нужно/не нужно запускать зависят от машины.

> schedtool(8) можешь особо не смущаться

Добавить его не проблема. Будет ещё опциональная ручка.

> В limited поддержка schedtool и ionice мне _пока_ кажется бесцельной, хотя для больших
> систем возможность организовать affinity и отодвинуть третьестепенные сервисы
> совсем в фон может быть и интересной -- это лучше поговорить с support@ и
> заказчиками, эксплуатирующими такие системы.

Мне кажется это полезной возможностью. Без этого у нас были только /etc/security/limits.
Comment 11 Michael Shigorin 2008-11-20 20:13:35 MSK
Лёш, niceness -- это не приоритетность, а обратная величина -- пусть будет "скромность" :)

---

Одна часть разницы задач -- в гранулярности объекта: сервисы vs задачи из-под одного (двух дублирующих, неважно) из них.  При этом вариант "занайсить весь anacron" предлагался как "на скору руку".

Вы с Димой решили более фундаментальную задачу в этом же направлении, но её применимость к _этой_ баге ограничивается самым дубовым из изначально предложенных вариантов -- "nice anacron" с поправкой на современные технологии(tm) в виде ionice.

---

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

Что конкретно этому мешает?  Или какая для updatedb и makewhatis зависимость приоритета от машины? (для osec -- уже выслушал и принял мнение rider@)

В крайнем случае /etc/cron.*/* обычно %config(noreplace), если вдруг откуда-то такая зависимость вылезет.  А как вылезет -- так и будем систематизировать, поскольку вероятность этого IMHO пренебрежимо мала.

---

Добавлять поддержку в индивидуальные cronjob-ы предлагаю так:
http://git.altlinux.org/people/mike/packages/?p=slocate.git;a=commitdiff;h=218cfbfd25b937fcb81722978980a4963d31276f
Comment 12 Michael Shigorin 2009-11-15 23:19:08 MSK
Ау.  Патчи приветствуются или игнорируются?  В community@ опять напомнили про эту неприятность.
Comment 13 Michael Shigorin 2010-09-17 01:09:15 MSD
ping -- поставил 20100909, опять makewhatis колотится об диск и тормозит первую загрузку системы.  Какой вообще сермяжный толк с anacron, портящего жизнь по утрам?
Comment 14 Michael Shigorin 2011-03-26 11:13:01 MSK
Поправочка: ionice -t критично, иначе будем почём зря обламываться под ovz.  Отправил idlewrap-0.2.1-alt1.
Comment 15 Michael Shigorin 2020-09-07 22:03:09 MSK
Сочтём, что уже сделано в нынешних service и vixie-cron или idlewrap.
У меня вопрос отпал (возможно, после переезда на SSD лет десять назад).