«Lz4 без деградации CPU» — обещание, которое ломается под нагрузкой. Типовой разбор отказа бюджетного узла: сервис тормозит, мониторинг показывает активный swap, дежурный обвиняет накопитель. Сначала swapon --show: если своп размещён на /dev/zram0 и writeback не настроен, эти страницы вообще не уходят на диск. Сжатое хранилище занимает ту же физическую RAM. vmstat 1 показывает интенсивность swap-in/swap-out в si/so; первый отчёт — среднее с загрузки, смотрим следующие. cat /proc/pressure/memory показывает время задержек из-за нехватки памяти: some — простаивает хотя бы одна задача, full — одновременно все не простаивающие задачи. Рост PSI вместе с устойчивым обменом страницами — повод искать thrashing. Средняя загрузка CPU по узлу сама по себе этот диагноз не исключает. cat /sys/block/zram0/compalgorithm: выбранный алгоритм отмечен скобками. В cat /sys/block/zram0/mmstat первые три поля — origdatasize, comprdatasize, memusedtotal. Последнее учитывает расход аллокатора, поэтому выигрыш по памяти оцениваем через origdatasize / memusedtotal, а не только по размеру сжатых данных. При плохо сжимаемых страницах запас быстро исчезает; при постоянном обращении к вытесненным страницам оплачиваем повторное сжатие и распаковку. Граница применения проста: холодные страницы хорошо сжимаются, горячий набор помещается, p99 и PSI выдерживают нагрузочный прогон. Lz4 обычно дёшев по CPU, но нулевую деградацию гарантировать нельзя. Размер zram — логическая ёмкость, а не подаренная память. Ни K3s, ни дорогая панель мониторинга эту арифметику не исправят. Практика эксплуатации: https://ftops.space/?utm*source=telegram&utm*medium=smm&utm*campaign=ftops&utm*content=zram-svoping-na-nedorogih-uzlah-szha