Скорее пережитки монолитной программы образования. Мне 10 лет назад в университете на полном серьезе читали устройство ГАС Контур

А как min_free_kbytes решает проблему?

Так это же очень сложная система с массой деталей, которые не могли предусмотреть даже академики.

Обучение, ну, как минимум при СССР, предполагало понимание причин и следствий.

Например, что сначала в РБМК были стержни-вытеснители, в которых был концевой эффект. Кратко: если их уронить очень быстро, то реактор глушится мгновенно. Если медленно — то тоже всё хорошо.

Но если их вводить как 26-го апреля 1986-го, то будет тепловой разгон.

И нам сначала рассказывали, как и почему была сделана первая версия, а потом объясняли, почему оно было переделано.

нет тех эффектов о которых вы говорите. Система остается управляемой

Ага, как пример эволюции сложной системы. Круто!

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

но это + отключение свопа делает систему надежной. Своп делает её желеобразной.

thrashing я видел, не знал  что он так называется

Так вот.
Зания о РБМК мне не пригодились в жизни, но помогли понять, что такое эксперимент, что такое исправление ошибок в проде, а самое главное — обязанность признавать ошибки.

Если инженер не в состоянии сказать что он обосрался, он плохой инженер.

Именно поэтому я требую ото всех не только признания ошибок, но и ответа на вопрос, как исправить.

Да, ещё важный момент: будь всё сделано по инструкции, без желания во что бы то ни стало получить результат (о чём я всегда промываю мозги), то РБМК был бы заглушен сразу после провала ниже нижнего уровня мощности, и никакой аварии бы не было.

Возможно, после этого история пошла бы иначе.

И это очень обидно, да...

Так а в чем проблема со свопом?

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

mlock чем не выход?

вырубить своп сильно универсальнее

Там выше пример в lkml.

1. грузимся с mem=4G
2. Выключаем своп
3. Открываем толпу вкладок в chrome

Есть даже описание почему так происходит.

В стриминговом софт разве не принято загонять в лимиты для соблюдения гарантий?
плюс всякие memory tracking, memory management не юзаются?
Не набрасываю, просто интересуюсь, так как не мой профиль, я больше по базам.

да не, не принято.   Кто-то пытается рассказывать о том, как они филигранно использую хитрые сисколлы или мастерски рулят VFS-ом через fadvise, но почему-то всё это регулярно не взлетает и разоряется

Сложно как-то :)
Имел в виду использование собственного аллокатора в user space, который позволит не только видеть статистику, но и на уровне своего софта выставлять лимиты для контекстов.
Когда можно виновника увеличения memory flow  задетектить уже на тестах и дать ему по башке своим MEMORY_LIMIT_EXCEEDED.

мы например пишем на эрланге, тут вообще не очень с управлением памятью и реакцией на её отсутствие.

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

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