Что в логах? Может сработал и прибил не то, что нужно. И до полного исчерапания ОЗУ могло и не дойти, просто был сброшен весь файловый кеш и GUI начал сильно тормозить.

SWAP ?

Потому что ты его не настроил. man -k limits что ли.

Тоже самое

Потому что он неспешный - это печальный факт. Я в таких случаях на десктопе тупо пинаю его через SysRq-F, иначе ждать пока он пропердится можно по 5 минут

SWAP отключи, сразу будет срабатывать.

SWAP отключи

Может наоборот, включить? Он отключен. На неделе пойду за дополнительной оперативкой видимо...

Потому что он неспешный - это печальный факт. Я в таких случаях на десктопе тупо пинаю его через SysRq-F, иначе ждать пока он пропердится можно по 5 минут

В моём случае 5 минут я ждал, пока мышка слайдшоу с залипонами изображала. Потом совсем всё зависло и перестало реагировать и я выключил комп. Что даёт это сочетание?

Потому что ты его не настроил. man -k limits что ли.

Спасибо, завтра посмотрю.

Что в логах? Может сработал и прибил не то, что нужно. И до полного исчерапания ОЗУ могло и не дойти, просто был сброшен весь файловый кеш и GUI начал сильно тормозить.

В логах ничего интересного. У меня такое было за пол часа до, когда я запустил стим и зашёл на страницу подруги проверить, что там и чем она занята. Условия были аналогичные. Там открылось куча анимаций, тоже на другом экране играл ютуб и начало так же замораживаться, я успел его в ручную закрыть. Датчик на рабочем столе показал, что Ram Full. А это случилось минут 40 спустя, тоже оперативка заполнилась, плазма начала офигевать и загаживать лог таким без остановки:

сен 16 17:46:50 dell plasmashell[741]: QXcbConnection: XCB error: 2 (BadValue), sequence: 5355, resource id: 94371856, major code: 142 (Unknown), minor code: 3

сен 16 17:47:42 dell plasmashell[741]: log_klipper: Checking clip data
сен 16 17:47:42 dell plasmashell[741]: log_klipper: Synchronize? false

сен 16 17:52:16 dell org_kde_powerdevil[811]: powerdevil: Releasing inhibition with cookie  172
сен 16 17:52:16 dell org_kde_powerdevil[811]: powerdevil: Can't contact ck
сен 16 17:52:16 dell org_kde_powerdevil[811]: powerdevil: Releasing inhibition with cookie  173
сен 16 17:52:16 dell org_kde_powerdevil[811]: powerdevil: Restoring DPMS features after inhibition release
сен 16 17:52:16 dell org_kde_powerdevil[811]: powerdevil: Can't contact ck
сен 16 17:52:22 dell org_kde_powerdevil[811]: powerdevil: Scheduling inhibition from ":1.15" "firefox" with cookie 174 and reason "screen"
сен 16 17:52:22 dell org_kde_powerdevil[811]: powerdevil: Scheduling inhibition from ":1.15" "/usr/lib/firefox/firefox" with cookie 175 and reason "screen"
сен 16 17:52:28 dell org_kde_powerdevil[811]: powerdevil: Enforcing inhibition from ":1.15" "firefox" with cookie 174 and reason "screen"
сен 16 17:52:28 dell org_kde_powerdevil[811]: powerdevil: Added change screen settings
сен 16 17:52:28 dell org_kde_powerdevil[811]: powerdevil: Added interrupt session
сен 16 17:52:28 dell org_kde_powerdevil[811]: powerdevil: Disabling DPMS due to inhibition
сен 16 17:52:28 dell org_kde_powerdevil[811]: powerdevil: Enforcing inhibition from ":1.15" "/usr/lib/firefox/firefox" with cookie 175 and reason "screen"
сен 16 17:52:28 dell org_kde_powerdevil[811]: powerdevil: Added change screen settings
сен 16 17:52:28 dell org_kde_powerdevil[811]: powerdevil: Added interrupt session
сен 16 17:52:28 dell org_kde_powerdevil[811]: powerdevil: Can't contact ck
сен 16 17:52:28 dell org_kde_powerdevil[811]: powerdevil: Can't contact ck

сен 16 17:57:26 dell plasmashell[741]: QXcbConnection: XCB error: 2 (BadValue), sequence: 8660, resource id: 94371856, major code: 142 (Unknown), minor code: 3
сен 16 17:57:26 dell plasmashell[741]: QXcbConnection: XCB error: 2 (BadValue), sequence: 8661, resource id: 94371856, major code: 142 (Unknown), minor code: 3

Что даёт это сочетание?

Взято с википедии

Alt + SysRq + F

Full — позволяет вызвать обработчик oom_kill (out-of-memory kill) для прерывания приложений, забравших слишком много памяти (может занять продолжительное время). Используйте его, если свободная память совсем истощилась, так что система не реагирует ни на какой иной ввод (курсор мыши не движется, индикаторы NumLock/CapsLock не включаются, но индикатор работы накопителя всё время включен);

