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

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

Материалы для ознакомления:

• Memory leaks in nodejs

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

Хотя может «безопасность» (Rust) не смогла избавить от ошибок. Не знаю переписали ли уже лиса на самом безопасном языке 🤣🤣🤣🤣

В JS могут течь приложения как и на любом скриптовом языке

И всё-таки в скриптовом языке с GC (примеры: JS, Lua, любая скриптуха на JVM) утечку создать сложнее, чем в скриптовом языке с подсчётом ссылок (примеры: perl, cpython)

Правда, у JS конкретно в браузере есть дополнительная возможность для утечек, а именно использование DOM-объектов, которые создаются в нативном коде и не подчиняются JS GC. В хроме, если я ничего не путаю, гугловцы устали бороться с утечками т сделали-таки GC для них, тогда как в WebKit (и, скорее всего, в Firefox тоже, но я не проверял) продолжают использовать для них подсчёт ссылок. Утечка вызывается комбинацией бага в браузерном движке и сомнительного JS-кода.

oom-killer

как то раз впервые услышав про zswap тут же решил его попробовать… но как заставить машину всю память пожрать? вынул планку 4 гига, вставил планку 1 гиг - так быстрее пожрется, расчет оказался верным - запускаешь браузер и памяти нет, но ничего не тормозит - zswap работает и никакой oom-killer ничего не убивает, я конечно слышал кое что про это буквосочитание, но в живую не сталкивался никогда, однако заметил - все эти разговоры ведут пользователи довольно больших объемов памяти.

Там слово утечка можно в кавычки брать. Тут просто имеет место незнание того как работает интерпретатор. Шаблон примерно такой:

• Обезьяна беерет в цикле 100500 раз копирует строку, например, вызывая метод .replace()
• Затем она возвращает объект содержащий ссылку на оригинальную строку (строки иммутабельны, всякие слайсы от них ссылаются на оригинал) и куда-то его пихает
• Обезьяна ожидает что в памяти будет средний размер подстроки * 100500, а там размер копии строки * 100500
• Обезьяна высирает кирпичи и в бложике пишет, что %ScriptLanguage% течет о чем соб-но, приведенная мною первая ссылка из гугеля

Те код той чепухи можно починить так:

for (...) {
  // ...
  arr.push(match[1] + '')
}

Ну там судя по логу течет фаерфокс сам по себе:

Firefox Memory Leak
Mozilla confirmed the memory leak on Firefox 112.0.1's release notes page. There, the organization provided the following information about the issue: "Under rare circumstances, animated Firefox themes can use excessive memory."

According to Mozilla, the issue may be experienced only when users have installed specific animated themes, such Dark Space, in Firefox and use it actively. Additionally, Firefox would leak memory only a browser window was either minimized or occluded.

All of these conditions had to be met for the memory leak to occur. Mozilla recommends that Firefox users switch to another theme until it is releasing a patch for the issue: "If you encounter this problem, please change your theme to one that does not use animations to work around it. We are in the process of shipping a fix".

Mozilla is working on a fix, and progress can be monitored on Bugzilla. There, users are informed that the issue is affecting Firefox 112, 113 and 114, but not Firefox ESR.

The issue was reported to Mozilla 6 days ago and engineers have worked on the fix ever since. Beta and Nightly versions of Firefox have updates already that should address the issue.

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

По словам Mozilla, проблема может возникнуть только в том случае, если пользователи установили в Firefox определенные анимированные темы…

Кстати, а ведь у кого-то ‘течет’, а кто-то говорит, что нет. Дефолтную то тему, наверно, большинство меняет.

Строго говоря как и zswap с zsmalloc по дефолту. Только zswap настраивается 3-я опциями, а zram для полноценной работы нужно раздел диска выделять.

Не, моё «забито» это «used» по free или зелёная полосочка в htop. Это даже не вся память ядра и приложений, там ещё разделяемая сверху и только потом идут всяке кеши и буферы (часть из которых нельзя отбрасывать!). Вот как раз эту память приложений и надо бы начинать сбрасывать заранее (желательно в ленивом режиме, хотя такого вроде бы ещё нет) на уровне 70-85% чтобы оставался резерв под кеши и внезапный запрос памяти.

