Comments 35
Можно попросить вас уточнить какой дистрибутив линукса вы используете?
Debian, если точнее - отдельно ядро от Armbian (главное чтобы к железу подошло) и минимальный образ ОС, сделанный через debootstrap.
Все остальное ставиллсь из пакетов вручную.
То есть, это как бы не совсем дистрибутив.
Как вам удалось выкорчевать из дебиана systemd?
Легко )
Точных шагов не помню навскидку, но логика там такая:
Есть пакет установки sysv-скриптов - при его инсталляции удаляется systemd.
После этого на его установку в apt ставится блок. Если какой-то софт (многие) просит установить systemd - в абсолютном большинстве случаев запрос просто игнорируется, и все работает. Там могут идти в пакете юниты, им для работы нужен systemd, поэтому просит - но по факту он там не нужен.
Попадалось что-то, что вот прямо требовало и без него само не поставилось - но это было что-то такое нужное, что я даже не помню как называлось.
Пакет sysvinit-core. System-V - тормоз. Надо было ставить finit(Debian): “Finit is a simple alternative to SysV init and systemd, reverse engineered from the EeePC fastinit. Focus is on small and embedded systems” Свежак - Finit v4.17(released this last month) HowTo: Finit on Debian GNU/Linux. Сайт Finit Project
Интересно, посмотрю
А чем именно тот - тормоз? Строго говоря init может быть вообще скриптом на баш, который запускает по очереди все что положено, а потом ничего не делает.
Я так тоже запускал, там тормозить тогда просто негде...
Видимо у человека sys v init ассоциируется с последовательной загрузкой сервисов, и тогда загрузка действительно сильно дольше.
По порядку - не обязательно последовательно.
Кто мешает запускать ветками?
Другой вопрос, что глупо запускать сервис, рабочий каталог которого ещё не подмонтирован, потому что устройство не инициализирована - sys v init просто делает это по порядку шаг за шагом, а systemd быстро "запускается", но не факт что тот сервис будет работать, пока не отработают другие блоки.
По идее должен потом стартовать, но есть нюансы
Видно, что вы явно не трогали systemd, там зависимости и таргеты с первой версии
Так я об этом и говорю - зависимости и таргеты.
Которые ТЕОРЕТИЧЕСКИ должны работать так как ожидается, но если вы посмели что-то поменять - начинаются пляски с бубном в поисках конкретно той зависимости из-за которой конкретно эта хрень не работает.
SYS V init просто запускает всё по очереди. Это не всегда удобно, иногда приходится потом шаманить с кроном или еще как - и systemd должен был эту проблему решить, но создал другие проблемы.
Поэтому сейчас у себя я его при первой же возможности выпиливаю - не люблю неожиданностей.
Кто мешает запускать ветками
да, я в курсе что в некоторых дистрибутивах для ускорения загрузки использовали такие выкрутасы, но по мне так это лишает процесс инициализации простоты и прозрачности, за которые мне нравился sys v init.
"Так вот, первое решение - можно разместить своп-файл в самой памяти " - то есть если памяти мало, мы туда ещё своп вобьём? А памяти не станет от такого ещё меньше - то есть эффект будет противоположный ожидаемому?
Вот как раз об этом писал: конечно, он занимает место в памяти - но как правило память не работает все 100%, там висит куча страниц, которые программы запросили, получили, но в данный момент не используют - и вот они-то пакуются компактно в уголок. Страницы памяти, если что, блоки.
А когда уже и там места нет - тогда на диск, хорошо но медленно...
zram интересный инструмент, возможно где и пригодится, а вот swapspace я бы не стал ставить т.к. сложно спрогнозировать как оно будет работать.
Во первых зачем удалять своп файл? Что бы освободить место? Т.е. вы это место чем то другим займете? Но тогда автоматом свопфайл не получится создать.
Верно, тогда не получится.
Но тут вопрос в другом: дисковый своп вообще штука довольно тормозная, и если система начинает постоянно туда писать и читать - с одной стороны, она не помрет сразу, а с другой - вы это явно заметите, сделаете выводы и перестанете ее грузить - и место освободится.
Что-то типа колеса-докатки в машине: незаменимо в экстренных случаях, но не мешается в 99% времени. Как-то так.
А занимать место можно всякими временными файлами, кешем, распакованными архивами и прочим.
если система начинает постоянно туда писать и читать - с одной стороны, она не помрет сразу, а с другой - вы это явно заметите
это спорное утверждение.
Это получится заметить только если своп не на ссд а на обычном харде + настолько мало оперативы, что системе постоянно приходится жонглировать памятью. Например если памяти меньше 4 гиг и открываешь штук 100 вкладок в хроме. В остальных случаях заметить как система свопится проблематично.
zram интересный инструмент, возможно где и пригодится
Самое забавное, если у вас смарт или планшет на андроиде, то вы с высокой вероятностью пользуетесь zram постоянно.
Когда пришлось достать из сундука древний планшет с 4GB оперативки - я подумал о том, что надо бы активировать zram - а опаньки, он там уже используется. :)
PS: и в iPhone то же самое - Почему iPhone хватает 4 ГБ ОЗУ ( https://habr.com/ru/companies/droider/articles/514158/ )
Обсуждалось неоднократно: https://www.google.com/search?q=zram+habr
https://wiki.archlinux.org/title/Zram_(Русский) en
Если в используемом вами ядре по умолчанию включен zswap, его стоит отключить, чтобы он не работал как кэш подкачки перед zram.https://wiki.gentoo.org/wiki/Zram Примеры под OpenRC и systemd
Ну и немного тюнинга:
Есть такие параметры ядра, vm.swappiness и vm.page-cluster.Первый отвечает за то, насколько "злее" ОС будет пытаться сбросить страницы в своп: чем больше - тем злее, от 0 до 200.
С одной стороны, его надо бы поставить поменьше, чтобы реже лазить в медленный HDD, или реже портить записью SSD, с другой стороны - можно поставить побольше, чтобы активнее использовать компрессию zram.
а не нужно использовать своп в памяти(zram) и своп на диске(swap, zswap) одновременно и проблем не будет.
По поводу того какое выбрать значения для параметра vm.swappiness то на kernel.org есть информация от которой можно уже отталкиваться:
For in-memory swap, like zram or zswap, as well as hybrid setups that have swap on faster devices than the filesystem, values beyond 100 can be considered. For example, if the random IO against the swap device is on average 2x faster than IO from the filesystem, swappiness should be 133 (x + 2x = 200, 2x = 133.33).
Кстати, недавно накатил armbian(Ubuntu 26.04) на старый девайс и там по умолчанию используется(на самом деле нет) значение 100, по крайней мере в файле /etc/sysctl.conf указанно именно это значение, а по факту sysctl vm.swappiness выдавал дефолтные 60. Походу там не учли повальную "системдизацию" которая предписывает согласно man sysctl.conf что:
This man page describes the configuration files for procps sysctl. If you are us‐ ing systemd-sysctl(8), refer to sysctl.d(5) and note that it won’t use the file /etc/sysctl.conf.
где отправляют смотреть man sysctl.d
SYNOPSIS
/etc/sysctl.d/*.conf
/run/sysctl.d/*.conf
/usr/local/lib/sysctl.d/*.conf
/usr/lib/sysctl.d/*.conf
...
DESCRIPTION
At boot, systemd-sysctl.service(8) reads configuration files from the above directories to config‐ ure sysctl(8) kernel parameters.
то есть, используя systemd во все поля нужно помнить что файл /etc/sysctl.conf теперь не учитывается и нужно прописать параметры ядра, например в том же /etc/sysctl.d/*.conf что в принципе я и сделал:
# cat /etc/sysctl.d/zram.conf
vm.swappiness=100
# sysctl -p /etc/sysctl.d/zram.conf
vm.swappiness = 100
# sysctl vm.swappiness
vm.swappiness = 100
Статье место в 90х. У вас настолько мало диска, что вам жалко постоянный своп иметь? Но вы не боитесь, что в момент когда он понадобится свободного места не будет? Или не найдётся непрерывного участка? И да, там верно пишут, SRAM устарел, а zswap с 7.0 ядра даже сжатые страницы писать научился.
Почему меня эта тема вообще заинтересовала: у меня, как уже писал раньше, сейчас такой весьма спартанский рабочий компьютер: перепрошитый под Debian TV-box, процессор ARM, питание всего 5 вольт от USB-зарядки.
Там EMCC или MicroSD с очень несвежим ядром armbian
Там именно что еммс, микросхема на 32 гигабайта.
Поэтому мне жалко диска )
Кстати, ядро там в общем-то 6.7.12, не такое уж доисторическое - но все равно писать на еммс своп без необходимости - такое себе...
Но это всё равно не отменяет главного момента - если вам жалко выделить место под свап, потому что оно может понадобиться, то что делать, когда оно понадобится, а него не будет?
То же самое, что бывает когда оно понадобилось - а его нет: от чего-то отказаться. Удалить какие-то файлы, закрыть лишнюю программу...
то что делать, когда оно понадобится, а него не будет?
что поделать, это всегда компромисс, да и своп на диске тоже не гарантия что его хватит когда "корабль" даст сильную течь и перед неизбежной смертью попытаться з..ть ваш диск.
32 гига на все. Остальное - по сети.
Вы представляете своп по сети? )
а zswap с 7.0 ядра даже сжатые страницы писать научился.
эм, а поподробнее можно ?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d38fab605c66
Ну может чуть поторопился. Состояние "реализовано, но пока отключено".
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d38fab605c66
это про zram, а не zswap
Ну может чуть поторопился. Состояние "реализовано, но пока отключено".
да не, судя по доку с kernel.org она должна работать начиная с ядра 7.0, смотри функцию compressed_writeback
хотя, как по мне, для простых смертных она будет мало востребована(как и обычный writeback), особенно для тех кто выбирает zram из за отказа иметь своп на медленном и менее надёжном ресурсе как диск(hdd,ssd ...).
Когда памяти мало