Стоит помнить, что эта комбинация клавиш сработает даже если свободная память имеется - в таком случае будет прибито приложение, жрущее наибольшее количество памяти.

Огромный LA (комментарий)

что за sysrq-f?

будь котиком, просвети земляка

У меня не работает комбинация.
На встроенной в ноут клаве он при нажатии Alt + SysRq делает принтскрин (там и на кнопке нет такой надписи), а на механической внешней клавиатуре надпись есть, но при нажатии происходит ничего.

kernel.sysrq = 1

сделано?

https://wiki.archlinux.org/index.php/Keyboard_shortcuts

Да, печально это всё.

Время убивать

Почему ООМ киллер не сработал? (комментарий)

А другие сочетания работают? Например Alt+SysRq+B(осторожно - это аналог резета!)

Если нет - тогда чего-то не хватает в ядре или опция sysrq отключена, как уже предположили

А так - хз. У меня к OOM Killer-у только одна претензия: 5 минут пердолиться когда вся память засрана - это слишком долго. На всех системах у меня он всегда отрабатывал. Вопрос только - насколько быстро, на десктопе проще пнуть руками, чем ждать

Да. Или ещё modprobe zram помогает.

Не будет.

Чот фигня. Перепутал zram (который надо конфигурить), с zswap (который просто подгрузить нужно нужно включать через echo 1 > /sys/module/zswap/parameters/enabled или параметры ядра при загрузке, но оно просто буффер и похоже работает только при наличии обычного swap).

Чтобы сразу срабатывал можно overcommit отрубить, но это как-то...

С отрубленным overcommit'ом как раз меньше вероятность, что будет вызов OOM killer'а, там просто вызов malloc() в приложении вернёт ошибку, но ядро не будте считать эту ситуацию нехваткой памяти.

Но без swap overcommit лучше не выключать.

Угу, ты прав. Вообще и со swap'ом тоже не фурычит - у меня похоже firefox не работает вообще без overcommit.

Включил SysRq, работает, спасибо

Я хз, как проверить работоспособность. Ибо когда делаю tail /dev/zero, происходит

сен 18 11:42:54 dell kernel: Out of memory: Kill process 1475 (tail) score 763 or sacrifice child
сен 18 11:42:54 dell kernel: Killed process 1475 (tail) total-vm:6142936kB, anon-rss:6074656kB, file-rss:0kB, shmem-rss:0kB

Свап обычный я включать не хочу, ибо это может сказаться на быстродействии системы. Сделаю апгрейд небольшой оперативки на всякий случай.
В крайнем случае буду прибивать по SysRq. А тему, видимо, закрою, ибо нет возможности проверить работоспособность тех или иных параметров, т.к. при проверке простым методом оом киллер срабатывает, а воспроизвести проблему у меня не выходит. Работу надо делать, да и с сейлфишем играюсь и хобби проект незаконченный.

Я тут с костылями на cgroup поигрался - добавил memory в DefaultControllers в /etc/systemd/system.conf, ограничил память всего что запускается в пользовательской сессии 6-ю ГБ (всего в системе - 8Гб RAM):

echo 6G > /sys/fs/cgroup/memory/user.slice/memory.limit_in_bytes

А иксы и менеджер окон вынес в корневую memory cgroup.

... Написал и понял, что если вынести менеджер окон в корневую, то запущенные из него процессы тоже будут в корневой. Надо вставлять костыль, хорошо что window manager - qtile.

Но вообще сама идея вроде ок, отожрал память в терминале внутри user.slice - система при исчерпании памяти продолжает выглядеть отзывчивой и OOM-killer отработал моментально.

Ещё zswap включил, без него обычный swap тормозит ужасно, но работу OOM-Killer'а это не улучшило.

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

В вашем случаее скорее всего не было полного исчерпания памяти, просто её было настолько мало, что ни exec(), ни malloc() нормально не срабатывали, софт «не понимал» как ему работать дальше.

Не знаю, у меня работает (vm.overcommit_memory = 2, vm.overcommit_ratio = 90), правда под обычно пустой swap у меня выделено 2-3 объёма RAM.

Не сработал, потому что ты не использовал https://aur.archlinux.org/packages/earlyoom/

Только хуже станет.

Спасибо, то что нужно! Зашёл на страничку на гитхабе, там ещё так доступно объяснено всё, начиная с

Instead of sitting in front of an unresponsive system, listening to the grinding disk for minutes, I usually press the reset button and get back to what I was doing quickly.

Единственное, стандартное ведь echo -17 /proc/1234/oom_adj не поменяется получается для НЕубийства определённого процесса?

Вруби обычный своп. OOM-киллеру нужно время, чтобы заметить неладное. Пока в своп медленно будут писаться данные, OOM-киллер успеет отработать. ИМХО. Проверить - пара минут.

Уже проверено.

Время убивать

На SSD своп - это выброшенное впустую место