А всё-таки Леннарт Поттеринг знает своё дело

Поттеринг няшка, системд - лучшее что случилось с линупсом.

Пора пилить systemd-kerneld

он наверное уже запилил, иначе как объяснить «полёт» системы

Похоже на истории о: есть платная программа, обрабатывает данные пару часов; в новой версии смогли оптимизациями уменьшить время на 15%; потом кто-то переписал часть и стала обрабатывать за пару минут, что порушило все планы релизов программы.

Фу! Скатился! Этой технологии нет и двадцати лет, она не проверена временем, в отличие от Motif, Tcl/Tk, X.Org, sysvinit и прочего говна etc.

Так устранением недоделок, которые раньше рандомно приводили к ощутимым задержкам перед запуском новых процессов (уже запущенные процессы со всеми systemd работают одинаково шустро). Если с systemd 230 при очередном запуске даже какого-го нибудь mc в очередной раз сидишь и ждёшь не менее 5-ти секунд, то с systemd 234 такого уже нет.

А многопоточный софт постоянно генерирует новые процессы.

Вот в 28-й Федоре, например, systemd версии 238, и система работает довольно шустро. В 6-й Магейе из коробки systemd версии 230, и система не настолько отзывчивая.

«Прошла зима, настало лето - спасибо партии за это» (ц)

Всё-таки ты удивительно невежественен.

И какое значение это имеет для владельцев серверов? Там же поголовно старые убунты и дебианы стоят, без системды вообще.

Там же поголовно старые убунты и дебианы стоят, без системды вообще

Дай-ка ссылку на статистику.

На серверах полно тех же CentOS'ов, в которых уже давно systemd.

А так я про десктоп пишу.

Так после одного только обновления systemd на практике спавн новых процессов внезапно значительно оживает.

после одного только обновления systemd на практике спавн новых процессов внезапно значительно оживает.

Я не знаю, что такое «спавн» (ты же не имеешь в виду vfork + exec, которыми мало кто пользуется), но просто на всякий случай: порожением процессов и управлением памятью занимается ядро.

Пакет требует сборки от root'а.

у мну и под юзером нормально собирается

Никто и не говорит, что вызов fork() обрабатывает именно systemd. Но, факт остаётся фактом - при запуске очередного процесса systemd начинает что-то обрабатывать, и чем старее версия systemd, тем большее кол-во page fault'ов в системе этот systemd генерирует. И это каким-то образом тормозит появление нового процесса.

А у меня из под обычного юзера сборка падает с такой строчкой в логе:

