From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sat, 10 May 2003 01:10:59 +0400 From: Denis Smirnov To: community@altlinux.ru Subject: Re: [Comm] Re: Message-ID: <20030509211059.GB22737@localhost.localdomain> References: <20030428192549.GO25074@localhost.localdomain> <20030506132429.GE4534@solemn.turbinal.org> <20030506134941.GE1605@localhost.localdomain> <20030507113037.GL374@osdn.org.ua> <20030507123312.GA12934@localhost.localdomain> <20030508082948.GG374@osdn.org.ua> <20030508191358.GA7673@localhost.localdomain> <4969971133.20030509030642@udm.ru> <20030508231257.GB15096@localhost.localdomain> <416723046.20030509113959@udm.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aVD9QWMuhilNxW9f" Content-Disposition: inline In-Reply-To: <416723046.20030509113959@udm.ru> Sender: community-admin@altlinux.ru Errors-To: community-admin@altlinux.ru X-BeenThere: community@altlinux.ru X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: community@altlinux.ru List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Archived-At: List-Archive: List-Post: --aVD9QWMuhilNxW9f Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit 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 --aVD9QWMuhilNxW9f Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+vBljPuR8c4jhFKIRAjgcAKCPXMzruNEvZwvJ1lBm6w1iY7yYrACeKhkW CXdnoKDHDMRU/NzuNE6R128= =GV88 -----END PGP SIGNATURE----- --aVD9QWMuhilNxW9f--