oom-killer зачем-то убивает Огнелиса по утрам

Может он cpu начинает утилизирувать

В принципе, если какое-то веб-приложение запущено всё это время, то вполне может столько памяти израсходовать. У меня на гуглмапсах постоянно подтекает, что после получаса интенсивного елозенья приходится перезагружать вкладку. И на некоторых браузерных играх такое тоже бывает.

Если тебе FF не нужен, то можешь его временно останавливать: pkill -STOP firefox. Продолжить процесс - pkill -CONT firefox.

oom_score_adj=200

А захрена, собственно? У тебя может течь любой другой процесс ( 67185556 2821 282624 0 200 baloo_file), но ядро видит Firefox как самый ненужный и убивает его.

UPD: Скорее всего, даже Brave, а не Baloo.

А захрена, собственно?

Не знаю 🤷🏻‍♂️ Я в эту сторону никогда руками не лез и ничего не менял

Надо помониторить как офокс пожирает память за это время. Может просто в крон засунуть через каждые 10-15 мин питоновский ps_mem и писать выхлоп в один файл >>

Ставишь sysstat (не требует настройки), утром смотришь статистику.

Вообще это ожидаемое поведение юзерспейсных киллеров.

Если это какой-нить ситемд-оом то имей в виду, что он не для домашнего использования. Возможно фаерфокс запускает процесс проверки обновления/слива метрик, начинает хавать память, и оом прибивает всё вокруг.

Но я не понимаю, почему.

Firefox течет и выжирает много памяти со временем. Поэтому он мог выжрать достаточно памяти, чтобы oom-killer его убил.

началось что-то непонятное. Сажусь утром за компьютер

10:58:17 ... Out of memory: Killed process 1957 (firefox)

Как одно из решений, завести будильник на 10:30. )

А если серьезно, установи earlyoom, у него больше настроек, чем у дефолтного. Сможешь выставить приоритет приложениям, кого килять в первую очередь, а кого приберечь. Выставить момент срабатывания, когда осталось сколько то процентов ram и процентов свопа…
(Есть еще nohang от ЛОРовца, там настроек просто море, и соответсвенно сложнее для понимания, что крутить.)

Тем более, раз говоришь, что памяти хватает (16G), то возможно просто дурИт штатный oom-killer.

Свободной оперативки предостаточно

«Не верю» (с). Вызов oom-killer’a всегда связан с нехваткой оперативки, а именно с тем, что в Linux называют «cache pressure». Настраивайте мониторинг, ищите, кто выедает память.

Firefox течет и выжирает много памяти со временем. Поэтому он мог выжрать достаточно памяти, чтобы oom-killer его убил.

Чем дольше процесс работает, тем меньше его скор. Поэтому, чтобы oom-killer его убил, нужно, чтобы он выедал память достаточно быстро, а не по чайной ложке в час. Ну или чтобы в системе кончилась вся память и своп, и Firefox оказался лучшим из кандидатов на убивание.

Если это какой-нить ситемд-оом

И да, если уже установлен новомодный systemd-oomd, тогда не знаю. Чтобы не городить масло масляное.

Кстати, в логе видно, что firefox перед смертью наел более 10 гигов памяти, что намного превышает жор все остальных «конкурентов».

Ещё судя по логу в системе отсутствует своп, что чревато кучей неприятностей, включая буйство киллера, внезапные фризы, сбои в работе драйверов некоторых устройств, неэффективное использование оперативной памяти и т.д.

Total swap = 0kB

Вступил в секту отключения свопа - ну вот.

Но ведь «Свободной оперативки предостаточно». )

Умные люди говорят, что своп – это не про мало оперативки.

Я вот, ради интереса наоборот пытался как-то заставить систему юзать активнее своп. Оперативы у меня 8 гигов (своп 10 гигов), вроде бы не трудно это сделать, а нифига. swappiness поставил 100, тоже еле-еле, только когда что-то компиляет начинает жрать, а в простом режиме сидения за компом какие-то мегабайты. Так всё и оставил, продолжаю наблюдение 🤣

Тогда уж top, полезной информации будет несоизмеримо больше.

FF может быть вообще никоим боком. Пишите скриптом как можно чаще в лог расход ресурсов и их потребителей - вычислите виновного, кто именно начинает по утрам их подъедать. Если это сам FF - по очереди давите вкладки, кто знает, что там за задачи

своп

У тебя же дистр от «красной шапки»? Там zswap по умолчанию включен?

Все же «шапка» вроде как задает стиль всему линукс-сообществу (в плане тех. решений), или я преувеличиваю? )

upd. Хотя по Федоре были новости, что там zram дефолтно. И то ли и сейчас так, то ли убрали.

Вот поэтому и нужно держать своп.

Хотя бы символические 2ГБ. Или поток-два zram по 500мб.

Там zswap по умолчанию включен?

Не знаю, что это такое, а вот zram отсутствует, надо ставить из epel. Я использовал одно время, но смысла не нашёл, выкинул.

upd

Да.

Не знаю

$ cat /sys/module/zswap/parameters/enabled

