[Comm] Re:
ASA
=?iso-8859-1?q?llb_=CE=C1_udm=2Eru?=
Пт Май 9 10:39:59 MSD 2003
Hello Denis,
Friday, May 9, 2003, 4:12:57 AM, you wrote:
>> Вы только что описали систему поднятия сервисов в WinNT/2000/XP ;)
DS> :)
>> DS> Необязательные -- только обеспечивают соблюдение очерёдности.
>> А это хорошая идея. Относительно. Но очередность уже есть в
>> SysV.
DS> В SyV она тольно последовательная. Я имею в виду что-то вроде "почтовый
DS> сервер должен запускать после антивирусного сервиса, если таковой
DS> имеется".
Как мы отметили ниже, такое можно реализовать без потери
совместимости с SysV.
DS> Соответственно последовательность работы загрузчика следующая -- берётся
DS> список поднимаемый сервисов, строится дерево зависимостей, дальше
DS> запускаем скрипты инициализации для N сервисов, из тех, которые можно
DS> инициализировать сразу. После завершения каждого из скриптов смотрим что
DS> следующее можно инициализировать.
Я протестую против "все враз". Если запустить слишком много
программ, то они в сумме отработают медленее, чем в сумме каждая
по отдельности, из-за слишком большого количества
разноупорядоченных обращений к диску (что-то типа hard drive
seek test ;). Пример - в той же вынде выделите побольше иконок
на рабочем столе и нажмите Enter ;) Поэтому можно ввести
ограничение на одновременную работу не более 4*CPU скриптов враз.
DS> > отдельно от других подобных ему. И тут может возникнуть
DS> > нетривиальная задача развязки обязательных и необязательных
DS> > зависимостей.
DS> А в чём собственно её нетривиальность? Автор пакета должен суметь чётко
DS> сформулировать что необходимо его сервису для работы.
Нетривиальность вообще в создании такого дерева.
DS> Насчёт завязки на диск -- что это, например? Сервер БД на что больше
DS> завязан? IMHO сервер БД можно запускать как только смонтированы все
DS> разделы и подняты интерфейсы (если он не локальный).
то же самое можно сказать про большиснтво других сервисов.
Итак, fsck :), squid, smb
А в целом, да, ты прав, нужно какое-то другое деление.
DS> Для многопроцессорных систем польза от многопоточного запуска, IMHO,
DS> очевидна.
Но не для hdd.
DS> Ещё можно вспонмить известный факт с многопроцессной компиляцией (make
DS> -jN), которая увеличивает скорость компиляции даже на однопроцессорных
DS> машинах.
Потому что тут постоянно запускаются одни и те же программы
(gcc, make, ...), которые уже лежат в кэше.
DS> > В сам S-скрипт (те, которые лежат в init.d) добавляем еще одно
DS> > поле типа как это сделано для chkconfig. В этом поле указываем
DS> > класс скрипта - дисковый или нет.
DS> Тоже вариант. Только вот с классом скрипта непонятно -- как их делить?
DS> Какой у Bind'а? А если он обслуживают тучу зон? А у иксов?
Думать надо...
DS> > Можно пойти дальше и ввести еще одно поле в S-скрипте -
DS> > зависимость от уже стартовавшего сервиса. Реализация именно
DS> > такого способа задания зависимостей не представляет вообще
DS> > никакого труда.
DS> Собственно этим и можно в результате сделать точно ту схему, о которой я
DS> писал выше. Только тогда придётся шерстить все скрипты.
И?
--
Best regards,
ASA mailto:llb на udm.ru
Подробная информация о списке рассылки community