awk: cmd. line:1: fatal: cannot open file `/etc/login.defs' for reading (Отказано в доступе)

У тебя была какая-то бяка с резолвером имён. При обновлении конфиг сбросился, и резолвинг стал работать быстрее, а не вылетать по таймауту, как было раньше. Некоторый софт использует блокирующее разрешение имён, и ощутимо тормозит, если там какие-то проблемы.

Возможно, теперь у тебя включен кеширующий systemd-resolved. До 233 его выключали, потому что там была удалённая уязвимость. В 234 уязвимость починили, и стало возможным его включать.

Так что выключай systemd-resolved и смотри, стало ли снова всё плохо.

systemd

ну дык выбора же нет, остлаьные deprecated .

Ждём systemd 300 koi8-r only.

чем старее версия systemd, тем большее кол-во page fault'ов в системе этот systemd генерирует. И это каким-то образом тормозит появление нового процесса.

Оспадетыбожемой. Какой бред.

Ага, вот уйдет линус на пенсию, а на его место возьмут леннарта. Вот тогда заживем!

Дарья Петровна: Истинно вам говорю: 4 мая 1925 года Земля налетит... на небесную ось!

Ну, я задействовал latencytop, который фиксировал весьма длительные page fault'ы в такие моменты. Потом я узнал про системный счётчик page fault'ов и команду «ps -o min_flt,maj_flt,cmd,args,uid,gid 1». И счёт минорных page fault'ов как и раньше шёл на тысячи, так и сейчас. Только теперь latencytop показывает, что на них уходит в 10 раз меньше времени.

Никто и не говорит, что вызов fork() обрабатывает именно systemd

Но некий saahriktu говорит, что с новым systemd стал быстрее работать fork (если под «спавн» он имел в виду именно fork).

счёт минорных page fault'ов как и раньше шёл на тысячи, так и сейчас. Только теперь latencytop показывает, что на них уходит в 10 раз меньше времени.

Что systemd животворящий делает!

стал быстрее работать fork

Не обязательно сам системный вызов fork(). Речь про всю цепочку, которая происходит от fork'а до начала практической работы процесса.

Речь про всю цепочку, которая происходит от fork'а до начала практической работы процесса.

Ага, и для этого ты считаешь страничные сбои в systemd? Круто.

А про резолвинг имен тебе уже сказали.

что с новым systemd стал быстрее работать fork

А пися-то, пися увеличилась на 10см с новым системд?

выбора же нет

OpenRC

Меня-то ты почему спрашиваешь? У меня вообще Debian Stable.

А какой там сейчас стейбл? /мрачно косится на роутер на котором который год стоит нетронутый шестой дебиан/

Если с systemd 230 при очередном запуске даже какого-го нибудь mc в очередной раз сидишь и ждёшь не менее 5-ти секунд, то с systemd 234 такого уже нет.

Т.е. до последней версии systemd у тебя просто загружал систему собой, тебя всё устраивало, после чего тормоза пофиксили, а ты и опять рад.

Видимо без оптимизма адептам systemd не прожить, психика не выдерживает.

Может здесь и на резолвинг больше времени уходило. Не буду спорить.

Но, по данным latencytop всё дело было именно в page fault'ах. Которые systemd генерирует тысячами. Вот на данный момент:

# ps -o min_flt,maj_flt,cmd,args,uid,gid 1
 MINFL  MAJFL CMD                         COMMAND                       UID   GID
 15872     74 /sbin/init                  /sbin/init                      0     0

На втором месте по минорным pagefault'ам bash - 11296. su и ps суммарно даже одну тысячу не сгенерировали.

Только теперь latencytop показывает, что на них уходит в 10 раз меньше времени.

И что, прямо реально всё в секунды складывалось?

Latencytop — не волшебная палочка. Желательно понимать, что он там измеряет.

оно по ходу умерло https://github.com/OpenRC/openrc/tree/0.38.x

Загрузка системы и тогда была шустрой. В истории сохранилось

Startup finished in 6.477s (kernel) + 19.058s (userspace) = 25.536s

Startup finished in 6.787s (kernel) + 19.977s (userspace) = 26.765s

А вот запуск новых процессов рандомно притормаживал. Уже запущенные процессы работали нормально.

Некоторый софт использует блокирующее разрешение имён, и ощутимо тормозит, если там какие-то проблемы.

некоторый или почти весь?

Нет разницы между «некоторый» и «почти весь».

Пакет требует сборки от root'а.

Леннарт Поттеринг знает своё дело

Ну, может, я и запутался в том как его использовать. Не буду спорить.

Так сколько там было всего? В миллисекунды-то хоть сложилось?

Да. Раньше в графе «maximum» у page fault'ов было более чем 110 миллисекунд.

А если дисковый кеш прогреть, прочитав нужные файлы перед запуском?

saahriktu

systemd

ШТА?!

Пакет требует сборки от root'а.

Серьезно?

232

Какой-то троллинг странный...

Это saahriktu

Ты бы ещё у erzent-а уроки по сборке пакетов попросил.

Да, наличие файлов в кэше помогает снизить длительность Page fault'ов, например, с 103,4 миллисекунд до каких-нибудь 28,4 миллисекунд.

Серьезно?

Не из под root'а:

awk: cmd. line:1: fatal: cannot open file `/etc/login.defs' for reading (Отказано в доступе)

Образцовое знание своего дела (трудно сказать, кем, но определенно образцовое).

Так от root'а же пакет собирается. Обновлять пакеты всё равно от root'а.

Так от root'а же пакет собирается.

Зачем? Хотя нет, не отвечай.