который можно дропнуть в любую секунду

На практике как раз нет - он кеш записи а не чтения. Или там вроде есть отдельная категория кода библиотек, который один хрен скоро придётся перечитать с диска (что точно так же займёт ресурс i/o, как и свопинг). И тем более это надо делать не за 10мс до ППЦ, а заранее.

Дефолтную то тему, наверно, большинство меняет.

Зачем? Она хотя бы как-то вписывается в GTK.

Не меняет. После какого то из апдейтов это стало слишком сложно. Они даже свой собственный веб-сервис раскласки через дополнение запилили, но с ним тоже всё сложно и медленно.

Хотя бы потому, что дефолтная тема гтк уныла, уродлива и требует замены.

На практике как раз нет - он кеш записи а не чтения

Кэш записи можно подтюнить параметрами dirty_ratio/dirty_bytes и dirty_background_ratio/dirty_background_bytes

Не, моё «забито» это «used» по free или зелёная полосочка в htop

По моему личному опыту, когда остаётся около гига available, то ядро начинает бодро сбрасывать страницы в своп даже при низких значениях swappiness. Хотя это поведение должно зависеть ещё и от от текущей активности файлового i/o и выделения памяти приложениями, если всё спокойно, то свопить вроде бы и незачем. Предугадать пиковую аллокацию на несколько гигов, возникшую из ниоткуда, ядро, понятное дело, не сможет, и в таком сценарии придётся как-то ему помочь.

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

Значит стиоит по умолчанию. Какой это дистрибутив?

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

В логе - работа ядерного киллера.

anon-rss:10598920kB - лис сожрал 10 гиг.

если уже установлен новомодный systemd-oomd, тогда не знаю

В логах - работа ядерного, а не юзерспейсного.

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

Киллер создан для выживания системы путем жертвования жирным процессом.

Ну, если использование оперативки перевалило за 80% то это определённо признак высокой вероятности нехватки памяти.

когда остаётся около гига available, то ядро начинает бодро сбрасывать страницы

Там же проценты. Я так понимаю min_free_kbytes это как раз тот резерв памяти на случай непредвиденных обстоятельств а не строгая необходимость некогда не использовать эту память. А watermark_scale_factor насколько я понял максимально близко к тому пределу, после которого надо начинать свопиться. Но там 90% это самый максимум, а по дефолту что то совсем позднее.

Вот только его почему то пытаются использовать для выгрузки «лишних» вкладок чтобы не допустить фризов в ДЕ.

Так говоришьл будто что-то плохое. Фриз - это смерть.

Ну ядерный так ядерный. Хотя 10 гигов для браузера это вполне норм.

Это когда у тебя они есть, а тут два браузера и 16 Гб.

Кстати, а ведь у кого-то ‘течет’,

У меня течет, дефолтную тему не менял.

По-хорошему там должно быть ещё 16 свопа.

Своп, конечно, должен быть, но не для компенсации нехватки памяти. С ним oom-killer просто придёт позже, и тормозить будет адски.

и тормозить будет адски

Не будет если своп на zram.

Пора с мака скоммуниздить их чудо своп, чтобы был в динамическом файле и работал с максимальной прозрачностью

А systemd-swap чем не устраивает? Ну кроме того, что автор забил на него, так как сам теперь использует zram

Оно в файле, который размер менять умеет?

Иногда появляются темы, подобные этой При сборке chromium закрываются все открытые терминалы, где ТС на компе с 64Gb памяти (без свопа) компилит chromium с -j32 и приходит oom-killer. И сразу от комментирующих: «Сборка во сколько потоков? Если несколько, то уполовинь для начала.»

И изредка, в таких случаях, хочется скинуть в тред твой коммент Zram и сборка в памяти. (комментарий), но там на скриншоте «ошибка сегментирования», к чему сразу прицепятся. Поэтому не выкладываю в качестве аргумента «вау-эффекта». :)
Понятно, что там не ставилась цель компиляции до победного.

Вот пример: 2 гига памяти, и 6 улетело в своп.
Это сборка ядра 514 в 128 потоков, емнип, на двух гигах оперативы.

Нет кучу файлов создает по 512 мегабайт. Чем тебе не динамический размер?

создает по 512 мегабайт

