propeller
написал 5 мая 2006 года в 01:40 (685 просмотров)
Ведет себя
как мужчина; открыл 53 темы в форуме, оставил 158 комментариев на сайте.
Какое-то время назад прошел разговор об одновременном старте сервисов при загрузке системы. утверждалось, что при этом будет вам заметный прирост скорости старта системы.
рассмотрим однопроцессорный случай.
Теперь вопрос. а откуда прирост скорости-то? ну вот запустили ssh и не ожидая его сообщения об [OK] пустили gpm. замечательно, но ведь процессорного времени они в итоге съедят столько же, сколько и при раздельном пуске.
или утверждается, что уж слишком много приходится разнообразным сервисам чего-то тупо ждать особо не нагружая ресурсы?
Последние комментарии
- OlegL, 17 декабря 2023 года в 15:00 → Перекличка 21
- REDkiy, 8 июня 2023 года в 9:09 → Как «замокать» файл для юниттеста в Python? 2
- fhunter, 29 ноября 2022 года в 2:09 → Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt? 6
- Иванн, 9 апреля 2022 года в 8:31 → Ассоциация РАСПО провела первое учредительное собрание 1
- Kiri11.ADV1, 7 марта 2021 года в 12:01 → Логи catalina.out в TomCat 9 в формате JSON 1
ecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.
Ага, именно из-за ожидания, поговаривают, и выигрыш.
Вам в сторону SMF: http://www.sun.com/bigadmin/content/selfheal/smf-quickstart.html
Тут пишут скромно:
> Large systems boot faster by starting services in parallel according to their dependencies.
На Solaris Day сильно хвастались, что благодаря этому им действительно удалось существенно уменьшить время загрузки ОС.
Ну зачем сразу Solaris? Берём прави^W кхм… дистрибутив SuSE 10.0 и наблюдаем параллельную загрузку скриптов в линуксе уже из «коробки» ;).
Процессорное время, затрачиваемое на запуск каждого сервиса в отдельности, ничтожно. Поэтому утверждается, что в многозадачной ОС независящие друг от друга сервисы (в данном контексте — скрипты инициализации сервисов) можно запускать и одновременно.
заметный прирост секунды в две-три, если брать стандартную систему, где не так много чего стартует…
конечно, паралельная загрузка сервисов уменьшит время загрузки.
тогда уж скорее наоборот — чем больше всего стартует, тем больше прирост (если у тебя один процесс, то просто не будет прироста).
Короче, как я понял, штука полубестолковая для десктопов, а для серверов плевать грузятся они 2 минуты, или 3.
для десктопов, наверное, да, бестолковая…
конечно, если ты не любитель меряться пип..ми с друзьями.
а вот для серверов все-таки очень нужно. представь, если у тебя что-то с ним случилось и надо быстро поднять его, а он у тебя грузится долго… тогда каждая секунда становится часом…
Мужики, неправда ваша. Для десктопов параллельная загрузка сервисов очень полезная фича. Ну сами посудите, пока у вас запускаются всякие cups, cron, может локальные ФТПшники и прочее, вы уже в KDE читаете новости с nixp.ru. Ну не удобно ли? ;)
А вот серверу, как раз, и не важно — загрузится он за 2 или за 3 минуты. Всё равно перезагружается он не чаще, чем раз в месяц ;). Но лишней данная фича всё равно не будет.
ну.. это смотря какой дусктоп часто грузится..
домашний или рабочий — очень редко у меня грузятся.
правда, дома я сделал сервис «AutoRun» — в котором у меня грузится X-сессия.. и запускается она сразу же как только возможно для её работоспособности — после поднятия сети.
А зачем грузить десктоп?
есть же Suspend to disk?
есть.. но у меня, к примеру, не вышло его настроить.
руки? хз. за вечер, что пробовал включить его — перегружался комп больше, чем за предыдущие полгода..
Есть конечно. Свопа только нету. Или вот вариант: swap есть, только размером в два раза меньше объёма оперативной памяти.
А ещё некоторым модулям сносит крышу при «просыпании».
Да и на самом-то деле, на данный момент, думаю, очень мало пользователей отправляют свои машинки в suspend вместо их выключения (ну, по крайней мере, среди моих знакомых). Но если будем говорить о личных предпочтениях, то лично я свой десктоп вообще не выключаю — ни в suspend, ни как-либо ещё ;). Это ж не значит, что оптимизация процесса загрузки никому не нужна.