Лимиты на десктопе для предотвращения зависаний

Рекомендую thrash-protect. Он временно замораживает процессы, у которых резко растет потребление памяти. Только не злоупотребляй, а то начнет морозить все подряд и станет еще хуже.

Многие программы не потребляют предсказуемое количество памяти. В зависимости от входных данных и прочих внешних факторов могут мегабайт съесть, а могут и несколько гигов внезапно затребовать и тут же заполнить. Не ССЗБ не пользуются такими программами, что ли? А чем тогда вообще пользоваться, выкинуть компьютер и пользоваться калькулятором?

Я по этому поводу уже высказался.

Не хватает оперативы? Сходи в ближайший супермаркет, купи.

Так неизвестно заранее, сколько оперативы понадобится. Купить можно потом. Задача - предотвратить зависание, когда какая-нибудь программа внезапно затребует больше оперативы, чем есть, сколько бы ее ни было.

И кстати, нередко бывают случаи, когда докупать оперативку бессмысленно: просто в программе глюк, или сами входные данные кривые, и программа начинает потреблять бесконечное количество памяти.

Ну а в аренде, то как?

По этому поводу я тоже уже высказался.

Чтобы внезапно такого не случалось, возьми да лимитируй ей ресурсы, либо поставь общий лимит для всего, что запускаешь. Или же просто не включай своп, тогда ядерный киллер сам порешает без всяких юзерспейсных быдлоподелий.

Ты это говно на серверах пускать собираешься, сириосли?

Ядерный киллер может не ту программу прибить, это плохо. thrash-protect более мягкий, он даёт юзеру время посмотреть, в чем дело, и разрулить ситуацию вручную. Лимиты, опять-таки, предсказывать сложно; например, сегодня пользователю понадобилось 20 вкладок в хроме, а завтра 10 вкладок в хроме и какой-нибудь SQLdeveloper. Предлагаете иметь оперативки по сумме максимального объема памяти, который позволено потребить каждой установленной программе по отдельности, даже если они обычно вместе не запускаются?

Самый популярный (или второй, не помню) серверный дистрибутив - убунта, где твой мир? А ещё туда всякие ISPmanager, VestaCP и прочее дерьмо ставят, чтобы мышевозы могли «админить». Куда там маленькому скрипту на питоне по говнистости по сравнению с этим?

либо поставь общий лимит для всего, что запускаешь

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

Дислексия?

Или же просто не включай своп, тогда ядерный киллер сам порешает

Неправда, вешается система нахрен.

По моей практике вешается, но не намертво и не надолго.

Вообще, я наоборот юзаю своп. Но на быстрых SSD, так что если его не засрать целиком, система продолжит ворочаться. Впрочем, я на десктопе свопался раза два за всё время.

Везёт, у меня вешается перманентно, пока вручную по alt+sysrq+f oom не вызвать.

То на orange pie zero было, я ей кота распознавал. Нахерачил не приходя в сознание, лишь бы работало, ну оно и текло. Судя по логу, там при переполнении от десятков миллисекунд до нескольких секунд проходило до убийства сервиса.

Так в результате грохнется первая программа, которая попытается выделить память сверх лимита. Ничем не лучше OOM. У него хоть какой-то скоринг есть.

Система колом не встанет, что ещё нужно-то?

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

Нужно, чтобы софт внезапно не падал.

Вполне, если задачи и набор программ, либо данных, постоянно меняются. Даже банальная нагрузка на сервере: сегодня 8 ГБ оперативки хватило, завтра налетело по слешдот-эффекту посетителей и даже этого мало, но в норме такого не предвидится. Значит ли это, что надо держать кучу избыточной оперативки? Облака с гибким горизонтальным масштабированием не просто так появились.

Вот тут поподробнее. Что по-твоему должно произойти на сервере в этот момент? Интересен твой ход мысли.

Сервер должен выдержать нагрузку и обслужить хотя бы часть пользователей, а не встать раком совсем. Прибивание воркеров OOM-ом этому явно не способствует, поскольку будет прерывать загрузку у пользователей, направленных на этот воркер.

Ещё бывают случаи, когда сервер что-то длительное по запросу молотит. Может и впрямь долго молотить, а может зависнуть и отжирать бесполезными вычислениями процессор и память. Тут уже должен вмешаться админ и прибить руками.

Вообще, если это колхоз, то пофигу, пусть встаёт раком, лишь бы более-менее аккуратно помер и перезапустился. Но в идеале просто иметь load balancer, который не даст серверу прихереть с нагрузки. Если уже сам балансер не осилит, то можно просто делать отлуп.

Ну, ок. Я уж было подумал, ты и на сервере хочешь киллеров пускать.

На серверах ОПС делать.

Нет. Да и фейсбук напрямую этого не требует