Там настраивается размер файлов и их количество. Сам пользовался раньше, но как и сказано выше, автор его забросил и посоветовал zram-generator.

Ну вооот. Нет чтобы в ядро встроить

У меня не случается никаких истерик от вида фризов. А вот сброшенная вкладка и 10с на её перезагрузку (хорошо если не больше) - вот это реально хреново.

Хотя 10 гигов для браузера это вполне норм.

65 вкладок? Да не... Наверняка там найдётся что нибудь, во что он упрётся раньше по цпу в 1 потоке.

Своп нужен и для компенсации недостатка, и для увеличения стабильности. А тормозить он будет не адски, а довольно слегка. В любом случае - для браузера свопинг оправдан на 99,9%. Посадить вкладку в своп на ssd и поднять обратно раз в 10-20 быстрее, чем сбросить и перезагрузить. А всякие zswap"ы и прочий тюнинг бесследно глотают 95% «адских» фризов.

Уже 10 лет как в каждом чайнике. А с 4.4 ядра так ещё и очень хорошо работает.

Посмотри в about:memory что у тебя кушает память. Может какое расширение. Там же, кстати, можно её и почистить.

а zram для полноценной работы нужно раздел диска выделять

Какого диска?

echo 8G > /sys/block/zram0/disksize
mkswap /dev/zram0
swapon /dev/zram0

Это было неплохо для hdd (но бесполезно, там давно нет смысла экономить что то меньшее, чем 10гб), но вероятно плохо для ssd и флеша вообще. Для этих штук очевидно лучше зарезервировать некую крупную область чтобы дать ftl пространство для балансировки.

Вот только его почему то пытаются использовать … чтобы не допустить фризов в ДЕ.

В ядрах ≥ 6.1 есть параметр /sys/kernel/mm/lru_gen/min_ttl_ms. Цитата: "Это в общем регулировка агрессивности киллера".

Дефолтно 0, и при исчерпании памяти и свопа система может успеть хорошо так подвиснуть, как ты и любишь. ) Обычно меняют на 1000.

upd. Да, я помню, что ядра ≥ 6.1 ты не используешь.

...и вот мы запускаем какую нибудь виртуалку, она оседает в zram, выжирает эти 8Гб, мы ставим её на паузу и идём на соседний рабочий стол чтобы погуглить. Но zram забита и висит в оперативке! А мы сидим без zram в том что осталось!

Есть очевидное решение, вот эту виртуалку сбросить на диск, а оперативку и освободившийся zram использовать для более актуальных данных. Только такого механизма в виртуальном блочном устройстве не предусмотрено! И в подсистеме свопа не предусмотрено перекачки страниц с одного диска на другой. Зато это изначально было в zswap потому что это не виртуальное блочное устройство, а прослойка сжатого кеша между оперативкой и диском.

А так как юзеры упорно используют для сжатия памяти виртуальное блочное устройство zram, и гугл с яндексом активно тиражируют это своей поисковой выдачей, разработчики ядра прикрутили костыль: backing_dev, который служит собственной своп-подсистемой zram на отдельный раздел, чтобы оно могло работать... как zswap! И сдрасывать самые ненужные сжатые данные на физический диск, оставляя в памяти только более востребованные.

И если вам кажется что это редко проявляющийся и неважный косяк - я вас разочарую. Я долго и упорно долбился об него пока не осознал, почему ускорение от сжатия так быстро пропадает. И потом подтвердил всё тестами, причём как раз на примере сёрфинга в 2Гб оперативки.

Там отображается что то около трети занимаемой браузером памяти.

В первую очередь я не использую киллера потому что до его прихода как пешком до Китая - у меня свопа от 500% до 12000% оперативки. А вообще настраиваемый ядерный киллер это более правильно чем всякие oomd.

В таком сценарии, безусловно, удобнее использовать zswap. Но ведь не всем нужно сбрасывать на диск. Zswap, в свою очередь, сложно адекватно настроить на работу только в RAM.

Адекватные анонимусы… «Истинно говорю вам, земля налетит на небесную ось (c)».

А мы тут в соседней теме скрипт для заблюрирования мутили, :) Добро пожаловать домой, Анонимус (комментарий).

❤️👍️