Bug 3193 - [FR] [5.0] (ana)cron'ed jobs could behave better
: [FR] [5.0] (ana)cron'ed jobs could behave better
Status: ASSIGNED
: Sisyphus
(All bugs in Sisyphus/crontabs)
: unstable
: all Linux
: P3 enhancement
Assigned To:
:
:
:
: 4245
: 17728
  Show dependency tree
 
Reported: 2003-10-22 16:13 by
Modified: 2011-03-26 11:13 (History)


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


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2003-10-22 16:13:40
Было бы замечательно перевести дистрибутивные 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 From 2006-02-17 16:41:13 -------
Было бы здорово иметь такую фичу к 3.1...
------- Comment #2 From 2007-09-17 19:25:45 -------
Created an attachment (id=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 #3 From 2008-02-13 11:12:59 -------
Тж. https://lists.altlinux.org/pipermail/devel/2008-February/069577.html
------- Comment #4 From 2008-03-16 23:23:39 -------
Тж. http://www.opennet.ru/tips/info/1620.shtml (taskset -b)
------- Comment #5 From 2008-10-21 14:29:37 -------
Просьба заценить http://git.altlinux.org/people/mike/packages/?p=idlewrap.git в
качестве обёртки для запуска updatedb, makewhatis и osec.  Скрипт несовершенен
и может быть доработан в сторону /etc/sysconfig/idlewrap, но будто работает.
------- Comment #6 From 2008-11-13 01:32:42 -------
2mike: Посмотри service-0.5.17-alt1 и vixie-cron-4.1.20060426-alt4-3-g3f23a87,
это проект дистрибутивного решения.
Для тех cronjob'ов, запуск которых можно вообще пропустить при определённых
условиях, нужен какой-то другой подход.
------- Comment #7 From 2008-11-20 01:46:49 -------
Дим, почитав 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 From 2008-11-20 13:28:52 -------
(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 From 2008-11-20 16:08:59 -------
Лёш, я вот про этот сюжет:
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 From 2008-11-20 18:29:08 -------
(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 From 2008-11-20 20:13:35 -------
Лёш, 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 From 2009-11-15 23:19:08 -------
Ау.  Патчи приветствуются или игнорируются?  В community@ опять напомнили про
эту неприятность.
------- Comment #13 From 2010-09-17 01:09:15 -------
ping -- поставил 20100909, опять makewhatis колотится об диск и тормозит первую
загрузку системы.  Какой вообще сермяжный толк с anacron, портящего жизнь по
утрам?
------- Comment #14 From 2011-03-26 11:13:01 -------
Поправочка: ionice -t критично, иначе будем почём зря обламываться под ovz. 
Отправил idlewrap-0.2.1-alt1.