LINUX.ORG.RU

Можно ли обезопасить себя от смерти при нехватке памяти?

 ,


2

2

Бывает такая ситуёвина, что запущено некоторое количество тяжёлых приложений, которые выжерают всю память, за ней своп и вешают намертво систему, не давая возможности себя убить. Можно ли с этим как-то бороться? Мне кажется, что это в корне неправильно.

Deleted

Если OOM не приходит, то вызывай его принудительно: Alt + SysRq + F. Только это сочетание обычно выключено по умолчанию и тебе придется его включить.

Ну и вот эта настройка для sysctl должна помочь:

vm.oom_kill_allocating_task=1

Kron4ek ★★★★★
()
Последнее исправление: Kron4ek (всего исправлений: 1)

Можно ли обезопасить себя от смерти

Нет

vertexua ★★★★★
()

Свопа докинь, ты забудешь что такое нехватка памяти. Хотя бы половину от имеющегося. Хотя если засвопится активное приложение (если памяти совсем мало), то тебе поможет только хардресет. Вряд ли хуже будет.

И swapiness 90 или 100 выставь. Ты замечаешь только когда кончается память и своп.

anonymous
()

Почему бы сразу не ограничить аппетиты жручих или текучих сервисов посредством cgroups?

Можно и тихонько рулить(например в systemd) перезапускать сервисы которые выедают памяти больше от разрешённого

[Service]
MemoryMax=16M
Restart=on-abnormal

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

Вроде ж SSD дохнут от активного свопинга, не? А так то SSD я могу и сейчас купить, но логичнее, как мне кажется, было бы купить память. Ещё логичнее – новый ноут, но на него пока не накопил. Спасибо, кстати, за смешную шутку про работу, до тебя до неё никто не додумался, ага.

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

Вроде ж SSD дохнут от активного свопинга, не?

На лоре прочитал? Здесь и не такого бреда можно начитаться.

логичнее, как мне кажется, было бы купить память

Ну да. Хотя лучше и то, и другое.

anonymous
()

Нет ты все равно умрёшь. Вопрос времени

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

На лоре прочитал?

Да.

Ну да. Хотя лучше и то, и другое.

Ну не все такие умные и предприимчивые, как ты. Вот я туповат и родился за мкадом, потому мне приходится на ноут копить.

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

Да.

ЧТД. SSD дохнут от брака. И ты его выбросишь задолго до износа памяти просто потому что станет мало ёмкости или производительности.

родился за мкадом

Пфф, я тоже.

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

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

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

Да все уже поняли, что ты умненький, а я – дурачок. Не усердствуй.

Deleted
()

Чо ты там не можешь? Alt+SysRq+R, Ctrl+Alt+F1, и жди, пока раздуплится. Потом прибивай, чо надо. Ну или Alt+SysRq+F, если доверяешь автоматике, как выше подсказали.

anonymous
()

Только 2 варианта:

1) Использовать менее тяжелые приложения

2) Обновить оборудование.

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

Если не секрет, что за приложения, которым не хватает 4 Гб? Фотошоп под Линукс вроде не завезли.

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

Если не секрет, что за приложения, которым не хватает 4 Гб? Фотошоп под Линукс вроде не завезли.

Хром + PhpStorm

Deleted
()
31 августа 2020 г.
Ответ на: комментарий от fornlr

Наверно только сменой ОС

В линуксах - лучшая обработка нехваткм памяти из всех ос при правильной настроке. Демо: https://www.youtube.com/watch?v=veY606v57Hk

Своппинг мягок, вызов киллера своевременен.

На что ты предлагаешь менять ос?

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

только cgroups

Конечно нет. Например, есть процессы с большим RssFile и мальеньким Anon. В группах RssFile не учитывается в memory.current.

Ты можешь ставить лимит в memory.max, но это не поможет:

процесс может весить 4 гига (VmRSS) и столько же отнимать от доступной памяти. При этом в memory.current будет 200M вместо 4G.

Хорошая практика - это реагировать на общесистемный уровень доступной памяти, а не на размер отдельных memory.current в сигруппах.

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

В группах RssFile не учитывается в memory.current.

С какой это радости? Учитывается, и ещё как. Даже page cache и тот учитывается.

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

Инфа 100% не учитывается.

Пример: машина с VirtualBox.

RSS 4 гига например. current будет намного меньше, несколько сотен. И в структуре RSS соответственно: гигабайты File и сотни Anon.

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

VirtualBox, внезапно, особый случай. Память виртуалки присваивается корневой цгруппе — наверное, потому что выделяется ядерным модулем.

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

