При наличии мощных многоядерных процессоров и охочих до памяти программ возникает логичная идея ужать занимаемую память. В ядре Linux для этого существуют два механизма: ZSwap и ZRam. Первый сжимает страницы памяти, уходящие в своп, а второй предназначен для создания в оперативной памяти полноценных разделов с обычными файловыми системами. Особенность ZRam в том, что данные, записываемые на такие разделы, сжимаются на лету быстрыми алгоритмами lzo или lz4.
Активация ZRam в ядре:
После этого можно установить скрипты и юниты для systemd:
После этого останется только активировать загрузку нужных юнитов (здесь своп не был активирован):
Здесь видно, что в /var/tmp данные сжатые более, чем в 2 раза: столбец DATA отображает размер несжатых данных, столбец TOTAL показывает фактическое занимаемое данными место. С данными в /tmp ситуация хуже - там, в числе прочего, располагается кэш Chromium с его массой несжимаемых данных вроде картинок.
Можно попробовать собрать какой-нибудь пакет в ZRam. Например, Amarok.
Что ж, сборочные файлы сжимаются в 2 раза. Отражается ли это на скорости сборки пакета?
Активация ZRam в ядре:
После этого можно установить скрипты и юниты для systemd:
# emerge -av zram-initК услугам пользователя - 3 юнита systemd: для свопа, для /tmp и для /var/tmp. По дефолту в юнитах количество потоков сжатия/распаковки равно 2, поэтому при наличии процессора с большим количеством ядер стоит соответственно увеличить этот показатель. За количество потоков отвечает ключ -s:
ExecStart=/usr/sbin/zram-init -d1 -s8 -alz4 -text4 -ostrictatime -m1777 2048 /tmpКак видно, по умолчанию используется алгоритм сжатия lz4 - очень быстрый и удачный алгоритм.
После этого останется только активировать загрузку нужных юнитов (здесь своп не был активирован):
# systemctl enable zram_tmp.service
# systemctl enable zram_var_tmp.serviceИ после перезагрузки можно убедиться, что ZRam задействован вместо традиционной tmpfs:
Здесь видно, что в /var/tmp данные сжатые более, чем в 2 раза: столбец DATA отображает размер несжатых данных, столбец TOTAL показывает фактическое занимаемое данными место. С данными в /tmp ситуация хуже - там, в числе прочего, располагается кэш Chromium с его массой несжимаемых данных вроде картинок.
Можно попробовать собрать какой-нибудь пакет в ZRam. Например, Amarok.
Что ж, сборочные файлы сжимаются в 2 раза. Отражается ли это на скорости сборки пакета?
Удивительно, но дополнительная нагрузка на процессор - сжатие всё-таки небесплатно обходится - никак не отразилась на времени сборки пакета.# genlop -t amarok* media-sound/amarokSat Sep 12 18:29:56 2015 >>> media-sound/amarok-2.8.0-r3merge time: 2 minutes and 38 seconds.Tue Oct 6 23:09:05 2015 >>> media-sound/amarok-2.8.0-r3merge time: 2 minutes and 35 seconds.
Комментариев нет:
Отправить комментарий