Re: [Comm] Re:

Denis Smirnov
1970-01-01T00:00:02Z

[-- Attachment #1: Type: text/plain, Size: 4112 bytes --]

On Fri, May 09, 2003 at 11:39:59AM +0500, ASA wrote:

> DS> В SyV она тольно последовательная. Я имею в виду что-то вроде "почтовый
> DS> сервер должен запускать после антивирусного сервиса, если таковой
> DS> имеется".
> Как мы отметили ниже, такое можно реализовать без потери
> совместимости с SysV.

В какой момент должен запускаться скрипт, если для него ничего не указано?
Считать его зависимых от всех предыдущих по номеру?

> DS> Соответственно последовательность работы загрузчика следующая -- берётся
> DS> список поднимаемый сервисов, строится дерево зависимостей, дальше
> DS> запускаем скрипты инициализации для N сервисов, из тех, которые можно
> DS> инициализировать сразу. После завершения каждого из скриптов смотрим что
> DS> следующее можно инициализировать.
> Я протестую против "все враз". Если запустить слишком много
> программ, то они в сумме отработают медленее, чем в сумме каждая
> по отдельности, из-за слишком большого количества
> разноупорядоченных обращений к диску (что-то типа hard drive
> seek test ;). Пример - в той же вынде выделите побольше иконок
> на рабочем столе и нажмите Enter ;) Поэтому можно ввести
> ограничение на одновременную работу не более 4*CPU скриптов враз.

Это конфигурируемо должно быть. По-умолчанию 4*CPU -- оптимум.

> DS> > отдельно от других подобных ему. И тут может возникнуть
> DS> > нетривиальная задача развязки обязательных и необязательных
> DS> > зависимостей.
> DS> А в чём собственно её нетривиальность? Автор пакета должен суметь чётко
> DS> сформулировать что необходимо его сервису для работы.
> Нетривиальность вообще в создании такого дерева.

В смысле в создании дерева по меткам, или в проставлении меток
зависимости?

> DS> Насчёт завязки на диск -- что это, например? Сервер БД на что больше
> DS> завязан? IMHO сервер БД можно запускать как только смонтированы все
> DS> разделы и подняты интерфейсы (если он не локальный).
> то же самое можно сказать про большиснтво других сервисов.
> Итак, fsck :), squid, smb
> А в целом, да, ты прав, нужно какое-то другое деление.

squid часть времени своего запуска почти не насилует хард. Кроме того кэш
сквида может случайно быть на другом харде. А smb при запуске вообще вроде
почти ничего не делает (разве что конфиги читает).

> DS> Для многопроцессорных систем польза от многопоточного запуска, IMHO,
> DS> очевидна.
> Но не для hdd.

Ну на многопроцессных системах вполне может оказаться что данные разных
процессов на разных разделах. Тестировать это всё надо.

> DS> Ещё можно вспонмить известный факт с многопроцессной компиляцией (make
> DS> -jN), которая увеличивает скорость компиляции даже на однопроцессорных
> DS> машинах.
> Потому что тут постоянно запускаются одни и те же программы
> (gcc, make, ...), которые уже лежат в кэше.

Это да. Но, IMHO, основные задержки при запуске системы сейчас это
DNS-запросы (и прочая сетевая активность) во время поднятия сервисов, и
таки загрузка процессора теми же скриптами.

> DS> > В сам S-скрипт (те, которые лежат в init.d) добавляем еще одно
> DS> > поле типа как это сделано для chkconfig. В этом поле указываем
> DS> > класс скрипта - дисковый или нет.
> DS> Тоже вариант. Только вот с классом скрипта непонятно -- как их делить?
> DS> Какой у Bind'а? А если он обслуживают тучу зон? А у иксов?
> Думать надо...

Мне кажется, что не удастся это разделить.

> DS> > Можно пойти дальше и ввести еще одно поле в S-скрипте -
> DS> > зависимость от уже стартовавшего сервиса. Реализация именно
> DS> > такого способа задания зависимостей не представляет вообще
> DS> > никакого труда.
> DS> Собственно этим и можно в результате сделать точно ту схему, о которой я
> DS> писал выше. Только тогда придётся шерстить все скрипты.
> И?

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

--
С уважением, Денис

http://freesource.info

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]