Есть ли хоть одна причина...

Есть ли хоть одна причина...

Как минимум одна всегда найдется — причина в том, что ты это до сих пор не реализовал.

Поставь стрекозу и не лезь к костылинуксу. Код oom killer в FreeBSD в разы длиннее и запутаннее. Это правда не тривиальная задача.

неправильно

Да.

Наверное можно под себя ядро скомпилировать, жестко задав размеры для своей системы.

Как, ещё не было комментария про докупку памяти? Ну, значит, вот он!

Поставь стрекозу и не лезь к костылинуксу.

А системд у ней есть?

Это правда не тривиальная задача.

Можно здесь подробнее?

Да.

Можно здесь подробнее? (2)

Как, ещё не было комментария про докупку памяти? Ну, значит, вот он!

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

просто ты не знаешь таких магических слов как dirty_cache и zswap.

О чём? Кеш по определению должен занимать всю свободную память. Его не нужно ограничивать. То, что ты наблюдаешь — либо косяки настройки параметров через sysctl, либо мистический баг, либо фича.

Как работает своп линукса:
1. Память кончается.
2. Начинаем свопить.
Как работает своп у всех остальных систем:
1. Свопим всё.
2. Стараемся освободить максимум ОЗУ, даже если нет в этом необходимости.

Как работает шелдулер линукса:
https://www.opennet.ru/base/sys/linux_shedulers.txt.html
- если грубо, поделить ресурсы поровну по-очерди.
Как работает шедулер в FreeBSD: на основе эвристик придумать, каким процессам ресурсы нужнее.

Также и с ООМ.

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

Ещё можно почитать про треды M:N, которые идеологически более правильные, чем 1:1, но их осилил только автор стрекозы. К тормозам прямого отношения не имеют, но интересно.

У меня тоже «вешается» система, когда, например, firefox сжирает своп до предела. На ctrl-alt-F1 не реагирует, по ssh не подключиться. Приходится reisub'ом перезагружаться. А надо бы повесить OOM на какую-нибудь свободную букву sysreq'а (там же ещё не все заняты?).

То, что ты наблюдаешь — либо косяки настройки параметров через sysctl,

Всё по debian'овскому умолчанию.

либо мистический баг, либо фича.

Интересно, что это.

firefox сжирает своп до предела

Ну, ССЗБ. А если хочешь хороший OOM, иди кури LKML, его там последние полгода активно курочат.

А надо бы повесить OOM на какую-нибудь свободную букву sysreq'а

если ты про OOM-killer, то Alt+SysRq+F

Ты не понял вопрос. Я хочу ограничить снизу, зарезервировать минимальное количество памяти для кэша, чтобы оом срабатывал быстро. Сейчас перед срабатыванием оом система превращается в тыкву на неопределенное время. Насколько я понимаю, причина в том, что формально памяти еще хватает, но для кэша ее совсем не осталось, и ввод-вывод становится чудовищно медленным.

Как работает своп линукса

Неправда же, от /proc/sys/vm/swappiness зависит, по умолчанию начинает свопить при 40% занятой памяти

Да без разницы, всё равно на других принципах основано. Во фре в принципе чем больше ОЗУ - тем больше своп должен быть по инструкции. Не потому, что ОЗУ не хватает, а чтобы всегда было свободное место.

https://github.com/ivanfitenko/oom_ext

sysctl oom_ext_bufsize=512

выставит 512 мегабайт аварийного буфера, который будет освобожден в случае ООМ

Оспаде, не думал, что тут филиал Лафокса ;).

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

Есть ли хоть одна причина, по которой в 2017 году

ты не можешь поставить 32 Гб озу?

firefox сжирает своп до предела

Ну, ССЗБ.

Это может быть и git gc --aggressive. И прочее. В том случае, когда работает долго, потребляет памяти, вроде, в нормальных пределах, а сидеть следить нет возможности.

О! Так он там уже есть. Надо будет разогреть огнелиса да проверить, не убьёт ли oom мне XServer вместо него.

Нужно брать последнее ванильное ядро

А Debian не подойдёт?

скриптовать надёжный репродьюсер

Интересно, если взять и рандомом повызывать malloc + mem write / free, т.е. с фрагментированием занять почти всю память. А потом продолжать read / write и чуть-чуть malloc.

32 Гбайт? Всего-то на 4-ядерном проце (при 8 потоках) на некоторых репозиториях git gc --aggressive «повесит» ядро. А 64 не везде поставишь, да и будет уже очень дорого. Да и то, только до тех пор пока не поставишь 8-ядерный (16-поточный) райзен.

Debian

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

Т.е. нужно не только ванильное ядро, а ещё и программка, использующая только сисколы вместо glibc, и прописанная в «init=» ядра? А ещё лучше только MacBook Air, который у Торвальдса или он его уже поменял?

Лучше быть самим Торвальдсом, но никто не идеален.