Бастьен Ночера (Bastien Nocera) анонсировал (http://www.hadess.net/2019/08/low-memory-monitor-new-project...) новый обработчик нехватки памяти для рабочего стола GNOME - low-memory-monitor (https://gitlab.freedesktop.org/hadess/low-memory-monitor/). Демон оценивает нехватку памяти через /proc/pressure/memory и при превышении порога отправляет через DBus предложение процессам о необходимости умерить аппетиты. Также демон может пытаться сохранить отзывчивость системы через запись в /proc/sysrq-trigger.
В комбинации с проведённой в Fedora работой по применению zswap и прекращению использования дисковой подкачки, low-memory-monitor позволяет добиться повышения отзывчивости и качества работы на большинстве рабочих станций. Проект написан на языке C и поставляется (https://gitlab.freedesktop.org/hadess/low-memory-monitor/) под лицензией GPLv3. Для работы демона необходимо ядро Linux 5.2 или новее.
URL: https://www.reddit.com/r/linux/comments/ctyzhc/lowmemorymoni.../Новость: https://www.opennet.me/opennews/art.shtml?num=51354
Вот обновленное сравнение юзерспейсных киллеров:earlyoom: простой, лёгкий, стабильный. VmRSS меньше мегабайта, нагрузка на процессор околонулевая. С релиза 1.3 стал очень надежен (исправлено возможное убийство невиновных). Лучший выбор для домохозяек, которым не нужны лишние настройки, а нужна хорошая работа из коробки. Поддержка PSI обсуждается (https://github.com/rfjakob/earlyoom/issues/100 - автор давно собирался добавить поддержку PSI, но в последнее время засомневался в целесообразности этого. Проводятся работы по убеждению сенсея в необходимости добавления поддержки PSI). Оф Репа: https://github.com/rfjakob/earlyoom / Присутствует в репах Ubuntu 18.04+ и Debian 10+. Начиная с версии 1.3 могу смело рекомендовать его в качестве дефолтного киллера для десктопа. Буду лоббировать его в качестве дефолтного киллера для Федоры (zram они уже собрались включать по дефолту, для полного счястья не хватает earlyoom, обсуждение тут: https://pagure.io/fedora-workstation/issue/98 ).
nohang: явная и очень гибкая конфигурация. Десятки параметров настройки в конфиге. Подробная печать свойств завершаемого процесса. Печать таблицы процессов со свойствами всех процессов перед корректирующим действием. Возможность реакции на PSI (pressure stall information, https://lwn.net/Articles/759658/) с выбором произвольной метрики и сигруппы для мониторинга. Возможность кастомизации корректирующих действий: отправка жертве любого сигнала (помимо SIGTERM/SIGKILL) или выполнение произвольной команды. Возможность тонкого влияния на badness процесса путем сопоставления его name, cmdline, cgroup, exe realpath c заданным регулярным выражением. Уведомления о низком уровне памяти (произвольной командой или через notify-send). Минусы: мало документации. Хочу релизнуться, но лень писать документацию. Можно рекомендовать тем, кому не хватает возможностей earlyoom (у последнего нет поддержки PSI и уведомлений о нехватке памяти).
oomd: работает только с сигруппами - минимальным объектом для корректирующего действия является сигруппа. Это означает, что при применении на десктопе oomd убъет всю сессию посредством SIGKILL. В связи с этим рекомендуется только для крупных высоконагруженных серверов. Плюс требования: работает только с systemd, cgroup2 должна быть единственной иерархией, иерархия cgroup_v1 должна быть отключена + требуется ядро с поддержкой PSI + своп должен быть включен (без свопа oomd бесполезен). Плюс oomd заметно грузит проц - нагрузка в 4.5% в порядке вещей (We see this internally too. Something like 4.5% of a core all the time. - https://github.com/facebookincubator/oomd/issues/79#issuecom...). Модульная архитектура во все поля, но издержки описаны выше.
low-memory-monitor: рано делать выводы. Идея просить процессы умерить аппетиты самостоятельно вызывает скепсис. В остальном этот киллер примитивен и не содержит других киллер-фич.
Итог таков: Если у тебя CentOS 6, или слабое железо, или не нужно ничего лишнего, или хочешь «быстро поставил и забыл» - ставь earlyoom. Nohang имеет дополнительные фичи, полезные как для десктопа, так и для сервера. oomd не трогай, если ты сам не из Фейсбука.
> отправляет через DBus предложение процессам о необходимости умерить аппетитыДо сегодняшнего дня, соответственно, приложениям неоткуда была узнавать о том, что память заканчивается.
>отправляет через DBus предложение процессам о необходимости умерить аппетитыС трудом верится, что процессы не будут игнорировать эти сигналы. Скорее всего почти все проги будут забивать кек на этот сигнал.
>> отправляет через DBus предложение процессам о необходимости умерить аппетиты
> С трудом верится, что процессы не будут игнорировать эти сигналы. Скорее всего почти все проги будут забивать кек на этот сигнал.интересно, а точно ли процессы должны слушать этот DBus а не сами лезть в /proc/pressure/memory ?
какой толк от Демона если это всего-лишь посто прослойка?
Универсализм настройки. Так каждому приложению надо изобретать тот порог по которому умерять аппетит.
а нельзя так придумать чтобы работало без кручения руками настроек?
> какой толк от Демона если это всего-лишь посто прослойка?Эта прослойка работает через универсальный интерфейс взаимодействия с внешней средой. Не поллинг файликов: поллинг файликов в главном цикле где хочется ограничить latency (скажем, чтобы гуй не залипал) -- это самоубийство. Тут правда псевдофс, она по идее не должна блокировать файловые операции, но я не знаю в точности, даёт ли ядро такие гарантии, и даже выяснять не хочу: при наличии оповещений по dbus, я предпочту их.
> Эта прослойка работает через универсальный интерфейс взаимодействия с внешней средойЭто откуда у гномеров руки растут?
>> Эта прослойка работает через универсальный интерфейс взаимодействия с внешней средой
> Это откуда у гномеров руки растут?Это через dbus. Если место роста рук у других не позволяет им использовать dbus, то тогда да, можно указать в качестве причины место роста рук.
Главное чтобы сам DBus дожил до нужного момента и ему не прислали чёрную метку.
А чё не Earlyoom? Нормальная же штука. Или это типичный GNOME-way?
>Или это типичный GNOME-way?This. Это поделка уровня earlyoom 0.1, c той лишь разницей, что детекцию проводит через /proc/pressure/memory вместо /proc/meminfo.
> Или это типичный GNOME-way?Очевидно же, что если убить текущую (в очередной раз) Гномо-Щель:
https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem.../
> Well, as stated in the comment, GJS’ garbage collect was indeed collecting memory when triggered. Problem is, it wasn’t being triggered at all.https://gitlab.gnome.org/GNOME/gnome-shell/issues/64
> On Ubuntu 17.10, gnome-shell starts the day on 569.9MiB for me, and ends around 2GB. It got up to 5GB over two days. Now I shutdown every night.Убъется весь сеанс пользователя ;)
Но ведь этот баг исправили давно!
> Но ведь этот баг исправили давно!Это у них традиционное:
https://bugzilla.gnome.org/show_bug.cgi?id=777537
> Gnome 3.22.2 + GDM 3.22.1 : Memory leaks
> 2017-01-20https://bugzilla.gnome.org/show_bug.cgi?id=789634
> 2017-10-29https://gitlab.gnome.org/GNOME/gnome-shell/issues/64
> #64 · opened 1 year agohttps://gitlab.gnome.org/GNOME/gnome-shell/issues/653
> #653 · opened 10 months agohttps://gitlab.gnome.org/GNOME/gnome-shell/issues/1359
> #1359 · opened 2 months ago
Это ж не баг, а оснопологающая фича Вяленного.
>В комбинации с проведённой в Fedora работой по применению zswapNo.
Installing and enabling zram by default (already merged):
https://bugzilla.redhat.com/show_bug.cgi?id=1731598
https://pagure.io/fedora-comps/pull-request/391Disabling disk-based swap by default:
https://bugzilla.redhat.com/show_bug.cgi?id=1731978- https://pagure.io/fedora-workstation/issue/98 - Федора переходит на zram, а не zswap. Это можно, кстати, в отдельную новость выделить.
В этой новости прекрасно всё.
опять на си, он не помогает в написании корректных программ
А у раста бинарники слишком жирные и его еще никто не выучил.
Причем тут размеры бинарников раста? Посмотри сколько рамы на твоем десктопе занимают Gnome Software + PackageKitD.
Все и так плохо, давай ещё и раста подкинем, чтобы совсем адъ?
в earlyoom утечек нет, хоть он и на си - стабильно 1 МБ потребляет
> опять на си, он не помогает в написании корректных программНи один язык не помогает. Как показывает практика, люди, которые на си не могут память освободить вовремя, на яве не могут вовремя закрыть соединение с базой или остановить опрос какого-нибудь BLE в андроиде. Люди, которые в си не проверяют, что введённое пользователем значение попадает в нужный диапазон, не будут делать этого и на питоне.
А от того, что вместо UB вы получаете стектрейс, программа корректной не становится.
Однако в отличие от многих других, си помогает в написании БЫСТРЫХ программ.
Хорошее собрание типично юниксовых заблуждений времен расцвета.
А в чём конкретно заблуждение?
в том, что до сих пор кто-то ведется на такую жырноту
Насчёт того, что си быстрее можно долго и бесполезно спорить, ибо цель у языка только в скармливании компилятору, от которого больше зависит. А вот то, что си максимально примитивен в плане абстрагирования от того, что происходит в машине - это факт, который кому то в плюс, а кому то в минус.
Это если машина - PDP-11. Если же обсуждать то как работает что-то посовременнее, то кто там дальше от execution units, cache line bouncing или например wear leveling, Си, Haskell, или brainfuck - вопрос дискуссионный.
> Это если машина - PDP-11. Если же обсуждать то как работает что-то
> посовременнее, то кто там дальше от execution units, cache line bouncing
> или например wear leveling, Си, Haskell, или brainfuck - вопрос дискуссионный.Не обязательно валить все известные buzzwords в кучу, достаточно посмотреть реализацию vfprintf в musl -- она строго 32-х разрядная.
Надеюсь еще и вручную оптимизированная под конкретный размер кэшей конкретной линейки CPU конкретного производителя, с ассемблерными вставками, профайлингом доведенными до совершенства скорости работы на конкретном поколении конкретной линейки CPU конкретного производителя.
> Надеюсь еще и вручную оптимизированная под конкретный размер кэшей конкретной линейки CPU
> конкретного производителя, с ассемблерными вставками, профайлингом доведенными до совершенства
> скорости работы на конкретном поколении конкретной линейки CPU конкретного производителя.Ведь я указал, какой конкретно файл можно посмотреть, без лишних поисков. Но, похоже, сделал недостаточный для знатока ассоциативности кешей акцент на разрядности. Так вот, преимущества 64-х битной арифметики не используются. То есть не очень-то упомянутая функция на С и "кроссплатформенная".
> Ни один язык не помогаетНу почему же, пресловутый раст помогает, например. Программа просто не скомпилится, а компилятор ещё и покажет как надо написать.
-Wall -Werror
И половина ошибок не отловится.
Даже -Wextra -Wpedantic. Только вынесут мозг наркоманией с приведениями численных типов одного к другому там, где это совершенно не требуется просто потому, что так в свое время сделали не подумав, а потом так же и стандартизировали.
Не говоря о том, что ошибки компиляторов (GCC, clang) совершенно невнятные, а иногда и неочевидные. А про плюсы, где все описанные еще раз в 100 более сломано даже речи не было.
Как известно, неприятные ошибки состоят по большей части из опечаток, off-by-one error, и cache invalidation. Это чисто технические, еще большая часть ошибок логические. Как именно компилятор Rust помогает с каждым из этих типов ошибок?
Что-то твой всраст не помог огнелису стать нормальным браузером. Хром, на проклятых плюсах, все так и дает ему по морде.
Не защищая Rust, пример-то так себе. Вложив того и столько, чего и сколько в Chrome вложил Гугл, его можно было бы сделать точно таким же (во всяком случае не хуже) на любом языке, включая COBOL и РАПИРА, или совсем без оного - прямо в машинном коде, редактируя бинарник в ed.
Как же хорошо, что в винде нет таких проблем.
Но как плохо, что в винде проблем гораздо хуже полно)))
Бяда с ентой вендой. То DKMS поломают, то в OOM-Killer завозят патчи, беспричинно убивающие всё подряд, то CVE-2012-0056. В линуксе такой фигни нет.
Вы чуть перепутали названия, но в целом верно согласен.
В линуксе полно другой фигни
почему хорошо? было бы хорошо если бы мы её использовали
Правильно, местные зонды сами знают, как занять всю доступную память
В винде Memory Compression работает всегда, не важно сколько рамы 8 или 64 ГБ. Если нет возможности найти физически свободных адресов, произойдет одно из двух: 1. Закроется самая тяжелая программа. 2. Нарисуется окно с предложением закрыть эту самую тяжелую программу.
вот как?
а в линухе compression — это сжатие, а не освобождение.
ну типа zip. или для вас rar
ARJ
>В винде Memory Compression работает всегдаЭто означает ее низкую гибкость и невозможность отключения свопа. В линуксах zram/zswap давно доступны по желанию и гибко настраиваемы. Кому надо - ставят.
Оно не доступно при выключенном pagefile, и не нужно ничего "гибко" настраивать. Поставил ОС - работает и вместе с гибернацией из коробки всегда.
> Как же хорошо, что в винде нет таких проблемс чего ты взял?
сварить то вообще можешь в вантузе отключить?
Вы забываете, что в некоторых других дистрах такой фигни тоже нет, всё зависит от понимания дистрибьютера того, какую хрень он творит. И в дистрах на линуксе полное раздолье (хотя и не предел мечтаний), а в винде у вас только один дистрибьютер.
Со старта 1,5 Гб при сжатии - да, нет проблем, уже зарезервировали.
Сперва они пишут приложухи, которые жрут память, а потом они пишут еще одну приложуху, которая говорит остальным приложухам сколько им можно жрать памяти, которая тоже жрет память; а потом они напишут еще...Прям сказка про белого гнома какая то.
Сперва они прекращают возвращать NULL из malloc, а потом уже пишут приложухи, которые жрут память и т. д.
Больше велосипедов богу велосипедов!
Какая разница будет сожрана память в ядре или в userspace-е? Что действительно важно, это то, что "ещё одна приложуха" жрёт память статически (и реально мало, к тому же), а не динамически.
> On Ubuntu 17.10, gnome-shell starts the day on 569.9MiB for me, and ends around 2GB. It got up to 5GB over two days.
> Now I shutdown every night"Я выключаю компьютер каждую ночь, я успешен, я свободный от задродство человек!" или тому подобное.
Окстись, гонм юзают только хомячки.
kde plasma держу планшет неделями в слипе.
И не вывожу из него
я тоже, причём как раз 17.10 )
Requires Linux 5.2 or newer and GLib.
Беполезный мусор для хипстеров. Даже поддержки последнего lts нет. Считай, все дистрибутивы кроме ролинг релизов в пролете. Да и я не знаю кем надо быть чтоб ставить 5.2.9 на свой комп. Там же может быть любая хрень вплоть до поломок фс.
Он еще только анонсирован, релизов не было. Через пару лет окрепнет, и дистры к нему будут готовы, даже Дебиан Стейбл.
> Беполезный мусор для хипстеров.
>> для GNOMEКеп?
А толку то делать эту новую штуку под старые ядра?
Та же Ubuntu 18.04 LTS сейчас идёт с ядром 5.0.
Эта штука новая будет до более вменяемое состояния написана этак через полгода.
Так что проблемы то нет.
//offtop
> обработчик нехватки памяти для рабочего стола GNOMEэто что, официальное признание гномеров что гном жрёт больше всех, а другим такого не надо?
>а другим такого не надо?А другие давно используют earlyoom, и только гномеры завезли себе персональную, только с гномом совместимую, кривую поделку.
Что бы делать, лишь бы ядро не фиксить. Потому что все эти демоны-кильеры не решают проблемы того, что на винде программы прекрасно работают, а на линуксе либо ты выключаешь оверкоммит и проги крэшатся и не стартуют, либо ты включаешь оверкоммит и у тебя всё виснет, либо ты ставишь эти демоны и они убивают программы.Во всех случаях работать невозможно, и тем, кому работать нужно, приходится использовать Windows 7/8/10, все с телеметрией (для 7 телеметрию встроили в security-only обновление, даже те, кто готов нехило заплатить за отсутствие телеметрии не имеют этой возможности).
Зачем фиксить ядро, если можно просто памяти накупить и вставить. Тех, кому неприемлимо постоянно комп всяким гoвнoм апгрейдить, наверное, за унтерменшей считают.
>ты выключаешь оверкоммитЕсли мозгов нет
>Что бы делать, лишь бы ядро не фиксить.
В ядре есть ООМК. Ядро не надо фиксить.
>эти демоны-кильеры не решают проблемы
Демоны-киллеры полностью решают проблемы.
>ядро, если можно просто памяти накупить и вставить
Ядро не может заменить оперативу. Тюнинг vm и вкл свопа - это не рагает проблему малого обема ОЗУ. Одкако юзерспейсные киллеры решают проблему дедлоков при нехватке памяти.
>либо ты включаешь оверкоммит и у тебя всё виснет
Напротив, разрешение оверкоммита в сочетании с юзерспейсными киллерами позволяет полностью утилизировать память, обходяь при этом без зависаний.
Толсто.Без оверкоммита ни единого тормоза до резета с остервенелым шуршанием винтом. Просто программы крешатся и перестают стартовать, особенно из GUI (видимо в кедах какой-то говнокод в меню, потому что из консоли те же самые GUI Qt5 программы обычно стартуют нормально).
С оверкоммитом и без юзерспейсного оом-киллера зависание насмерть с износом жёсткого диска и перезагрузкой по резету. ИМХО - первый вариант гораздо предпочтительнее.
С юзерспейсным ООМ-киллером происходит следующее: оом-киллер прибивает вкладку, а Firefox её перезапускает, оом-киллер опять её прибивает.
Причём на винде всё прекрасно работает. На другой машине, с в разы меньшей оперативой.
Так что не надо нам лапшу на уши вешать. Сами бы поработали с 8 гигами, а лучше с двумя, и под виндой и под линуксом, тогда может желание хамить бы и пропало.
>Просто программы крешатся и перестают стартоватьВот именно, причем могут падать массово, зачастую рандомные и невиновные, пруф: https://imgur.com/a/p9j67KA
В случае с юзерспейсным киллером падает только один жирный процесс, и падает мягко, по SIGTERM.
>желание хамить
Я лишь исправил ваши ложные утверждения.
>В случае с юзерспейсным киллером падает только один жирный процесс, и падает мягко, по SIGTERM.Причём тоже невиновный. В общем, метод действия у меня такой:
1. отключается оверкоммит
2. в случае, если приложения перестают стартовать, вручную прибивается шланг.
> для 7 телеметрию встроили в security-only обновление, даже те, кто готов нехило заплатить за отсутствие телеметрии не имеют этой возможностиСоберите себе дистр без этих конкретных обновлений - и запретите обновляться вообще.
И не пускайте в интернет: критические обновления безопасности идут в комплекте с телеметрией. Единственный правильное действие тут - это не использовать винду и прочие проприетарные поделия вроде Intel ME и ARM TrustZone. Даже если это будет значить отказ от компьютеров и технологий вообще и переезд в пещеру. Действие единственно правильное, но совсем неабекватное.Адекватные предложения будут (кроме "надо забить на эту чепуху, больше зарабатывать, больше тратить, терпеть зонды, строем идти в неизбежное будущее, распевая гимн Единой России", я не настолько адекватный, чтобы принять эту простую стратегию, решающую все проблемы)?
Ты гонщик, когда винда начинается свопаться, все висит настолько глухо, что даже диспетчер задач вызывается десяток минут
Винда на свопе начинает тупить, в линуксе при свопе даже мышка по экрану не ездит.
Да фиг с ней с мышкой, magic-sysrq не работает и виртуальные консоли не переключаются.
Подождав несколько минут я сделал ребут и... потерял часть функционала KDE
А нельзя тупо выделиь кусок памяти под ОС, чтобы никакое приложение не могло на него претендовать. Тогда можно будет хотя без проблем бы прибить зажравшееся приложение
можно выделить, кто ж мешает.memory.min в сигруппах (на самом деле это не работает, по крайней мере в моих опытах)
Интересный вопрос. Кажись как-то можно прибить некоторые вещи гвоздями в памяти, но я так и не вкурил как...
vm.min_free_kbytes = 393216
>vm.min_free_kbytes = 393216Это катастрофически много, к тому же бессмысленно. На компах с малым размером памяти это может вообще положить систему.
>>vm.min_free_kbytes = 393216
> Это катастрофически много, к тому же бессмысленно.The problem has gone away completely for me after I bumped vm.min_free_kbytes way up to 393216.
https://bugzilla.kernel.org/show_bug.cgi?id=196729#c17
> На компах с малым размером
> памяти это может вообще положить систему.Скажу больше: на калькуляторе вообще не запустится.
Не прошло и 28 лет как в линаксе начали появляться базовые вещи...
Какие, например?
Во времена Гнома 2 своп работал нормально
Надо для Электрона такой. :)
Это чтобы поделия на нем вообще не запускались?
Для Электрона нужен перманентный киллер.
>отправляет через DBus предложение процессам о необходимости умерить аппетиты.-SIGCHROME?
> при превышении порога отправляет через DBus предложение процессам о необходимости умерить аппетиты"Окей", -- говорит dbus и падает первым. "Субботник - это когда люди, которые никогда не мусорят, убирает за теми кто никогда не убирает"
Сам подход порочен. Это сообщение должно или отправляться юзеру, чтоб принял меры, или самостоятельно прибить зажравшееся (для чего уже есть софт типа earlyoom).
Зачем прибивать? Просто заблочить на операции выделения памяти, пока не освободится нужное количество. А пользователь пусть сам выбирает какое из "замороженных" приложений прибить.
>заблочить на операции выделения памятиОбычно это приводит к MemoryError и непредсказуемому поведению https://imgur.com/a/p9j67KA
SIGTERM обычно обрабатывается корректнее, чем ошибка выделения памяти.
Если блокировка потока на выделении памяти приводить к непредсказуемому поведению, очевидно приложение написано криво. Логичным выводим из того, что new застопорился, должно быть понимание, что выделить память по какой-то причине не получается.
В любом случае автоматически прибивать - это самая крайняя мера. Её надо всеми возможными способами избегать.
>dbus и падает первымdbus обычно защищено низким значением oom_score_adj
>Это сообщение должно или отправляться юзеру, чтоб принял меры, или самостоятельно прибить зажравшееся
И то и другое есть в nohang. В earlyoom нет уведомлений о низком уровне памяти.