Обещание «zram с lz4 без деградации CPU» ломается на первом тесном узле. Типовой отказ: после включения swap на zram OOM отступил, но под нагрузкой вырос p99. Диск почти без работы — поверхностный мониторинг отправляет искать проблему в приложении. Ложный диагноз: zram обслуживает swap в RAM, поэтому отсутствие дискового I/O ничего не говорит о цене подкачки. Снимаем улики: cat /proc/pressure/memory, vmstat 1 и cat /sys/block/zram0/mm_stat. Рост memory PSI показывает время остановок из-за нехватки памяти; устойчивые si/so вместе с ростом задержек требуют проверки оборота страниц. В mm_stat первые три поля — orig_data_size, compr_data_size, mem_used_total. Последнее учитывает накладные расходы хранения: оценивать экономию только по размеру сжатых данных — приукрашивать отчёт. Проверяем cat /sys/block/zram0/comp_algorithm: активный алгоритм указан в квадратных скобках, lz4 выбирают до инициализации устройства. Его скорость не отменяет затрат CPU. Плохо сжимаемые страницы съедают выигрыш, а постоянно востребованные страницы запускают повторные вытеснения и возвраты. Размер zram — логическая ёмкость устройства, а его содержимое занимает ту же физическую RAM, за которую уже дерутся процессы. Исправление — уменьшить конкурирующий рабочий набор или дать узлу память; zram оставить запасом для холодных страниц. Приёмка — p99, CPU и memory PSI под репрезентативной нагрузкой, а не красивый коэффициент сжатия. Покупать облачный тариф вместо диагностики — налог на лень; обещать бесплатную память через lz4 — та же бухгалтерия. https://ftops.space/?utm_source=telegram&utm_medium=smm&utm_campaign=ftops&utm_content=zram-svoping-na-nedorogih-uzlah-szha