Юзерспейсные обработчики могут мягко обрабатывать ситуации с нехваткой памяти

Может уже следует пропихивать в дистрибутивы или системд, а не спамить на лоре?

Уже пропихиваем, все идет по плану.

Может уже следует пропихивать в дистрибутивы или системд, а не спамить на лоре?

https://fedoraproject.org/wiki/Changes/EnableEarlyoom вот пропозал, будем наблюдать.

Ещё бы поработали над тем чтобы важные юзерспейсные и не очень библиотеки/рантаймы не вытеснялись в своп.

Ну это технически легко: cgroup2 позволяет запрещать своппинг для процессов группы. Как это реализовать? Консенсуса нет.

https://github.com/hakavlad/nohang

богомерзкий питон, даже смотреть не буду, сразу виден уровень автора

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

Ещё бы поработали над тем чтобы важные юзерспейсные и не очень библиотеки/рантаймы не вытеснялись в своп.

prelockd is a daemon that locks mmapped binaries and libraries in memory and prevents code eviction from memory.

https://github.com/hakavlad/prelockd

Демо прилагается.

Ещё бы поработали над тем чтобы важные юзерспейсные и не очень библиотеки/рантаймы не вытеснялись в своп.

Еще вариант:

https://gitlab.freedesktop.org/benzea/uresourced/

https://pagure.io/fedora-workstation/issue/154

https://www.spinics.net/lists/fedora-package-review/msg543820.html

https://fedoraproject.org/wiki/Changes/Reserve_resources_for_active_user_WS

https://pagure.io/fesco/issue/2457 - это будет в F33.

Круто!

Хаха, похоже все твои сишники повымирали :D

Если написано нормально, с ловлей эксшепшенов, то пофиг что питон. Лишь бы действительно вовремя прибивало «наглецов».

https://youtu.be/G0FYDIKVPYI

А где своп? Или это решение для no swap case? Мне б вариант для свопа.

А где своп? Или это решение для no swap case? Мне б вариант для свопа.

https://youtu.be/PLVWgNrVNlc - демо со свопом

написано нормально, с ловлей эксшепшенов

Все так. Демон работает без падений и достаточно быстро.

Вот еще со стрессом в 8 потоков:

https://youtu.be/veY606v57Hk

Это все популизм какой-то. Без чтения моих мыслей ни ядро ни юзерспейс не знают что мне на самом деле надо.

Я читал твои мысли, и видел, что тебе нужен отзывчивый десктоп при нехватке памяти. Где тут популизм?

При нехватке памяти мне нужен не отзывчивый, а хоть какой-нибудь десктоп, и если эта скотина прибьет софтину, которая мне нужна и позволит лисе с хромым бессмысленно жиреть дальше, я буду очень расстроен :/ лучше бы нашли как сказать хромому с лисой «горшочек, не вари!» чем придумывать ненужные эвристики.

если эта скотина прибьет софтину, которая мне нужна и позволит лисе с хромым бессмысленно жиреть дальше, я буду очень расстроен

Софтину, которая тебе нужна, прибьет ядерный киллер.

А юзерспейсные киллеры позволяют гибко регулировать выбор жертвы. Например, можно защищать важные процессы путем понижения badness для процессов с определенным именем или exe realpath.

Например, защитить от убийства процессы VB (через конфиг nohang):

@BADNESS_ADJ_RE_REALPATH  -500 /// ^/usr/lib/virtualbox

Или предпочитать убийство дочерних процессов firefox:

@BADNESS_ADJ_RE_NAME 200 /// ^Web Content$

Предпочтение убийства вкладок лисы как раз включено в nohang-desktop из коробки.

как сказать хромому с лисой «горшочек, не вари!»

$ systemd-run --user -p MemoryMax=1G -p MemorySwapMax=0 firefox

– при этом в ограничиваемой контрольной группе сработает OOM killer при исчерпании лимитов. см https://github.com/hakavlad/nohang/issues/99

А можно реализовать режим или команду которая prevents code eviction для всез запущенных процессов.
Или некий белый список.
Чтобы при перезагрузке система не гадала (чтобы железные гарантии были, что DE/иксы не выгрузится)?

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

Вопрос в догонку, рядом с хромиумом будет blender ещё,или либра с книгой написанной за ночь без сохранения, кто умрёт первым?