Память виртуалки присваивается корневой цгруппе — наверное, потому что выделяется ядерным модулем.

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

Вот и опыт:

# systemd-run prelockd -c /usr/local/etc/prelockd/prelockd.conf
Running as unit: run-rc75ece6cd9d0489cafea32df777f9107.service

# oom-sort
oom_score oom_score_adj  UID   PID Name            VmRSS   VmSwap   cmdline
--------- ------------- ---- ----- --------------- ------- -------- -------
        0             0    0 28296 python3           112 M      0 M python3 /usr/local/sbin/prelockd -c /usr/local/etc/prelockd/prelockd.conf

# cat /proc/28296/cgroup
0::/system.slice/run-rc75ece6cd9d0489cafea32df777f9107.service

# cat /sys/fs/cgroup/system.slice/run-rc75ece6cd9d0489cafea32df777f9107.service/memory.current
11915264

>>> 11915264 / 1024 / 1024
11.36328125 (MiB)

# cat /proc/28296/status
Name:	python3
...
VmRSS:	  114660 kB
RssAnon:	    8728 kB
RssFile:	  105932 kB
RssShmem:	       0 kB

Как тебе такое? В сигруппе отражена анонимка 10 метров. Сто метров файловой - не отражено в memory.current.

наверное, потому что выделяется ядерным модулем

Нет. Выше пример обычно процесса, без всякиих модулей. Это не особый случай.

Ядро 5.8.5.

hakavlad ★★★
()
Последнее исправление: hakavlad (всего исправлений: 1)

Сдается мне есть вариант со вторым жестким диском или флешкой ибо подкачке ненужны рейды чтоб работать. Ну еще своп в начало диска можно перетащить.

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

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

Ну вот она там лежит. Корневая цгруппа — 14GB, system.slice + user.slice — 6 GB. Памяти виртуалке было выделено 8.

Сто метров файловой - не отражено в memory.current

А эти сто метров файловой вообще считаются занятыми? ну то есть после запуска программы соответствующий столбец вывода free изменяется на сто метров?

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)

теоретически, можно настроить ограничение памяти, firejail вроде умеет при определенных настройках ядра

anonymous
()

Использовать cgroups, ограничить этим приложениям память не большое определённого значения. Когда они её выжрут, упадут сами.

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

сто метров файловой вообще считаются занятыми?

В used не учитывается, но доступная память на сотку убывает. А нас-то как раз убыль доступной интересует в контексте предотврвщеня OOM.

Вот еще опыт: 125 current, 650 RSS, 650M убыль доступной. used убыль 10М

# systemctl stop prelockd
# free -m
              total        used        free      shared  buff/cache   available
Mem:           9781        4146        1930         563        3704        4410
Swap:        293443         113      293329
# systemctl start prelockd
# free -m
              total        used        free      shared  buff/cache   available
Mem:           9781        4158        1801         567        3821        3757
Swap:        293443         113      293329


# oom-sort | grep prelockd
        0          -100    0 30898 python3           650 M      0 M


# cat /sys/fs/cgroup/system.slice/prelockd.service/memory.current
131158016  # 125M

# status
VmRSS:	  665748 kB
RssAnon:	   10328 kB
RssFile:	  655412 kB


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

Корневая цгруппа — 14GB, system.slice + user.slice — 6 GB

Где ты берешь данные корневой? в корневой лежат только слайсы, там нет memory.current, емнип.

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

Где ты берешь данные корневой?

В systemd-cgtop :)

в корневой лежат только слайсы, там нет memory.current, емнип.

Зато есть memory.stat (хотя по документации его тоже не должно быть).

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

Наверно только сменой ОС

+1. Даже Haiku нормально обрабатывать нехватку памяти умеет. Overcommit не нужен.

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

вызов киллера своевременен

При нехватки памяти malloc/mmap должен возвращать NULL, а не убивать программу.

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

Кому должен?

  1. Большинство программ не умеют обрабатывать allocation failure и либо падают с sigsegv, либо вызывают abort().

  2. При нехватке памяти убить жирную протёкшую программу – наименьшее зло, чем вернуть NULL в случайную ни в чем не виноватую программу и нарушить её работу. Которой может оказать что угодно: текстовый редактор с несохранёнными файлами, сетевая служба, менеджер сеанса, иксы.

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

+1. Даже Haiku нормально обрабатывать нехватку памяти умеет.

Нормально это как – возвращая NULL всем клиентам подряд?

Overcommit не нужен.

fork() работает через астрал?

wandrien ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.