3193 2003-10-22 16:13:40 +0400 [FR] [5.0] (ana)cron'ed jobs could behave better 2020-09-07 22:03:09 +0300 1 1 4 Development Sisyphus crontabs unstable all Linux CLOSED WORKSFORME P3 enhancement --- 4245 17728 1 mike placeholder aen boyarsh dd1email erthad evg glebfm ildar ktirf ldv legion nbr placeholder solo vt vvk vx8400 qa-sisyphus oldest_to_newest 10340 0 mike 2003-10-22 16:13:40 +0400 Было бы замечательно перевести дистрибутивные 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 35929 1 mike 2006-02-17 16:41:13 +0300 Было бы здорово иметь такую фичу к 3.1... 55301 2 2202 mike 2007-09-17 19:25:45 +0400 Created attachment 2202 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" --- 63079 3 mike 2008-02-13 11:12:59 +0300 Тж. https://lists.altlinux.org/pipermail/devel/2008-February/069577.html 65969 4 mike 2008-03-16 23:23:39 +0300 Тж. http://www.opennet.ru/tips/info/1620.shtml (taskset -b) 79949 5 mike 2008-10-21 14:29:37 +0400 Просьба заценить http://git.altlinux.org/people/mike/packages/?p=idlewrap.git в качестве обёртки для запуска updatedb, makewhatis и osec. Скрипт несовершенен и может быть доработан в сторону /etc/sysconfig/idlewrap, но будто работает. 81051 6 ldv 2008-11-13 01:32:42 +0300 2mike: Посмотри service-0.5.17-alt1 и vixie-cron-4.1.20060426-alt4-3-g3f23a87, это проект дистрибутивного решения. Для тех cronjob'ов, запуск которых можно вообще пропустить при определённых условиях, нужен какой-то другой подход. 81358 7 mike 2008-11-20 01:46:49 +0300 Дим, почитав 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: спасибо за участие! 81375 8 legion 2008-11-20 13:28:52 +0300 (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'ов отличается от задачи лимитов и это нужно ещё придумать как реализовать. Я бы вынес её отдельным багом. 81389 9 mike 2008-11-20 16:08:59 +0300 Лёш, я вот про этот сюжет: 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@ и заказчиками, эксплуатирующими такие системы. 81402 10 legion 2008-11-20 18:29:08 +0300 (In reply to comment #9) > Эта бага повешена аккурат о той задаче, которая отличается от решённой. И > детский набросок решения для _исходной_ задачи Ещё раз, в исходной задаче описано две проблемы: 1. запуск cronjob'ов с высоким приоритетом; 2. пропуск не существенных cronjob'ов при определённых условиях. Первую задачу limited решает. Я предлагал, вторую задачу вынести в отдельный баг, а не первую :) > (вместе с более современным > наброском idlewrap) тоже доступен. Осталось поправить запускалки кронджобов. Мне кажется задача #2 не так проста и не глядя запускать cronjob'ы через idlewrap нельзя. Вместе с тем, критерии какие нужно/не нужно запускать зависят от машины. > schedtool(8) можешь особо не смущаться Добавить его не проблема. Будет ещё опциональная ручка. > В limited поддержка schedtool и ionice мне _пока_ кажется бесцельной, хотя для больших > систем возможность организовать affinity и отодвинуть третьестепенные сервисы > совсем в фон может быть и интересной -- это лучше поговорить с support@ и > заказчиками, эксплуатирующими такие системы. Мне кажется это полезной возможностью. Без этого у нас были только /etc/security/limits. 81411 11 mike 2008-11-20 20:13:35 +0300 Лёш, 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 103168 12 mike 2009-11-15 23:19:08 +0300 Ау. Патчи приветствуются или игнорируются? В community@ опять напомнили про эту неприятность. 112237 13 mike 2010-09-17 01:09:15 +0400 ping -- поставил 20100909, опять makewhatis колотится об диск и тормозит первую загрузку системы. Какой вообще сермяжный толк с anacron, портящего жизнь по утрам? 119492 14 mike 2011-03-26 11:13:01 +0300 Поправочка: ionice -t критично, иначе будем почём зря обламываться под ovz. Отправил idlewrap-0.2.1-alt1. 192272 15 mike 2020-09-07 22:03:09 +0300 Сочтём, что уже сделано в нынешних service и vixie-cron или idlewrap. У меня вопрос отпал (возможно, после переезда на SSD лет десять назад). 2202 2007-09-17 19:25:45 +0400 2007-09-17 19:25:45 +0400 load-sensitive cronjob wrapper relax text/plain 813 mike IyEvYmluL3NoCiMgQSB0aW55IHdyYXBwZXIgdG8gbGV0IGNyb24gcnVuIGpvYnMgKGxpa2Ugc2xv Y2F0ZSkgd2l0aCBhIHJlc3BlY3QKIyB0byB0aGUgc3lzdGVtIGxvYWQuIFdyaXR0ZW4gYnkgPG1p Y2hhZWwuc2hpZ29yaW5AdXNhLm5ldD4KCkxPQUQ9MC41CSMgLWw6IHRoZSBkZWZhdWx0IGNyaXRp Y2FsIGxvYWQgdmFsdWUKVElNRT0yCQkjIC10OiAxIGZvciB0aGUgdmVyeSBsYXN0IG1pbnV0ZSwg MiA9PiA1IG1pbiwgMyA9PiAxNSBtaW4KT05DRT0wCQkjIC1vOiBvbmNlIHBlciBkYXkKCndoaWxl IDoKZG8KCWNhc2UgJDEgaW4KCQktbHwtLWxvYWQpIExPQUQ9JDI7IHNoaWZ0OyBzaGlmdDsgY29u dGludWU7OwoJCS10fC0tdGltZSkgVElNRT0kMjsgc2hpZnQ7IHNoaWZ0OyBjb250aW51ZTs7CgkJ LW98LS1vbmNlKSBPTkNFPTE7ICBzaGlmdDsgICAgICAgIGNvbnRpbnVlOzsKCQktaHwtLWhlbHAp IGhlYWQgLWwgNiAiJDAiOyBleGl0IDA7OwoJCSopCSAgIGJyZWFrOzsKCWVzYWMKZG9uZQpMT0FE PSQoZWNobyAiMTAwKiRMT0FEInxiYykKTE9BRD0ke0xPQUQlLip9Ck5PVz0kKGVjaG8gIjEwMCpg L3Vzci9iaW4vY3V0IC1mJFRJTUUgLWQnICcgL3Byb2MvbG9hZGF2Z2AifGJjKQpOT1c9JHtOT1cl Lip9ClsgIiQoL2Jpbi9scyAtbCAtLXRpbWU9dXNlICIkMSJ8L3Vzci9iaW4vY3V0IC1jNDMtNDgp IiA9IFwKCSIkKC9iaW4vZGF0ZSArIiViICVkIikiIF0gJiYgZXhpdCAwCSMgJDEgYWxyZWFkeSB1 c2VkIHRvZGF5CgkJCQkJCSMgKG1heWJlIG5vdCBieSB1cyA6LS8gKQpbICROT1cgLWxlICRMT0FE IF0gJiYgZXZhbCAkKgoK