LINUX.ORG.RU

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

 ,


5

4

Летом был тред о неспособности ядра обрабатывать нехватку памяти: Линукс ядро не может мягко обрабатывать ситуации с нехваткой памяти

Пришло время продемонстрировать элегантное решение: https://youtu.be/G0FYDIKVPYI

Проблема: https://lkml.org/lkml/2019/8/4/15.

Решение: https://github.com/hakavlad/nohang.

Обсуждение в r/linux: https://www.reddit.com/r/linux/comments/ee6szk/killing_the_elephant_in_the_room_the_userspace/.

Ответ на: комментарий от Exmor_RS

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

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

https://github.com/hakavlad/prelockd

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

anonymous ()
Ответ на: комментарий от Exmor_RS

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

Еще вариант:

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.

anonymous ()
Ответ на: комментарий от anonymous

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

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

RedEyedMan666 ()
Последнее исправление: RedEyedMan666 (всего исправлений: 2)
Ответ на: комментарий от RedEyedMan666

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

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

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

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

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

https://youtu.be/veY606v57Hk

hakavlad ()
Ответ на: комментарий от hakavlad

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

slapin ★★★★★ ()
Ответ на: комментарий от slapin

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

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

А юзерспейсные киллеры позволяют гибко регулировать выбор жертвы. Например, можно защищать важные процессы путем понижения 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

hakavlad ()
Ответ на: комментарий от anonymous

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

Exmor_RS ★★ ()

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

LINUX-ORG-RU ★★ ()
Ответ на: комментарий от LINUX-ORG-RU

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

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

t184256 ★★★★★ ()
Ответ на: комментарий от t184256

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

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

fornlr ★★★★★ ()
Ответ на: комментарий от Exmor_RS

А можно реализовать режим или команду которая 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 позволяет отследить всё происходящее при запуске демона.

hakavlad ()
Последнее исправление: hakavlad (всего исправлений: 2)
Ответ на: комментарий от LINUX-ORG-RU

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

На самом деле проблема не велика. Ест стабильно 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.) соответствуют заданным регуляркам - весьма гибкое решение.

hakavlad ()
Ответ на: комментарий от LINUX-ORG-RU

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

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

hakavlad ()
Ответ на: комментарий от hakavlad

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

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

Exmor_RS ★★ ()
Ответ на: комментарий от Exmor_RS

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

Exmor_RS ★★ ()
Ответ на: комментарий от Exmor_RS

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

Простейший стресс: 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 - чтоб не происходило полное исчерпание памяти, тогда проблем нет.

hakavlad ()
Ответ на: комментарий от hakavlad

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

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

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

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

Dementy ()