Мне кажется, что дока по цгруппам от ядра имеет приоритет над записками фейсбука.

Вообще я сначала подумал, что дело может быть в том, что systemd может автоматически выставлять memory.min на всех родительских цгруппах. Но я проверил — это не так.

Можешь рассказать, как ты воспроизводишь нехватку памяти? Я поэкспериментирую.

дока по цгруппам от ядра

он как раз в ФБ и работает:

================
Control Group v2
================

:Date: October, 2015
:Author: Tejun Heo <tj@kernel.org>

Tejun has been working on the Linux kernel for over 15 years across various subsystems from device drivers to core infrastructures. Since 2011, he has been maintaining cgroup, the Linux kernel resource control subsystem, and, for the past five years, working on cgroup2 to solve the previous version's fundamental shortcomings. Tejun currently leads resource control efforts at Facebook.

- https://www.youtube.com/watch?v=LVU0W5yL30I

как ты воспроизводишь нехватку памяти?

`tail /dev/zero` простой пожиратель памяти

https://github.com/hakavlad/nohang-extra/blob/master/trash/i-memhog - более гибкоое решение

общий лимит для всего

Он есть по дефолту, называется MemTotal.

Только не злоупотребляй, а то начнет морозить все подряд и станет еще хуже.

У меня так и было - он морозил всё подряд. thrash-protect очень сырой, не имеет удобного конфига, нет инфы о тонкостях конфигурации. Но идея интересная - посылать SIGSTOP самому быстрорастущему вместо SIGKILL самому толстому. Возможно, это и есть правильное поведение при высоком давлении памяти - останавливать растущий процесс вместо убийства самого большого чтобы уменьшить давление памяти (PSI).

Окей. Потестил. Действительно не работает. Либо это какой-то адский баг (который никто не заметил, втф), либо мы что-то делаем не так.

Не, не такой:

решение с cgroups достаточно очевидное, следует вычесть из общего объёма оперативы 3-4гб под систему (чтобы с запасом, никакой «полной утилизации»), а всё остальное отдать группе в которой будут находиться запускаемые тобой приложения

юзерские программы сейчас всегда лежат в одной цгруппе с графическим сервером/WM/DE

у меня в deb 9 Xorg лежит в /system.slice/lightdm.service

Окей. Потестил

Какие тесты провел? Выставлял ли memory.min для родительской группы?

Он не работает.

Он не работает.

Процессы могут съесть больше, чем имеется MemTotal?

Могут завесить всю систему же, приходится оставлять запаc.

чтобы с запасом, никакой «полной утилизации»

Что плохого в полной утилизации?

Ничего, плох тот убогий говнокостыльный способ, которым ты предлагаешь её достигать.

Ядерный киллер может не ту программу прибить

В системд юнитах есть опция OOMScoreAdjust=

Какие тесты провел?

systemd-run tail /dev/zero :)

Выставлял ли memory.min для родительской группы?

Да, пробовал выставлять memory.min и memory.low по цепочке и без — ноль эмоций.

у меня в deb 9 Xorg лежит в /system.slice/lightdm.service

А юзерские программы в session-N.scope?

плох тот убогий говнокостыльный способ

Таки что в нем плохого? Эти костыли лечат сломанное ядро, и делают это хорошо.

А юзерские программы в session-N.scope?

Да, все остальное там - mate-session и дети.

Это означает, что у тебя X-сервер запущен от рута вне PAM-сессии. Это уже давно устаревшая конфигурация. На современных системах экземпляры X-сервера (и тем более Wayland-композиторы) запускаются от имени пользователя и естественным образом попадают в цгруппу сессии.

Это уже давно устаревшая конфигурация

Разумеется, это же Debian Oldstable.

Разумеется, это же Debian Oldstable.

Вот это «винегрет»: oldstable, но cgroup2.

Почему бы и нет? Через опцию загрузки включение сигруп2 поддерживается.

Почему бы и нет? Через опцию загрузки включение сигруп2 поддерживается.

И что дальше? Результат где?

у тебя X-сервер запущен от рута вне PAM-сессии. Это уже давно устаревшая конфигурация

На Ubuntu 19.04 то же самое: http://okturing.com/src/6967/body

Результат таков: могу использовать доступные только в cgroup2 лимиты, например MemorySwapMax.

MemorySwapMax=bytes

    Specify the absolute limit on swap usage of the executed processes in this unit.

    Takes a swap size in bytes. If the value is suffixed with K, M, G or T, the specified swap size is parsed as Kilobytes, Megabytes, Gigabytes, or Terabytes (with the base 1024), respectively. If assigned the special value "infinity", no swap limit is applied. This controls the "memory.swap.max" control group attribute. For details about this control group attribute, see cgroup-v2.txt.

    This setting is supported only if the unified control group hierarchy is used and disables MemoryLimit=.