Если я увеличу размер своп файла, то Линукс его будет использовать. В случае если у меня закончится память вместе со свопом, тогда Линукс выгрузит программы. А процесс гибернации не будет работать, потому что своп будет занят.
С моим же скриптом стабильность системы не нарушится. Процесс гибернации будет работать даже если памяти и свопа не достаточно. Я разделил эти две задачи.
Моё утверждение такое. Если вы используете гибернацию, то вам нужно резервировать под эту задачу дисковое пространство. Никакого магического решения для этого нет.
Вы уже отказались от вашего тезиса про то что вы "не хотите резервировать пространство, ведь его можно использовать как-то более разумно" - это очевидный бред сумасшедшего )))) нарушение базовой логики.
И на ваш тезис про увеличение свопа - это тоже костыль ненадежный. Уже 10 раз объяснил. Но вам видимо трудно это понять.
Нет. Увеличение свопа не даст гарантии. Уже проверено. И 10 раз вам ответил почему. Почитайте комментарии выше.
Если вы так уверены в своей правоте, то напишите статью и предложите свое решение. Я на Хабре не видел хорошего решения. Как в принципе и в других источниках. Пишется только о кривости системы гибернации. Что в общем-то имеет место быть
Засылалю вас вопросами. Вы так рьяно свою точку зрения хотите пропихнуть. Тогда отвечайте на конкретные вопросы
Как вы хотите уходить в гибернацию без зарезервированного для этого пространства? если вы используете это пространство для чего-то другого (файлы, своп, что угодно), тогда у вас просто не будет пространства для гибернации. Логика ))))
Так что тут всё просто. Если вы хотите использовать глубокий сон, тогда вам нужно просто смириться с тем, что кусок памяти по размеру такой же как оператика, вы отдаете под эти нужды. Иначе у вас не будет этого самого места. Оно не может появится неоткуда. Это нарушение логики.
Откуда 48ГБ. У меня в системе 32ГБ. И для гибернации ровно столько и нужно. Своп не участвует в этом процессе. Там данные и так на диске
Вы изначально понимаете эту проблему неправильно. И пытаетесь прикрутить туда какой-то костыль перенастраивая ядро. При этом такие настройки крутите, которые вообще никак не связаны с описанной проблемой и напрямую влияют на стабильность работы системы.
Ответ не очевиден. Я так пробовал. Это не работает. Своп будет занят и места там не будет достаточно. Придется выделять больше, чем нужно. А так я выделя как раз минимальный необходимый объем. Ваше "решение" (которое не работает) это костыль. А мое решение - это 100% обход несовершенства системы + вы вольны настаивать swapinness и кэширование файлов для задач приложений, а не для задач хайбернейта. Я на компьютере не хайбернейтом занимаюсь, а рабочими задачами. Так что я хочу настраивать ядро под задачи, а не под хайбернейт.
Так что очевидно, что костылистось моего решения в бесконечное количество раз меньше вашего костыля
дефолтные настройки любого дистрибутива. какой бы он ни был не позволяют использовать систему как обычный пользователь windows/macosx - включил, поработал, ушёл делать другие дела не думая о состоянии операционной системы. из-за неправильного дизайна системы хайбернейта.
вот как работает swapiness = 0, если вам интересно. специльно для вас сделал тест на пару дней:
как видно swapiness = 0 не гарантирует того, что swap не будет использоваться..
тюнить систему дальше, регулировать настройки очистки файлового кеша или отключать кеш файловой системы совсем - нет спасибо. мне это не нужно. я считаю, что это костыть - ломать одно из-за того, что где-то другое криво разработано. и в любом случае все эти костыли не будут давать 100% гарантии того, что система уйдёт в глубокий сон.
ваш комментарий про то что ядру достеточно только того, что в свопе будет достоточно места - так же неверен. я это всё тчательно продебажил. с логами в journal. нужен непрерывный участок. ну или ещё как-то. но просто достаточное свободное место - не гарантия ухода в хайбернейт. проверено неоднократьно.
я использую ubuntu studio. система уже настроена очень хорошо. и я не хочу менять настройки ядра, которые уже на мой взгляд идеальны.
скрипт-сервис, написанный мною - результат многолетнего опыта использования ОС Линукс на десктопе. Работает на любой systemd системе.
ваш камень предкновения - это дешёвое дисковое пространство, кое для меня ничего ровным счётом не значит.. если у меня будет памяти 96ГБ, то я выделю ровно столько же для hibernate. у буду жить спокойно не думаю ни о чем. я знаю что мой сервис никогда меня не подведёт. по крайней мере за годы работы не было, как говорится ни единого разрыва
дефолтные настройки и поведение ядра и systemd в ubuntu 24.04 не позво ляют всего того о чём вы пишите. я неоднократно получал систему с полным отключением из-за разряда батареи. hibernate не уходит даже если достаточно памяти в своп - можете спорить с реальностью, но это так.. собственно поэтому я и написал этот скрипт/сервис... и сейчас я вообще не думаю о том сколько чего у меня используется.. я могу установить kubeflow - и только сама установка этого зверя займёт за одну минуту больше памяти, чем месяц работы какого-нибудь сервера, которых у меня на работе целое множество и своп там не используется вообще, потому что ресурсы спланированы так, чтобы памяти просто на всё хватало.. у нас на работе весь продакшн занимающий террабайты (если не петабайты) хранятся в кеше - представьте себе... а на рабочей машине всё по-другому.
ну такой вердикт.. по-умолчанию мой линукс не работает с батареей как это делает windows/macos - очень ненадёжно. а подход, который я описал, даёт мне гарантию 100% без каких-то переживаний.. могу работать до отсечки и заниматься только моими проектами без мониторинга системы в приципе. делал я это для себя и вполне доволен. поделился опытом. если вам не нравится или не подходит, или вы можете предложить более лаконичное решение - флаг в руки - покажите - расскажите.
я не единственный юзер у которого такие проблемы с линуксом. не отрицаю что это может быть связано с железом.. но в общем мне то какое дело. железо это или несовершенство архитектуры (использовать своп для хибернейта без возможности резервирования пространства для собственно хибернейта - это очевидный косяк в архитектуре как ни крути. какие тут могут быть аргументы). Я хочу использовать компьютер для своих целей, а не для того, чтобы администрировать своп - этим я могу заняться в рабочее время, когда мне за это платят деньги. а на домашнем компьютере я хочу просто быть довольныс пользователем. и моё решение делает меня вполне довольным
я всё это протестировал много раз. swappiness = 0 далеко не эквивалентно отключению свопа ни в одной из ситуаций. да в общем-то из цитаты вашей это тоже можно прочитать. своп может и не используется на сервере на какой-то узкоспециализированной задаче.. но ноутбуке разработчика с 32 ГБ RAM с активным использованием различного ПО - компиляторов, сборщиков, докера, браузера, почты, нейронок и т.п., избежать попадания памяти в своп - задача неосуществимая. нет такой настройки в линуксе. и даже если поставить 128ГБ оперативки, то всё равно своп будет использоваться.
проверено личным опытом. swappiness=0 работает в течение часа может быть. но в реальной работе оно ничего не даёт - своп в процессе работы заполнится ровно на столько же как и обычно какой swappiness вы не поставите. если мы говорим про лаптоп разработчика.
а во-вторых, как я уже написал в статье, недостаточно просто того, чтобы в свопе было достаточно места для гибернации. нужен непрерывный участок. память как известно фрагментируется (и своп тоже фрагментируется). в таком случае Вам на рабочий стол нужно выводить не только загруженность свопа, но и его карту :)
и как-то это сложно, не находите, и странно. Я заканчиваю работу с лаптопом, просто закрывая крышку. С чего вдруг меня должно интересовать как занят мой своп. И с чего вдруг может появится уверенность (я ведь наверняка знаю что это не так), что ситуация не изменится, когда я отвернусь, и своп вдруг окажется занят больше чем нужно.
И в конце концов, представьте себе как в 2025-ом году вы объясняете это пользователю WIndows или Mac, что перед тем как закрыть крышку ноутбука, им нужно проверить место в свопе.. и если что, то отключить своп и потом снова подключить (это кстати тоже сработает только на пару минут, даже со swappiness=0).
поэтому мой логичный трейд-офф, это кастомный сервис, который делает всю эту работу за меня. вполне несложный. и, кстати говоря, он срабатывает не всегда с первого раза. линуксу хватает считанных долей секунд, чтобы занять место в только что подключенном свопе, даже когда в другом свопе ещё половина свободна (приоритеты можно покрутить, но это тоже не гарант). однако скрипт на таймере, и поэтому ему стабильно таки удаётся погрузить систему в глубокий сон со второго или третьего раза
даже не знаю что поставить во главе ответа под грифом "во-первых" :)) скажу так. обе причины одинаково важны. начну с первой и самой простой. это просто не сработает :)) да. можно почитать документацию. этот параметр ничего не гарантирует и тем более не отключает своп. запись в своп продолжится
и второе: не слишком ли это круто - отказаться от записи в своп (если я понял вашу идею правильно) только из-за недочёта в дизайне системы? похоже на "лечение симптомов", а не решение проблемы. да ещё и таким радикальным способом, продолжая ухудшать этот самый дизайн
на второй вопрос уже ответили. а про первый соглашусь. но у меня лично systemd. делал, как говорится, для себя. но подход описан подробно - можно адаптировать. скрипт несложный
да. в arch wiki можно многое почерпнуть само собой. на мой взгляд вся проблема заключается в том, что линукс зачем-то использует swap для нужд хибернейта. и это доставляет много трудностей при длительной работе без перезагрузки. если кто-то умеет отправлять в гибернацию без подключения раздела как swap, то буду рад научиться этому
Если я увеличу размер своп файла, то Линукс его будет использовать. В случае если у меня закончится память вместе со свопом, тогда Линукс выгрузит программы. А процесс гибернации не будет работать, потому что своп будет занят.
С моим же скриптом стабильность системы не нарушится. Процесс гибернации будет работать даже если памяти и свопа не достаточно. Я разделил эти две задачи.
Моё утверждение такое. Если вы используете гибернацию, то вам нужно резервировать под эту задачу дисковое пространство. Никакого магического решения для этого нет.
Вы уже отказались от вашего тезиса про то что вы "не хотите резервировать пространство, ведь его можно использовать как-то более разумно" - это очевидный бред сумасшедшего )))) нарушение базовой логики.
И на ваш тезис про увеличение свопа - это тоже костыль ненадежный. Уже 10 раз объяснил. Но вам видимо трудно это понять.
Нет. Увеличение свопа не даст гарантии. Уже проверено. И 10 раз вам ответил почему. Почитайте комментарии выше.
Если вы так уверены в своей правоте, то напишите статью и предложите свое решение. Я на Хабре не видел хорошего решения. Как в принципе и в других источниках. Пишется только о кривости системы гибернации. Что в общем-то имеет место быть
Засылалю вас вопросами. Вы так рьяно свою точку зрения хотите пропихнуть. Тогда отвечайте на конкретные вопросы
Как вы хотите уходить в гибернацию без зарезервированного для этого пространства? если вы используете это пространство для чего-то другого (файлы, своп, что угодно), тогда у вас просто не будет пространства для гибернации. Логика ))))
Так что тут всё просто. Если вы хотите использовать глубокий сон, тогда вам нужно просто смириться с тем, что кусок памяти по размеру такой же как оператика, вы отдаете под эти нужды. Иначе у вас не будет этого самого места. Оно не может появится неоткуда. Это нарушение логики.
Откуда 48ГБ. У меня в системе 32ГБ. И для гибернации ровно столько и нужно. Своп не участвует в этом процессе. Там данные и так на диске
Вы изначально понимаете эту проблему неправильно. И пытаетесь прикрутить туда какой-то костыль перенастраивая ядро. При этом такие настройки крутите, которые вообще никак не связаны с описанной проблемой и напрямую влияют на стабильность работы системы.
RTFM
Ну вы ерунду определенно пишите ))).
Если я отключу своп, то в гибурнацию система никак не уйдет. И тут мой скрипт - это единственное решение.
Да. Вариант добавить оперативы - это хорошо. Но это смена железа.
И тогда встречный вопрос. Как без моего скрипта уйти в хайбернейт с отключенным свопом?
Думайте перед тем как писать. Если вы так хорошо в этом разбираетесь. То напишите тут статью. И публика её прокомментирует.
И ещё. Вам не кажется странным, что вы единственный, кто поставил дизлайк и критикует этот подход? ;)
И оперативки мне хватает. Система работает без тормозов. и не требует моего внимания от слова совсем
Ответ не очевиден. Я так пробовал. Это не работает. Своп будет занят и места там не будет достаточно. Придется выделять больше, чем нужно. А так я выделя как раз минимальный необходимый объем. Ваше "решение" (которое не работает) это костыль. А мое решение - это 100% обход несовершенства системы + вы вольны настаивать swapinness и кэширование файлов для задач приложений, а не для задач хайбернейта. Я на компьютере не хайбернейтом занимаюсь, а рабочими задачами. Так что я хочу настраивать ядро под задачи, а не под хайбернейт.
Так что очевидно, что костылистось моего решения в бесконечное количество раз меньше вашего костыля
дефолтные настройки любого дистрибутива. какой бы он ни был не позволяют использовать систему как обычный пользователь windows/macosx - включил, поработал, ушёл делать другие дела не думая о состоянии операционной системы. из-за неправильного дизайна системы хайбернейта.
вот как работает swapiness = 0, если вам интересно. специльно для вас сделал тест на пару дней:
как видно swapiness = 0 не гарантирует того, что swap не будет использоваться..
тюнить систему дальше, регулировать настройки очистки файлового кеша или отключать кеш файловой системы совсем - нет спасибо. мне это не нужно. я считаю, что это костыть - ломать одно из-за того, что где-то другое криво разработано. и в любом случае все эти костыли не будут давать 100% гарантии того, что система уйдёт в глубокий сон.
ваш комментарий про то что ядру достеточно только того, что в свопе будет достоточно места - так же неверен. я это всё тчательно продебажил. с логами в journal. нужен непрерывный участок. ну или ещё как-то. но просто достаточное свободное место - не гарантия ухода в хайбернейт. проверено неоднократьно.
я использую ubuntu studio. система уже настроена очень хорошо. и я не хочу менять настройки ядра, которые уже на мой взгляд идеальны.
скрипт-сервис, написанный мною - результат многолетнего опыта использования ОС Линукс на десктопе. Работает на любой systemd системе.
ваш камень предкновения - это дешёвое дисковое пространство, кое для меня ничего ровным счётом не значит.. если у меня будет памяти 96ГБ, то я выделю ровно столько же для hibernate. у буду жить спокойно не думаю ни о чем. я знаю что мой сервис никогда меня не подведёт. по крайней мере за годы работы не было, как говорится ни единого разрыва
дефолтные настройки и поведение ядра и systemd в ubuntu 24.04 не позво ляют всего того о чём вы пишите. я неоднократно получал систему с полным отключением из-за разряда батареи. hibernate не уходит даже если достаточно памяти в своп - можете спорить с реальностью, но это так.. собственно поэтому я и написал этот скрипт/сервис... и сейчас я вообще не думаю о том сколько чего у меня используется.. я могу установить kubeflow - и только сама установка этого зверя займёт за одну минуту больше памяти, чем месяц работы какого-нибудь сервера, которых у меня на работе целое множество и своп там не используется вообще, потому что ресурсы спланированы так, чтобы памяти просто на всё хватало.. у нас на работе весь продакшн занимающий террабайты (если не петабайты) хранятся в кеше - представьте себе... а на рабочей машине всё по-другому.
ну такой вердикт.. по-умолчанию мой линукс не работает с батареей как это делает windows/macos - очень ненадёжно. а подход, который я описал, даёт мне гарантию 100% без каких-то переживаний.. могу работать до отсечки и заниматься только моими проектами без мониторинга системы в приципе. делал я это для себя и вполне доволен. поделился опытом. если вам не нравится или не подходит, или вы можете предложить более лаконичное решение - флаг в руки - покажите - расскажите.
я не единственный юзер у которого такие проблемы с линуксом. не отрицаю что это может быть связано с железом.. но в общем мне то какое дело. железо это или несовершенство архитектуры (использовать своп для хибернейта без возможности резервирования пространства для собственно хибернейта - это очевидный косяк в архитектуре как ни крути. какие тут могут быть аргументы). Я хочу использовать компьютер для своих целей, а не для того, чтобы администрировать своп - этим я могу заняться в рабочее время, когда мне за это платят деньги. а на домашнем компьютере я хочу просто быть довольныс пользователем. и моё решение делает меня вполне довольным
отличная идея! начну переписывать тесты на astroEqual!
я всё это протестировал много раз. swappiness = 0 далеко не эквивалентно отключению свопа ни в одной из ситуаций. да в общем-то из цитаты вашей это тоже можно прочитать. своп может и не используется на сервере на какой-то узкоспециализированной задаче.. но ноутбуке разработчика с 32 ГБ RAM с активным использованием различного ПО - компиляторов, сборщиков, докера, браузера, почты, нейронок и т.п., избежать попадания памяти в своп - задача неосуществимая. нет такой настройки в линуксе. и даже если поставить 128ГБ оперативки, то всё равно своп будет использоваться.
проверено личным опытом. swappiness=0 работает в течение часа может быть. но в реальной работе оно ничего не даёт - своп в процессе работы заполнится ровно на столько же как и обычно какой swappiness вы не поставите. если мы говорим про лаптоп разработчика.
а во-вторых, как я уже написал в статье, недостаточно просто того, чтобы в свопе было достаточно места для гибернации. нужен непрерывный участок. память как известно фрагментируется (и своп тоже фрагментируется). в таком случае Вам на рабочий стол нужно выводить не только загруженность свопа, но и его карту :)
и как-то это сложно, не находите, и странно. Я заканчиваю работу с лаптопом, просто закрывая крышку. С чего вдруг меня должно интересовать как занят мой своп. И с чего вдруг может появится уверенность (я ведь наверняка знаю что это не так), что ситуация не изменится, когда я отвернусь, и своп вдруг окажется занят больше чем нужно.
И в конце концов, представьте себе как в 2025-ом году вы объясняете это пользователю WIndows или Mac, что перед тем как закрыть крышку ноутбука, им нужно проверить место в свопе.. и если что, то отключить своп и потом снова подключить (это кстати тоже сработает только на пару минут, даже со swappiness=0).
поэтому мой логичный трейд-офф, это кастомный сервис, который делает всю эту работу за меня. вполне несложный. и, кстати говоря, он срабатывает не всегда с первого раза. линуксу хватает считанных долей секунд, чтобы занять место в только что подключенном свопе, даже когда в другом свопе ещё половина свободна (приоритеты можно покрутить, но это тоже не гарант). однако скрипт на таймере, и поэтому ему стабильно таки удаётся погрузить систему в глубокий сон со второго или третьего раза
будем надеться, что оно хотя бы не поменяется в следующей версии :D
даже не знаю что поставить во главе ответа под грифом "во-первых" :))
скажу так. обе причины одинаково важны.
начну с первой и самой простой. это просто не сработает :)) да. можно почитать документацию. этот параметр ничего не гарантирует и тем более не отключает своп. запись в своп продолжится
и второе: не слишком ли это круто - отказаться от записи в своп (если я понял вашу идею правильно) только из-за недочёта в дизайне системы? похоже на "лечение симптомов", а не решение проблемы. да ещё и таким радикальным способом, продолжая ухудшать этот самый дизайн
на второй вопрос уже ответили. а про первый соглашусь. но у меня лично systemd. делал, как говорится, для себя. но подход описан подробно - можно адаптировать. скрипт несложный
амбициозный проект с кучей трудностей. наверное стоит упомянуть и ABI, который у Rust не стабилен, а у C может не меняться десятилетиями
да. в arch wiki можно многое почерпнуть само собой. на мой взгляд вся проблема заключается в том, что линукс зачем-то использует swap для нужд хибернейта. и это доставляет много трудностей при длительной работе без перезагрузки. если кто-то умеет отправлять в гибернацию без подключения раздела как swap, то буду рад научиться этому