Тот, кто додумался отключить в либре автосохранение.

В смысле отключить?

Последний раз (и наверно единственный), когда я воспользовался восстановлением документа в LibreOffice после внештатного прерывания, оно мне файл нулевого размера сделало.

А можно реализовать режим или команду которая prevents code eviction для всез запущенных процессов

Чтобы при перезагрузке система не гадала (чтобы железные гарантии были, что DE/иксы не выгрузится)

Легко. Устанавливаешь prelockd, запускаешь. По умолчанию блокируются в памяти все маппленные файлы, соответствующие регулярке ^(/bin/|/sbin/|/usr/|/opt/|/lib) - ее можно поправить через конфиг. Блокируются файлы размером не более 10M (немногие файлы превышают этот размер), и не более 5% MemTotal. Лимиты могут быть расширены через конфиг.

По умолчанию также блокируются в памяти файлы, сохраненные в виде списка в /var/lib/prelockd/saved_snapshot. По умолчанию список пуст. Для сохранения слепка текущих маппленных файлов нужно выполнить sudo prelockd -w.

Если установить в конфиге $LOCK_SAVED_MAPPED=True и $LOCK_CURRENT_MAPPED=False, то блокироваться в памяти будут только файлы из сохраненного списка. Минус: при обновлениях возможно изменение путей к файлам, и список сохраненных файлов периодически лучше обновлять. Для дебиан проблема неактуальна, ибо стабильность.

Рекомендуемый способ употребления: на голой системе с запустившимся гуем, но без запущенных приложений, выполнить сохранение слепка. При последующих запусках демона сохраненный список будет блокироваться в памяти. Пример вывода команды sudo prelockd -w: http://okturing.com/src/9150/body

На моем Debian Mate для блокировки гуя требуется 220M памяти. C LXDE достаточно 80M. Для гнома - 500M.

config: https://github.com/hakavlad/prelockd/blob/master/prelockd.conf

$DEBUG = True позволяет отследить всё происходящее при запуске демона.

за то что питон жирный минус

На самом деле проблема не велика. Ест стабильно 10-12м памяти, энергопотребление 0.01-0.1% в зависимости от состояния памяти и настроек. Скорости работы вполне достаточно для беспроблемной работы.

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

Тот, у кого наибольший oom_score. При прочих равный первым умрет хром - его процессы имеют повышенный oom_score_adj из коробки:

$ oom-sort -l0
oom_score oom_score_adj  UID   PID Name            VmRSS   VmSwap
--------- ------------- ---- ----- --------------- ------- --------
      309           300 1000 14330 chromium           95 M      0 M 
      307           300 1000 14334 chromium           74 M      0 M 
      304           300 1000 14357 chromium           44 M      0 M 
      211           200 1000 14276 chromium          110 M      0 M 
      201           200 1000 14296 chromium           15 M      0 M 
       68             0 1000 11650 firefox-esr       670 M      0 M 
       49             0 1000 12597 Web Content       484 M      0 M 
       31             0 1000 12543 Web Content       307 M      0 M 
       25             0 1000 12467 Web Content       244 M      0 M 
       18             0 1000 11843 WebExtensions     181 M      0 M 
       18             0 1000 11892 Web Content       182 M      0 M 
       18             0 1000 12675 Web Content       181 M      0 M 
       16             0 1000 11745 Web Content       163 M      0 M 
       16             0 1000 12410 Web Content       164 M      0 M 
       16             0 1000 14171 soffice.bin       165 M      0 M 
       15             0 1000 13689 Web Content       151 M      0 M 
       14             0 1000 14235 chromium          136 M      0 M 
        8             0    0   340 systemd-journal    90 M      0 M 
        8             0    0   948 Xorg               88 M      0 M 
        5             0 1000 14238 chromium           50 M      0 M 

Белые списки задавать можно?

Можно задавать прибавление или вычитание произвольных значений из badness процессов, если их свойства (name, uid, cgroup, exe realpath etc.) соответствуют заданным регуляркам - весьма гибкое решение.

на полудохлых ноутах с медленным хардом в котором уход в своп равнозначен зависанию

Со zram зависания нет при своппинге. Вот, у бати ноут 1.7 гиг памяти, своп на zram, своппинг происходит без проблем, см Десктоп бати-пенсионера: Linux Mint 18.3 Mate и https://imgur.com/a/dGPCVJd

