В моем случае что досталось то досталось. Я только начал с ним колдовать, покрутил кеши, зашедулил скраббинг.

Все равно каша в голове

Теперь чуть понятнее стало

Хочу добавить 2 копейки про ООМ (у нас была ситуация с виртуалками - он их клал хотя памяти свободной было достаточно)
ООМ киллер высчитывает порог памяти (то когда он начинает килять процессы) по своей собственной хитрой схеме в которую входят спец коэффициенты + размер свапа.
У нас все настройки работы памяти и ООМ были по умолчанию, РАМ было 256ГБ а свап 16гб. ООМ киллер убивал вируталки когда memory used было чуть больше 200гб.
Всякие тюнинги vm.overcommit* не помогали да мы и не то чтобы до конца въезжали. То есть он сделал условно 256 +16 + свои коефиценты и у него получилось ~200гб.
Что нам помогло - увеличение свап до 64ГБ

то что я написал звучит очень по дилетантски ибо таковым и является) я не системных архитектор

теперь у нас правило что свап всегда 1/4 от РАМ, даже если РАМа очень много

@socketpair а помнишь ты когда-то чего-то писал про билды цефа что у них что-то было собрано криво и сжатие не работало или типа того?

да. под доебан. не было поддержки аппаратного CRC32 и сжатия вообще

и под еблунту тож самое

а из-за чего это было?

кривые хуи.....они повсюду....

там патч какойто очень мутный

это понятно, что там конкретно не было прописано?

надо искать

конкретно точно не было

там же типа автодетект чо есть. аля ./configure только ебать замудрёное

а, типа оно вообще собиралось без библиотеки сжатия?

по мне как по аффтару можно найти в багтрекере там и ссылка на ПР есть

да

без всех