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