Я вам уже ответил ранее, что swappiness выставлять — решение без необходимости увеличения объёма swap-файла, а раз мы вольны его увеличивать, то этой манипуляции не требуется.
Основной тезис из начала вашей статьи:
Неважно, какой у вас размер swap. Гибернация может не сработать даже если на swap достаточно свободного места. Догадайтесь, почему??? ... Да — фрагментация. Похоже, система пытается выделить непрерывный участок в swap.
Если я увеличу размер своп файла, то Линукс его будет использовать
У вас проблема в понимании. Не линукс использует своп, а вы. Это вам не винда, где система пользуется вами, а не вы ею. Своп должен быть задан такого объёма, который вы, своим использованием, не займёте в нормальных условиях — и под гибернацию место останется.
Также стоит отметить, что при гибернации по умолчанию RAM сжимается, а при неудачной гибернации система попытается отсечь наименее нужные данные, поэтому места может быть и меньше.
Моё утверждение такое. Если вы используете гибернацию, то вам нужно резервировать под эту задачу дисковое пространство
А в каком моменте я с этим утверждением спорил? Потрудитесь указать.
"не хотите резервировать пространство, ведь его можно использовать как-то более разумно" - это очевидный бред сумасшедшего )))) нарушение базовой логики.
В чём нарушение? Ваш скрипт держит это пространство неиспользованным до начала гибернации, а штатное решение позволяет системе скинуть туда то, что не влезает в RAM при пиковой загруженности. Абсолютно все кейсы, где работает ваше решение, продолжают работать на штатном. Просто штатное, в духе линукса, дополнительно даёт бонусные возможности под вашу собственную ответственность: выдержать больше нагрузки ценой невозможности гибернации ДО СНИЖЕНИЯ этой нагрузки. А без свопа ваша система такую нагрузку попросту не выдержала бы, приведя к фризу/крашу. Риторический вопрос: что лучше?)
Если вы так уверены в своей правоте, то напишите статью и предложите свое решение
Писать статью об очевидном моменте использования — бред. Здесь не нужно никакой статьи, у большинства людей (включая меня) всё прекрасно работает из коробки, достаточно просто установить нужный объём swap.
Так это же проблема вашего использования. Если своп будет занят, значит, вы выделили недостаточно свопа!
я выделя как раз минимальный необходимый объем
Но вам же всё равно приходится выделять отдельный файл для гибернации, помимо основного свопа. А без свопа в принципе нельзя.
И оперативки мне хватает
Если бы хватало, не забивался бы своп. Вы ведь понимаете, что он чем-то занимается? Это что-то — ваше. Возможно, без свопа у вас просто не возникает таких нагрузок, иначе бы фризило и OOM'илось.
Если я отключу своп, то в гибурнацию система никак не уйдет
Так ваш скрипт же это и делает — держит его по умолчанию отключенным.
Как вы хотите уходить в гибернацию без зарезервированного для этого пространства?
Я такого не утверждал. А утверждал следующее:
возможность уйти в гибернацию с 48 Гб … отрезая данный объём от дискового пространства, или … выдержать с его помощью больший пик
имея ввиду, что включенный своп принесёт бо́льшую пользу, чем отключенный.
Откуда 48ГБ. У меня в системе 32ГБ
Как, откуда? Вы же сами скинули скриншот, где из ваших 32 Гб перелилось ещё около 5 Гб в своп. Значит, в пиковой нагрузке у вас было занято точно больше 32 Гб, я взял следующее «круглое» для примера.
Своп не участвует в этом процессе. Там данные и так на диске Данные и так на диске, но нужно ещё не более одного объёма RAM для гибернации. Простая арифметика: выделите объём RAM + свопа сколько нужно в пике.
Вы изначально понимаете эту проблему неправильно. И пытаетесь прикрутить туда какой-то костыль перенастраивая ядро
Я вам предложил решение параметром ядра, исходя из того, что вы не хотите резервировать больше места. Исходя из вашего нового тезиса, что место на диске не является ценностью, я теперь вам предлагаю решение, как оно задумано по дизайну: увеличить объём своп-файла/раздела.
Вам не кажется странным, что вы единственный, кто поставил дизлайк и критикует этот подход?
Не кажется. Мне, как Linux-пользователю, кажется странным то, что вы так рьяно, как и я, отстаиваете свою точку зрения на костыльном решении, не пробуя рассмотреть штатно предусмотренные решения. А единственный я здесь в комментах потому, что подавляющему большинству осмысленных линуксоидов заголовок вашей статьи не был интересен в первую очередь.
дефолтные настройки любого дистрибутива. какой бы он ни был не позволяют использовать систему как обычный пользователь windows/macosx
Наверное, потому что это дистрибутивы Linux?
сделал тест на пару дней
Да, вижу проблему. Но я всё ещё не могу понять, какой смысл от гибернации с большим объёмом занятой памяти. Не вижу принципиальной разницы от отключенного по умолчанию свопа, потому что тогда вам банально не хватит оперативки, раз вы каким-то образом умудряетесь так её забивать.
дисковое пространство, кое для меня ничего ровным счётом не значит
из-за неправильного дизайна системы хайбернейта
Вы решаете костылями проблему, которую сами себе создали. Что лучше: иметь возможность уйти в гибернацию с 48 Гб занятой памяти, при этом фактически бесполезно отрезая данный объём от дискового пространства, или же иметь возможность выдержать с его помощью больший пик (вероятно, с вашим юзкейсом там могут выйти и все 64 Гб) вместо того, чтобы система постоянно уходила в OOM, и при этом НЕ терять возможности уйти в гибернацию с прежними 48 Гб? По-моему, ответ очевиден. Исходя из этого и дизайн.
если у меня будет памяти 96ГБ, то я выделю ровно столько же для hibernate
Если вы так категоричны, то могли бы и выделить столько, сколько вам с лихвой понадобится на своп + гибернацию + ещё чутка про запас. Тоже «устранило» бы несуществующую проблему.
Далее просто процитирую ваши же слова, без комментариев:
свободное место - не гарантия ухода в хайбернейт. проверено неоднократьно
не хочу менять настройки ядра, которые уже на мой взгляд идеальны
я могу установить kubeflow - и только сама установка этого зверя займёт за одну минуту больше памяти, чем месяц работы какого-нибудь сервера
Wat? Вы сравниваете установку софта с работой сервера, причём непонятно, имеете ли вы представление о разнице моментальных и временны́х единиц — объём оперативной памяти не может быть «за минуту» или «за месяц», это безвременная немонотонная единица.
но в общем мне то какое дело. железо это или несовершенство архитектуры
Дело вам как раз должно быть — железо вы самостоятельно не усовершенствуете, а вот архитектуру — запросто. Повторяюсь, GNU/Linux и его компоненты опенсорсны.
я не единственный юзер у которого такие проблемы с линуксом.
Вы не единственный юзер, у которого любые проблемы с линуксом. Это нормально, как видите, и у всех разный уровень. Всё пройдёт с опытом.
дефолтные настройки и поведение ядра и systemd в ubuntu 24.04 не позво ляют всего того о чём вы пишите.
Вот это и есть ваш камень преткновения. Дефолтные настройки дефолтного дистрибутива и не обязаны вам ничего более специфического, чем «включил—поработал—выключил», позволять.
я хочу просто быть довольныс пользователем. и моё решение делает меня вполне довольным
Правильное решение уже содержится в системе (о чём я рассказываю выше), а ваше личное не следует позиционировать как правильное, не разобравшись в вопросе до конца.
Моим предположением после нескольких минут размышления над этой строчкой было: вероятно, у файлов chmod -r стоит, и автор (наивно) надеется, что злоумышленник перед попыткой доступа сделает +r. Хотя в таком случае и код был бы немного другим — ловил OSError в целом.
А поясните, почему нельзя? Имеется ввиду разделение сущностей и создание реляций? Потому что если тикет представлять глазами как раз бухгалтера, то никаких реляций там нет и быть не может.
История разработки — это набор ключевых моментов, когда кто-то что-то затронул, в том числе во время работы над фичой.
Для истории выполненных задач у нас есть таск-трекеры, а в гите, будьте добры, подробности — дабы в случае необходимости вычленить конкретный небольшой коммит, затрагивающий только одну подсистему в рамках одной фичи (или нескольких — вот тут как раз не принципиально, что само является плюсом).
Хорошо это устроено в Linux (LKML), где целостные патчи, охватывающие разные подсистемы, попросту не принимают.
Я вам уже ответил ранее, что swappiness выставлять — решение без необходимости увеличения объёма swap-файла, а раз мы вольны его увеличивать, то этой манипуляции не требуется.
Основной тезис из начала вашей статьи:
Мы этот тезис уже опровергли два месяца назад.
К чему же вы продолжаете спорить?
У вас проблема в понимании. Не линукс использует своп, а вы. Это вам не винда, где система пользуется вами, а не вы ею. Своп должен быть задан такого объёма, который вы, своим использованием, не займёте в нормальных условиях — и под гибернацию место останется.
Также стоит отметить, что при гибернации по умолчанию RAM сжимается, а при неудачной гибернации система попытается отсечь наименее нужные данные, поэтому места может быть и меньше.
А в каком моменте я с этим утверждением спорил? Потрудитесь указать.
В чём нарушение? Ваш скрипт держит это пространство неиспользованным до начала гибернации, а штатное решение позволяет системе скинуть туда то, что не влезает в RAM при пиковой загруженности. Абсолютно все кейсы, где работает ваше решение, продолжают работать на штатном. Просто штатное, в духе линукса, дополнительно даёт бонусные возможности под вашу собственную ответственность: выдержать больше нагрузки ценой невозможности гибернации ДО СНИЖЕНИЯ этой нагрузки. А без свопа ваша система такую нагрузку попросту не выдержала бы, приведя к фризу/крашу. Риторический вопрос: что лучше?)
Писать статью об очевидном моменте использования — бред. Здесь не нужно никакой статьи, у большинства людей (включая меня) всё прекрасно работает из коробки, достаточно просто установить нужный объём swap.
Вероятно, имеется ввиду Credentials API или его аналоги.
Вероятно, под словом «движок» имеется ввиду существование оного на рынке, а не использование.
Так это же проблема вашего использования. Если своп будет занят, значит, вы выделили недостаточно свопа!
Но вам же всё равно приходится выделять отдельный файл для гибернации, помимо основного свопа. А без свопа в принципе нельзя.
Если бы хватало, не забивался бы своп. Вы ведь понимаете, что он чем-то занимается? Это что-то — ваше. Возможно, без свопа у вас просто не возникает таких нагрузок, иначе бы фризило и OOM'илось.
Так ваш скрипт же это и делает — держит его по умолчанию отключенным.
Я такого не утверждал. А утверждал следующее:
имея ввиду, что включенный своп принесёт бо́льшую пользу, чем отключенный.
Как, откуда? Вы же сами скинули скриншот, где из ваших 32 Гб перелилось ещё около 5 Гб в своп. Значит, в пиковой нагрузке у вас было занято точно больше 32 Гб, я взял следующее «круглое» для примера.
Я вам предложил решение параметром ядра, исходя из того, что вы не хотите резервировать больше места. Исходя из вашего нового тезиса, что место на диске не является ценностью, я теперь вам предлагаю решение, как оно задумано по дизайну: увеличить объём своп-файла/раздела.
Не кажется. Мне, как Linux-пользователю, кажется странным то, что вы так рьяно, как и я, отстаиваете свою точку зрения на костыльном решении, не пробуя рассмотреть штатно предусмотренные решения. А единственный я здесь в комментах потому, что подавляющему большинству осмысленных линуксоидов заголовок вашей статьи не был интересен в первую очередь.
Кто бы говорил :)
Наверное, потому что это дистрибутивы Linux?
Да, вижу проблему. Но я всё ещё не могу понять, какой смысл от гибернации с большим объёмом занятой памяти. Не вижу принципиальной разницы от отключенного по умолчанию свопа, потому что тогда вам банально не хватит оперативки, раз вы каким-то образом умудряетесь так её забивать.
Вы решаете костылями проблему, которую сами себе создали. Что лучше: иметь возможность уйти в гибернацию с 48 Гб занятой памяти, при этом фактически бесполезно отрезая данный объём от дискового пространства, или же иметь возможность выдержать с его помощью больший пик (вероятно, с вашим юзкейсом там могут выйти и все 64 Гб) вместо того, чтобы система постоянно уходила в OOM, и при этом НЕ терять возможности уйти в гибернацию с прежними 48 Гб? По-моему, ответ очевиден. Исходя из этого и дизайн.
Если вы так категоричны, то могли бы и выделить столько, сколько вам с лихвой понадобится на своп + гибернацию + ещё чутка про запас. Тоже «устранило» бы несуществующую проблему.
Далее просто процитирую ваши же слова, без комментариев:
Wat? Вы сравниваете установку софта с работой сервера, причём непонятно, имеете ли вы представление о разнице моментальных и временны́х единиц — объём оперативной памяти не может быть «за минуту» или «за месяц», это безвременная немонотонная единица.
Дело вам как раз должно быть — железо вы самостоятельно не усовершенствуете, а вот архитектуру — запросто. Повторяюсь, GNU/Linux и его компоненты опенсорсны.
Вы не единственный юзер, у которого любые проблемы с линуксом. Это нормально, как видите, и у всех разный уровень. Всё пройдёт с опытом.
Вот это и есть ваш камень преткновения. Дефолтные настройки дефолтного дистрибутива и не обязаны вам ничего более специфического, чем «включил—поработал—выключил», позволять.
Правильное решение уже содержится в системе (о чём я рассказываю выше), а ваше личное не следует позиционировать как правильное, не разобравшись в вопросе до конца.
Всё предложенное, кроме Вами упомянутого — аутентификация и… аутентификация (читайте: подписи и их проверка).
Стега тоже шифрованием не является (но может — и часто используется — в связке).
Моим предположением после нескольких минут размышления над этой строчкой было: вероятно, у файлов
chmod -rстоит, и автор (наивно) надеется, что злоумышленник перед попыткой доступа сделает+r. Хотя в таком случае и код был бы немного другим — ловилOSErrorв целом.Некрореплай на некрокоммент: NtopNG.
А всякие
TCP_NODELAY, «квик-квак» и пр. разве не спасают?Даёшь
NFQUEUE!А поясните, почему нельзя? Имеется ввиду разделение сущностей и создание реляций? Потому что если тикет представлять глазами как раз бухгалтера, то никаких реляций там нет и быть не может.
Как раз статья и говорит о том, что надо перестать так делать и начать д у м а т ь.
Ну, написано:
Так что всё-таки, получается, не обёртка.
Согласно документации, это прямой аналог
git stash.Будут удалены при чистке без учёта MRов, а вот в гитлабе это настраивается глобально или в параметрах репы, мол, MRы считать рефами и не трогать.
Сказать-то можно, а вот услышать вначале рассуждения или не услышать — это критерий.
Всё равно же, одна ветка — одна задача.
История разработки — это набор ключевых моментов, когда кто-то что-то затронул, в том числе во время работы над фичой.
Для истории выполненных задач у нас есть таск-трекеры, а в гите, будьте добры, подробности — дабы в случае необходимости вычленить конкретный небольшой коммит, затрагивающий только одну подсистему в рамках одной фичи (или нескольких — вот тут как раз не принципиально, что само является плюсом).
Хорошо это устроено в Linux (LKML), где целостные патчи, охватывающие разные подсистемы, попросту не принимают.