В арче дефолт «Y».

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

$ cat /sys/module/zswap/parameters/enabled

Кофейку попью и проверю.

то ли убрали.

Не убрали.

Брось каку! С 16 гектарами оперативки oom-killer может только всё портить. Он и создан для того чтобы творить непонятную дичь.

Это скорее старый миф чем реальность. Фактически встречал подобное поведение максимум на 1-2 сайтах за последние годы, причём скорее в вивальди чем в фоксе. Хотя может у меня просто ublock везде стоит... В любом случае вариант с утечкой на десяток гигов сейчас практически невероятный.

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

Это скорее старый миф чем реальность

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

PS. У меня 48 гигабайт памяти.

Лучше конечно раз в 5 минут делать скриншот с окошном top/htop и сортировкой по объёму памяти...

Да хоть скринкаст записать в 1фпс чтобы не напрягаться.

Какой ещё скриншот?

top -b -n 1 >> top.log

А вообще там вроде даже без цикла можно обойтись, в top настраивается и задержка между страницами и время он сам показывает.

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

Другое дело когда в ~2010 Опера на песто ничего не делая на одноклеточной страничке могла выжрать 3 из 2 гигов оперативки за 4-6 часов. Буквально на глазах. И фокс тоже тёк, только очень медленно - неделями.

У меня не выжирает, правда у меня 32 бит и возможно он вместо этого просто падает. Хотя он плодит процессов по 10 штук, можно и 20-30гб в сумме сожрать ими.

Но это же 1 конкретный сайт

У меня другой сценарий был. Если куча вкладок открыта и если среди вкладок есть тяжелые сайты, как тот же ютуб, то течет гарантированно.

Другое дело когда в ~2010 Опера на песто

О кстати исходники же выложили в общий доступ, попробую собрать и затестить.

Эту портянку потом ещё как то анализировать. А она будет за 100К строк. В случае скриншотов-скринкаста ты всё будешь видеть мотая линейку времени.

Это пока в дело не вступил cgrops и systemd со всякими лимитами и своим уникальным виденьем как распределять память. И при условии что киллер работает по понятному и предсказуемому алгоритму и написан без багов. А то мало ли, вдруг этот «cache pressure» может давать какую нибудь странную флуктуацию из за какого нибудь trim на ссд, когда вроде как надо бы скинуть пару страниц, но диск то не доступен в данные 10мс...

swappiness уже давно про другое - про баланс страниц памяти приложений и каких то других страниц. Но уже давно не про активность. Тут скорее /proc/sys/vm/min_free_kbytes и /proc/sys/vm/watermark_scale_factor

zswap это как zram, только без 2 ненужных сущностей - эмуляции виртуального блочного устройства и backing_dev - собственной реализации физического свопинга. По факту проще в настройке и так же эффективен, как и правильно настроенный zram.

Это пока в дело не вступил cgrops и systemd со всякими лимитами и своим уникальным виденьем как распределять память.

С лимитами всё просто: когда лимит по памяти превышен, приложению больше памяти не выделяется. Часто после этого радостно сегфолтится на нулевом указателе, но это не обязательно. Киллер вызывается только когда нехватка памяти угрожает стабильности системы в целом.

А то мало ли, вдруг этот «cache pressure» может давать какую нибудь странную флуктуацию из за какого нибудь trim на ссд, когда вроде как надо бы скинуть пару страниц, но диск то не доступен в данные 10мс…

Эм… что? trim не выделяет память в таких объемах, которые могут стриггерить киллера.

Увеличение min_free_kbytes может защитить от косяков в драйверах при нехватке памяти. Но не проще ли включить своп?

Можно запустить atop в режиме демона, а потом смотреть историю которую он запишет.

Или collectd

С лимитами всё просто: когда лимит по памяти превышен, приложению больше памяти не выделяется.

Вот прям так всё просто! А что отвечается приложению вна вызов «дай памяти»? И мне казалось все эти лимиты в cgrops вообще работают не на уровне выделения памяти а на уровне принудительного свопинга.

выделяет память

Зато создаёт i/o, а нагрузка i/o может конкурировать со сбрасыванием страниц на диск, а именно в таких ситуациях возникает своп-трешинг.

Так ведь про то, как сделать его более активным когда он уже включен. А то по дефолту память забита на 90%, а никто ещё не чешется пока ППЦ не подкрадётся.

Так ведь про то, как сделать его более активным когда он уже включен.

Если своп не используется, значит этого не требуется.

А то по дефолту память забита на 90%, а никто ещё не чешется пока ППЦ не подкрадётся.

Ядро в состоянии отслеживать состояние памяти. Твоё «забита на 90%» скорее всего включает несколько гигов кэша, который можно дропнуть в любую секунду.

И да, про это раньше часто писали в статьях о Линуксе, но всё-таки напомню: Линукс стремится минимизировать значение free, т.к. память должна работать, а не простаивать.

zswap это как zram

Нет. Насколько я помню по дефолту zram ещё память не умеет высвобождать.

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

На ЛОРе в таких случаях любят кидать ссылку на linuxatemyram. )