Уточню, что у меня достаточно ОЗУ (16 и 32 гб на разных машинах).
Могу хоть по 4 ГБ на все важные бибилиотеки/бинари выделить, главное чтобы ничего не выгружалось и не подвешивало систему (взаимодействие с пользователем).

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

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

1. Поправить настройки prelockd: расширить лимиты на долю заблоченного ($MAX_SELF_RSS_PERCENT, $MAX_SELF_RSS_MIB - можно оба значения поднять, ибо VmRSS процесса prelockd будет ограничего меньшим из этих значений) и на макс размер файла $MAX_FILE_SIZE_MIB (бинари браузеров весят больше сотни метров).
2. Запустить нужные приложнения для создания слепка, напр терминалы, файлменеджеры, браузеры (обычно крупнейшие бинари у браузеров, остальные процессы именют маленькие размеры).
3. сохранить слепок: sudo prelockd -w.
4. PROFIT!

Это может приводить в том числе к ускорению запуска приложений, ибо бинари будут замапплены и заблокированы. Однако это приводит к уменьшению доступной памяти, ибо память будет занята отображенными файлами. Поэтому, вероятно, блокировать лучше только то, что реально постоянно запущено.

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

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

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

Ну так кто ж мешает. Инструкция дана. sudo prelockd -w, через дебаг опцию можно отслеживать что блокируется при старте демона.

А есть отдельные команды для листинга закреплённых в памяти и для заполнения памяти (стресс)?

Для листинга пока не завезли. Пока только можно смотреть процесс закрепления при старте демона.

Простейший стресс: tail /dev/zero.

Можно и так: stress -m 8 --vm-bytes 32G - 32G может не влезть в память, тогда брать значение меньше, или разрешить неограниченный overcommit (overcommit=1).

Есть i-memhog - интерактивный пожиратель памяти - можно запускать прямо из репы: зайти сюда https://github.com/hakavlad/nohang-extra и выполнить ./i-memhog - можно задавать сколько гиг сожрать, скорость пожирания, энтропию (в каких пропорциях смешивать одинаковые байты и urandom - для тестов zram при разных степенях сжатия) - это старый инструмент.

Здесь https://github.com/hakavlad/nohang-extra же лежит hanger - пожирает память и балансирует около нуля доступной и свопа - без prelockd вероятно зависание, с prelockd обычно не зависает, часто вовремя прходит ядерный киллер.

WARNING: при применении prelockd при стрессах, при полном исчерпании памяти иногда падали иксы. Сохраняйте несохраненное перед стрессами. Как это предотвратить? Применением nohang или earlyoom - чтоб не происходило полное исчерпание памяти, тогда проблем нет.

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

только nohang затестил?

пощупал все, до чего ручки дотянулись. nohang, oom-sort, psi-top, psi2lo. глубока не вникал, некогда. если есть какой-нибудь тест план могу вечерком исполнить.

Легко. Устанавливаешь prelockd

А вот это - годно!

Попробовал на Kubuntu. Без каких-либо юзерспейсных киллеров.

Запустил два раза tail /dev/zero. Загадило 12 гигов оперативки и 30 гигов свопа. Камень (два ядра по два потока) при этом был занят чуть менее, чем полностью. Гуй тормозил аццки, но при этом не мерз и на тычки реагировал. Пришел OOM и прибил один tail. Второй tail дозанял освободившееся и тоже был прибит. Всё прочее живо, с него сейчас и пишу. Однако, 830 метров чего-то в свопе осталось.

Кстати, во FreeBSD tail /dev/zero не вешает так жестко систему, как в Linux.

Запустил параллельно 40 штук. Комп неюзабелен, пока они не помрут, но и не виснет наглухо.

Ещё бы поработали над тем чтобы важные юзерспейсные и не очень библиотеки/рантаймы не вытеснялись в своп.

Да вот же ядро с патчем для этого Убунтята, не проходите мимо: le9 patch добавлен в linux-xanmod и ваш OOM killer будет вылечен

библиотеки/рантаймы не вытеснялись в своп

Кэш файлов разделяемых библиотек не вытесняется в своп - кэш просто удаляется из памяти, ибо может быть снова восстановлен из диска.