Пользователь
0,0
рейтинг
11 марта 2013 в 16:48

Администрирование → Использование zRam для увеличения количества доступной памяти под Linux

image
Уже 2 месяца использую на своих компьютерах модуль zRam и хочу поделиться результатами. На практике он позволил мне не используя раздел подкачки, и не получая видимого замедления работы компьютера увеличить размер оперативной памяти в 2.5-3 раза. На сервере виртуалок тот же подход позволил очень ощутимо увеличить отзывчивость при нехватке памяти.
Заинтересовавшихся прошу под кат.

Как говорит Википедия

zRam это экспериментальный модуль ядра Linux (ранее известный как «compcache»). Он увеличивает производительность путем предотвращения подкачки страниц на диск, используя сжатое блочное устройство в оперативной памяти, пока не появится необходимость использовать файл подкачки на жестком диске. Скорость обмена с оперативной памятью быстрее, чем с жестким диском, следовательно zRam позволяет Linux производить большее число операций подкачки, особенно на старых компьютерах с малым объемом оперативной памяти.

Для пользователя все выглядит так: для начала нужно загрузить модуль (предварительно скомпилировав если он отсутствует)

modprobe zram num_devices=4


В num_devices задается количество сжатых блочных устройств, которое будет создано.
Для наиболее оптимального использования CPU стоит учесть: сжатие каждого устройства zram однопоточное. Потому я создаю их по количеству ядер.

При настройке модуля задается фиксированный размер НЕ сжатых данных в байтах

SIZE=1536
echo $(($SIZE*1024*1024)) > /sys/block/zram0/disksize
echo $(($SIZE*1024*1024)) > /sys/block/zram1/disksize
echo $(($SIZE*1024*1024)) > /sys/block/zram2/disksize
echo $(($SIZE*1024*1024)) > /sys/block/zram3/disksize


В итоге будет создано устройство /dev/zram0 заданного размера

Disk /dev/zram0: 1610 MB, 1610612736 bytes, 393216 sectors
    Units = sectors of 1 * 4096 = 4096 bytes
    Sector size (logical/physical): 4096 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Данные записанные на него будут прозрачно сжаты в памяти. Что делать с ним далее — уже ваш выбор, я на этих устройствах создаю разделы подкачки.

mkswap /dev/zram0
mkswap /dev/zram1
mkswap /dev/zram2
mkswap /dev/zram3

swapon /dev/zram0 -p 10
swapon /dev/zram1 -p 10
swapon /dev/zram2 -p 10
swapon /dev/zram3 -p 10


Далее уже ядро думает само какие данные туда складывать в зависимости от того как часто вы к ним обращаетесь и как много памяти свободно.

Мой опыт показывает, что степень сжатия обычно 1 к 3.

На практике это позволило на ноутбуке в 8Gb памяти вынести компиляцию libreoffice в tmpfs. (она требует 7 Гбайт временных файлов и примерно 1 Гбайт памяти потребляет каждый поток gcc при сборке).

Область применения такой идеи крайне широка:
  • нетбуки: у девушки ноутбук в двух-ядерным Atom-мом. И всего лишь 2 гигабайта оперативной памяти (больше не вставить). В итоге одна «наглая рыжая морда» все время съедала всю память и посылала машину в swap. Подключил zRam и девушка довольна
  • Сервера виртуализации: прозрачное сжатие памяти виртуальных машин может позволить выполнять большее число виртуальных машин одновременно: у нас есть сервер используемый для тестирования веб-приложения под различными конфигурациями клиентов (операционки, браузеры, версии плагинов к браузерам, настройки локалей и кодировок). Прохождение тестов на нем всегда было «задумчивым» процессом. Использование zRam позволило уменьшить время прохождение тестов с 30 минут до 18


Дополнение:
Изначально разработка велась под названием compcache, и первые рабочие версии были сделаны для ядра 2.6.26(Июль 2008)
Начиная с декабря 2009 года и ядра 2.6.33 оно доступно в ядре, в разделе Staging. Для более старый ядер патчи все еще доступны на вышеуказанном сайте.
В ядре 3.8 должно было быть вынесено из Staging, но это не произошло.
Дмитрий @darkdimius
карма
69,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (94)

  • +41
    Самое главное что девушка довольна)))
    • +7
      Есть и другие менее замысловатые способы сделать девушку довольной, но Хабр-юзеры не ищут лёгких путей!
  • +6
    Все же непонятно, как оно работает… Откусывается кусок оперативной памяти, или это прозрачно для других приложений.

    Насколько быстрей стал работать компьютер у девушки?
    • +1
      Работает примерно также как tmpfs — откусывает кусок памяти «от имени ядра».
      Из интересных подробностей: команды discard\trim это блочное устройство воспринимает примерно также как ssd. Под капотом высвобождаются используемые блоки памяти.
      Потому если на блочном устройстве сделать файловую систему не умеющую discard\trim, то освобождаться эта память почти не будет(но вырасти неограниченно она не может, так как вы задали максимальный размер несжатых данных).
      • +2
        И наивный вопрос, есть ли аналог под винду?
        • +2
          Невозможно в силу технических особенностей ядра Windows.
          • 0
            Можно подробней? Интересно очень)
            • 0
              Если Вы посмотрите материал на тему менеджера памяти Windows то заметите что MS не оставила релоков или хуков на случаи расширения памяти в процессе, в Linux и UNIX в этом плане проще и есть вариант расширения памяти на лету.
              Если посмотреть исходники ReactOS которые были получены реверсом то примерно понять работу стандартного менеджера можно.
              Хотя конечно в принципе возможен порт модуля zRAM — но только для обычных приложений (ring3 level) — это писать драйвер для хука Win32 API по работе с памятью — например VirualAlloc, HeapAlloc и т.д. — и управлять таким образом памятью. Ну конечно не забыв при этом пофиксить пачку системных DLL и SxS — т.к. некоторые программы не будут работать нормально при хуке импорта в процессе.
          • +2
            А что мешает создать сжатый RAM-диск? Конечно, могут быть трудности с размещением в нем файла подкачки (диск должен создаваться раньше, чем файл подкачки во время загрузки), но замапить туда тот же TEMP или еще что вполне реально… Или вы о чем-то другом?

            /me задумался о более эффективном использовании своих 16 гигов оперативы..
            • 0
              Можно, но можем получить цикличный эффект, т.е. когда страницы буду очень часто обмениваться и в целом это будет не очень хорошо.
              По поводу диска, насколько Я помню был вариант загрузки драйвера ДО старта подкачки, правда не могу точно сказать за новые ядра от Win7/8.
              /me у меня 32GB и больше, однако продакшен софт все-равно лучше тестить на продакшен железе, т.к. дома такое достаточно проблематично собрать и поставить.
          • 0
            А как же тогда девушка довольна?
            • +7
              win-админам придется отдуваться по-старинке)
              • 0
                в Hyper-V для Server 2012 было что-то подобное для гостевых ВМ (нужно будет поискать название)
            • 0
              Заработать и купить ультрабук :)
              P.S. несмотря на то что фраза устарела — но все еще актуальна.
        • 0
          Пользовался подобным под windows 95. Оно умело сжимать данные в ОЗУ и при этом виндовс показывал не 4М RAM, а 7М.
          Название может быть qmem, но могу ошибаться.
          • 0
            Быть может, QEMM?
    • 0
      Изменения в скорости работы у девушки пока firefox не сьел всю память незаметны.
      После того как сьел — до этого был мягко говоря черепахой, работать было невозможно. После изменения — в реальный swap мало что уходит вообще, вероятно память используемая firefox легко сжимается.
      • 0
        Получается два своп-файла, один на блочном устройстве другой на реальном хдд? А по какому принципу они приоритезируются?
        • +1
          Параметр -p который я передавал в swapon /dev/zram0 -p 10 это и есть приоритет. Страницы подкачки располагаются в устройствах и файлах подкачки согласно убыванию их приоритета(сначала полностью заполняются пространства с большим приоритетом). Приоритет по умолчанию — 1.
          В итоге: если у swap на диске приоритет по умолчанию и для zram указан приоритет 10, то swapping на диск не будет происходить до израсходования размера zram.
    • +1
      >Все же непонятно, как оно работает

      судя по тексту статьи, грубо говоря — своп сначала делается на виртуальный диск и только если его не хватает — то на реальный винт.
      Однако не понятно, как текст статьи соответствует вступлению: то, что свопаться на рамдиск быстрее, чем на физический веник — это понятно. Как это может привести к «увеличению размера оперативной памяти в 2-3 раза» — совершенно не ясно.
      • 0
        Не просто свопаться на рамдиск, а попутно сжимать данные. По-моему, всё очень понятно расписано.
        • –1
          А сжимать данные в обычном свопе на венике нельзя?
          • 0
            Скорость жёсткого диска всё равно значительно медленнее. А здесь получается производительность почти как у памяти, с небольшим оверхедом на сжатие.
            • 0
              так в статье речь про скорость или увеличение объёма памяти?

              См. мой комментарий:

              Однако не понятно, как текст статьи соответствует вступлению: то, что свопаться на рамдиск быстрее, чем на физический веник — это понятно. Как это может привести к «увеличению размера оперативной памяти в 2-3 раза» — совершенно не ясно.
              • 0
                Как не понятно-то: в хорошем случае те страницы, которые свопнуты в память таким образом, сжимаются в 2-3 раза при этом почти не теряется скорость работы с ними. Следовательно, это в первом приближении то же самое, что и увеличение доступной памяти.
                • 0
                  мне трудно представить, что данные, которые сбрасываются в своп и при этом ещё и сжимаются/разжимаются дают такое же время доступа как и «обычные», какую бы магию тут не пророчил описанный рецепт. Имхо, сравнивать нужно не с системой «только RAM» а с системой «RAM+swap». И по сравнению с ней данный рецепт даёт только прирост скорости, причём его ещё нужно правильно подсчитать, т.к. «ускоренный своп» делается в ущерб объёму «нормальной» (по скорости) памяти.
                  • 0
                    В случае, когда памяти хватает на всё: во всех случаях (нет свопа, zRAM, дисковый своп) все данные размещаются непосредственно в памяти и скорость одинакова.
                    Когда память заканчивается: в случае zRAM часть памяти отводится под сжатые страницы (соответственно, туда помещается больше страниц, чем при обычном свопе), откуда они достаются быстрее, чем с диска => скорость больше.
                    Ну а когда не хватает и zRAM, тогда в любом случае нужно обращаться к диску, что очень медленно.

                    Таким образом, производительность с zRAM всегда не хуже чем в других вариантах (по крайней мере, в теории — на практике нужно проводить тесты).
                    • 0
                      На практике — могу заверить, не хуже, по крайней мере при использовании процессоров с частотой не ниже 1ГГц. за время, прошедшее с момента написания статьи, тестировал на 5 разных машинах — производительность действительно увеличилась, а количество обращений к диску резко упала.
  • +1
    Насколько я понимаю, происходить сжатие данных для хранения в памяти. При этом создается обычное блочное устройство. Если сделать своп на zRam, он, естественно, будет работать быстрее чем своп на винт, т.к. сжатие в память работает быстрее чем сброс данных на винт.

    Правда, не совсем понятен механизм выигрыша при использовании именно свопа. Ведь сама система zRam отъедает кусок ОЗУ.
    • +2
      Да, zRam отьедает кусок ОЗУ. Но она не хранит полностью нулевые страницы памяти, и те данные которые она хранит почти всегда в сжатом виде занимают меньше места чем оригинальные.
      Моя практика показывает что на сервере виртуализации степень сжатия 1 к 3. На ноутбуке девушки видел и 1 к 10.
      • 0
        Ну, тогда, в общем-то имеет смысл. Надо будет попробовать. Еще-бы, конечно, неплохо было разместить информацию о доступности этого модуля в разных версиях ядра.
        • 0
          Дополнил пост информацией о версиях.
      • 0
        Интересно, почему ОС не делает такую оптимизацию изначально?
        • +1
          OC делает такую оптимизацию на момент выделения страницы. Для нормальных страниц, если мне не изменяет память, такая оптимизация есть очень давно.
          Для huge-pages появилась в 3.8.
          zRam делает это не в момент выделения, а в процессе работы. Часто бывает что какието данные в странице «были, да сплыли». То есть после того как OC выделила страницу с нулями, какое то значение было записано, а потом обнулено. В итоге страница полна нулей, но чтобы ОС сделала оптимизацию нужны какие то трюки.
  • +14
    Сделал бы кто-нибудь обзор всяких прикольных, неизвестных и полезных модулей ядра
    • +4
      Ядро слишком разнообразно и многие фичи нужны очень ограниченному кругу лиц. Многие спорны и холиварны(тотже x32 ABI)
      Если Вы укажете какие для Вас представляют интерес — может опишу.
      • 0
        Огласите весь список, пжалста… Или раскажите где/как вы их находите? На kernel.org, на git.kernel.org? С ходу не обнаружил…
        • +4
          Как нахожу:
          Я гентушник. Причем не потому что скомпилированная система под локальную машину имеет некое ускорение. И не потому что скомпилированная под мои нужны включает только то что мне надо и весит 3 гига. А потому что я получаю наслаждение от понимания что, как и почему работает.
          Во время компиляции очередной версии ядра, иногда вчитываюсь в настройки, начинаю гуглить и разбираться. И нахожу такие плюшки.
          Во время появления новых приложений в дереве portage читаю их описания. Если заинтересовало — гуглю. Вскоре собираюсь написать статью о opensource full-mesh vpn сети. О которой узнал потому что у нее полтора месяца назад появилась новая версия в portage.
          • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            tinc? Очень давно жду.
            • 0
              Угадали. Сейчас гоняю бенчмарки и пишу статью
  • 0
    Поделитесь конкретным конфигом для нетбука, у меня как раз машинка с двумя гигами есть
    • +1
      На нетбуке у девушки стоит gentoo(вообщето Calculate, но это gentoo :) )
      zRam вкомпилирован в ядро. При загрузке ядру передается zram.num_devices=4
      Из них используются только 2, с размерами по 768мег(в итоге 3/4 памяти может быть сжато)
      созданы файлы
      /etc/local.d/zram.start
      #!/bin/bash
      
      #modprobe zram num_devices=4
      
      SIZE=768
      echo $(($SIZE*1024*1024)) > /sys/block/zram0/disksize
      echo $(($SIZE*1024*1024)) > /sys/block/zram1/disksize
      
      mkswap /dev/zram0
      mkswap /dev/zram1
      
      
      swapon /dev/zram0 -p 10
      swapon /dev/zram1 -p 10
      
      

      /etc/local.d/zram.stop
      #!/bin/bash
      
      swapoff /dev/zram0
      swapoff /dev/zram1
      
      
      echo 1 > /sys/block/zram0/reset
      echo 1 > /sys/block/zram1/reset
      
      

      /tmp вынесен в tmpfs, с ограничением размера на 1 гиг.
      • 0
        Через udev элегантней и правильнее создавать устройства.
        rules.d # cat 10-zram-swap.rules
        KERNEL==«zram0», ACTION==«add», ATTR{disksize}=«2097152000», RUN="/sbin/mkswap /$root/$name"

        а приоритет можно выставлять при монтировании в /etc/fstab
      • 0
        Главное не спутать Атом с двумя ядрами и Атом с гипертредингом.

        Если сделать два девайса на гипертрединге, то цпу будет полностью занят системой, а когда свопы в памяти закончатся — всё встанет.

        С одним девайсом фурычит нормально, наконец-то можно отдаться пороку открытия бесконечных вкладок в браузере и запуска Eclipse на нетбуке =)
    • +1
      В результате гуглежки наткнулся вот на это. Если точнее, init.d скрипт вот тут лежит (или посмотреть на гитхабе). Если будете ставить на Debian Wheezy, то в скрипте нужно поменять на 26 строчке «modprobe zram num_devices=..» на «modprobe zram zram_num_devices=..», это бага, посмотреть багу можно тут.
  • +1
    Объясните пожалуйста как происходит прозрачное сжатие памяти виртуальных машин. Из статьи понятно только как swap там настроить.
    • 0
      Для host-системы память виртуальных машин это память приложений.
      Когда физической памяти будет недостаточно для хранения памяти всех приложений, ядро начинает swapping редко используемых страниц памяти. Причем это происходит для памяти, как занятых приложениями, так и tmpfs. В итоге редко используемая память виртуальных машин будет сжата.
  • 0
    поделись конфигом сервера виртуализации? и что на нам, xen?
    • +3
      Kvm. На нем поставлен gui — app-emulation/virt-manager. Сеть и жесткие диски по virtio, графика по spice.
      Никаких конфигов руками не правлено, все по-умолчанию.
      Если вызывать из консоли это будет чтото вроде
      qemu-kvm -m 2048 -name xp-ie8 -drive file=/srv/images/Xp-ie8.img,if=virtio -vga qxl -spice port=5900,addr=127.0.0.1,disable-ticketing  -net nic,macaddr=00:1e:3e:00:00:14,model=virtio -net tap,ifname=tap04
      
  • 0
    Интересен еще KSM/uKSM, есть опыт использования?
    • 0
      KSM у меня включен уже давно. С добавления его в mainline в 2.6.32. И сравнивать уже тяжело. Он не дает ощутимого замедления и порой дает уменьшение размера. Вещь безусловно полезная.
      uKSM не использую и не буду до того как не войдет в mainline, так как желание попадаться на «локальные особенности» у меня уже иссякло. Наигрался.
  • 0
    Интересно на Android такое используется? И какой выигрыш может дать? :)
    • +2
      Во многих «народных» прошивках используется.
      Выигрыш имеет тотже характер что и на ноутбуке: когда память заканчивается не происходит переход в состояние «я черепаха, не трогай меня».
  • +4
    Пытался пользоваться этой штукой года три-четыре, а потом еще раз ~два, назад, и она была так себе стабильна — при сильной нагрузке можно было схлопотать странное. Уж не знаю, правда, почему — не доходили руки разбираться.
    Из интересных вариантов расположения свопа есть еще видеопамять.
    • +2
      > Из интересных вариантов расположения свопа есть еще видеопамять.

      К сожалению, мегатормознуто :(

      /dev/mtdblock0:
       Timing buffered disk reads:   4 MB in  4.19 seconds = 976.81 kB/sec

      • 0
        Можете уточнить какая у Вас видеокарта?
        • 0
          Radeon HD 6320, 256Mb

          Погуглил, у народа получалось на других картах скорость порядка 4-5Mb/sec, а это тоже очень мало…
  • 0
    Какой алгоритм используется для сжатия? Если gzip, то слишком медленно. Если LZO, то стоит попробовать.

    Как мониторить, сколько памяти занимают данные в памяти? /sys/block/zram0/size — оно?

    Как мониторить, сколько отжирается CPU на [де]компрессию?
    • 0
      С мониторингом CPU стоит как-то относится осторожно. По идее, каждый раз, когда будет обращение к такому swap, будет происходить context switch на task, который вынет и распакует страницу памяти. Тут не на проценты стоит смотреть, а тестить в каждом отдельном случае. Для некоторых приложений csw не так страшен, а для некоторых критичен.
    • +2
      Алгоритм, насколько мне известно LZO. Но были и патчи для snappy, однако приняты не были.
      Как мониторить, сколько памяти занимают данные в памяти? /sys/block/zram0/size — оно?

      у меня size там отсутствует.
      Есть zero_pages — количество страниц заполненных нулями.
      Есть orig_data_size — размер изначальных данных за вычетом «нулевых» страниц
      Есть compr_data_size — размер данных в сжатом виде.
      Есть mem_used_total — суммарное потребление памяти с учетом фрагментации и метаданных.

      В итоге для расчета степени сжатия я использую формулу mem_used_total/(zero_pages*4096+orig_data_size)

      Как адекватно измерить потребление CPU на сжатие данных ядром я не знаю. Если Вы знаете метод — буду рад протестировать.
      • 0
        Где были мои глаза?!

        Однако, судя по www.kernel.org/doc/Documentation/ABI/testing/sysfs-block-zram
        zero_pages*4096 из вашей формулы нужно исключить.
        • +1
          При написании ответа я пользовался этим же файлом
          The zero_pages file specifies number of zero filled pages
          Количество страниц. Стандартный размер страницы для x64 — 4Кбайт. Потому чтоб получить размер изначальных нулевых страниц в байтах zero_pages*4096
          • 0
            The zero_pages file is read-only and specifies number of zero
            filled pages written to this disk. No memory is allocated for
            such pages.
          • 0
            OK, туплю, всё у вас правильно.
          • 0
            Я надеюсь, x64 это не на девчачьем нетбуке?
            • 0
              Ибо, по некоторым тестам, типичные юзерские проги жрут в 64 битах в полтора раза больше памяти, чем в 32. И моему нетбуку стало заметно легче, когда я одумался.
      • 0
        Итогам использования и размышлений в течение нескольких дней

        1. Не уверен в оптимальности создания zram блочных устройств по количеству ядер. Это делается в надежде, что на каждый чих будут задействованы все ядра, т.е. на всех произойдёт context switch. При этом при тяжёлой нагрузке на zram основными операциями будут извлечения сжатых страниц, что и на одном ядре должно происходить достаточно быстро. Нужны бенчмарки. Который всё равно мало что докажут, т.к. на разных нагрузках и процессорах оптимальные стратегии могут отличаться
        2. При освобождении страниц в свопе zram не идеально освобождает занятую память, compr_data_size/mem_used_total легко опускается до 0.8. Из общих соображений, при использовании только одного zram блочного устройства эффективность использования памяти должна быть выше. Я на всех своих машинах использую num_devices=1
        3. Опять-таки из общих соображений на x86_64 эффективность сжатия должна быть значительно выше, чем на i686, т.к. из-за увеличения interger'ов и различного выравнивания структур в памяти на архитектуре x86_64 будет гораздо больше нулей. Моя небольшая нерепрезентативная статистика это подтверждает: на i686 десктопе compr_data_size/orig_data_size колеблется в интервале 0.45 — 0.6, а на x86_64 крутится в интервале 0.3 — 0.35
        4. На большинстве моих машин количество занятого места в свопе согласно /proc/swaps совпадает с mem_used_total+zero_pages*4096. А вот на убунточке вечно всё не как у людей
          $ uname -a
          Linux olga-notebook 3.5.0-23-generic #35-Ubuntu SMP Thu Jan 24 13:15:40 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
          $ head /sys/block/zram0/{orig_data_size,zero_pages}
          ==> /sys/block/zram0/orig_data_size <==
          101617664
          
          ==> /sys/block/zram0/zero_pages <==
          1505
          $ awk '/zram/{print $4}' /proc/swaps
          139624
          $ echo $(( (101617664+1505*4096)/1024 ))
          105256

          А где ~34 неучтённых мегабайта?! Я было подумал, что из-за того что zero_pages включили в себя transparent huge pages, но нет
          $ grep AnonHugePages /proc/meminfo
          AnonHugePages:     12288 kB
  • 0
    Идея хорошая, но ещё есть потенциал для развития, ведь если прикрутить сжатие нативно к пейджеру — получится ещё производительнее. Сейчас ядро вынуждено гонять страницы через I/O систему к zram и обратно, когда в этом нет необходимости.
    • –1
      Ещё одна идея для улучшения — несжимаемые и слабосжимаемые страницы (а таковы тоже найдутся, например jpg или другой медиаконтент) принудительно сбрасывать таки на дисковый своп. И опять же нативная поддержка пейджером будет куда предпочтительней, т.к. для zram придется делать файловый бакенд на диске, а использовать fs для свопирования не самая лучшая идея — не зря в unix-ах swap лежит в отдельном блочном устройстве.
  • –1
    Не пойму, как Рыжелиса разогнать удалось? Из-за того, что своп переехал в сжатую память, и стал быстрее? Так Лис жрет ОЗУ столько, что на 2 Гб он да ОС и влезут, т.е. отдать заметный объем под swap вроде как нереально…
  • +6
    Для убунты достаточно выполнить
    sudo apt-get install zram-config
    :)
  • 0
    Поясните пожалуйста, а в чём отличие от просто выключенного свопа? Кроме сжатия данных. Зачем свопить, если можно держать всё в озу?
    • 0
      Зачем свопить, если можно держать всё в озу?

      Пока все влазит в ОЗУ и тут тоже не будет свопа.
      Поясните пожалуйста, а в чём отличие от просто выключенного свопа?

      В поведении когда ОЗУ кончается. Отключенный своп череват oom-killer-ом.
      Например: на серверах виртуалок, плотность укладки виртуалок часто превосходит доступное количество памяти, потому swap выключать нельзя. А латентность сжатия на порядки ниже чем время доступа к жесткому диску. Даже ssd.
      • 0
        Пока влазит — не будет, но кусок ОЗУ то уже будет скушан, а так понял это актуально только для виртуалок или где-нить ещё, где ОЗУ может кончиться?
      • 0
        Если виртуалки однотипные, то модуль который объединяет страницы памяти с одинаковым содержимым (забыл, как он называется) должен помочь намного больше, чем zram.
        • 0
          Это не модуль, просто опция: CONFIG_KSM (Kernel Samepage Merging).
  • +12
    <irony>
    — Слушай, Гена, давай я понесу чемоданы, а ты понесёшь меня…
    — Это ты здорово придумал, Чебурашка!
    </irony>
  • +3
    Накидал тут себе универсальный скрипт запуска. Определяет количество процессоров, оперативки и вычисляет сколько устройств создать и сколько памяти им отвести, всего отводит им половину оперативки (см. параметр USERAM). Проверено в openSuSE 12.2, должно работать и в других системах.
    /etc/init.d/zram
    #! /bin/bash
    
    ### BEGIN INIT INFO
    # Provides:          zram
    # Required-Start:
    # Default-Start:     3 5
    # Required-Stop:
    # Default-Stop:      0 1 2 6
    # Short-Description: start zram swap
    # Description:       start zram swap
    ### END INIT INFO
    
    
    . /etc/rc.status
    
    CPUS=`grep /proc/cpuinfo -e processor|wc -l`
    
    rc_reset
    
    case "$1" in
        start)
    
            RAM=`grep /proc/meminfo -e MemTotal|grep -o -E '[[:digit:]]+'`
            USERAM=$(( $RAM / 2 ))
            DEVRAM=$(( $USERAM / $CPUS ))
    
            echo "Activating $CPUS zram swap device(s), using total $USERAM kb, $DEVRAM kb per device."
    
            modprobe zram num_devices=$CPUS
    
            for (( i=0; i<$CPUS; i++ )); do
                    echo $(($DEVRAM*1024)) > /sys/block/zram$i/disksize
                    mkswap /dev/zram$i
                    swapon -p 10 /dev/zram$i
            done
    
            rc_status -v1 -r
            ;;
        stop)
            echo "Deactivating zram swap"
    
            for (( i=0; i<$CPUS; i++ )); do
                    swapoff /dev/zram$i
                    echo 1 > /sys/block/zram$i/reset
            done
    
            rmmod zram
    
            ;;
        restart)
            $0 stop
            $0 start
            ;;
        status)
            rc_reset
            rc_status -v
            ;;
        *)
            echo "Usage: $0 {start|stop|status|restart}"
            exit 1
            ;;
    esac
    
    rc_exit
    
    • +2
      Да, вот ещё на всякий случай — считалка степени сжатия. Показывает «нетто» (чистое сжатие) и «брутто» (отношение несжатых данных к общему использованию памяти). Второе радует, понятное дело, меньше, у меня оно стабилизировалось в районе 1.5.
      zram_cr
      #! /bin/bash
      CPUS=`grep /proc/cpuinfo -e processor|wc -l`
      for (( i=0; i<$CPUS; i++ )); do
              ODS=`cat /sys/block/zram$i/orig_data_size`
              MEM=`cat /sys/block/zram$i/mem_used_total`
              CDS=`cat /sys/block/zram$i/compr_data_size`
              echo Compression ratio of zram$i: `echo "scale=3; $ODS/$CDS;"|bc -l` net, `echo "scale=3; $ODS/$MEM;"|bc -l` gross.
      done
      
      • 0
        CPUS=`grep /proc/cpuinfo -e processor --count`
  • +1
    Для тех, кто задается этим вопросом: гибернация работает, суспенд в память работает.
    • 0
      Алсо: размер девайса указывает объем именно несжатых данных, т.е. при девайсе в 1,5 гига он рапортует, что занимает фактически 500 мб с копейками.
      Видимо, можно сделать девайс размером 3 гига из расчета на 1 гиг памяти.
      Только размер дискового свопа придется ещё тщательнее выбирать.
  • 0
    Почему-то в статье к команде swapon не добавлена опция -d, которая заставляет ядро делать discard на блоки swap'а, которые не нужны. Без этой опции, если система попользуется swap'ом и потом посчитает, что больше ей там хранить нечего, сжатые страницы ей не вернутся.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    А есть ли опыт использования подобного в продакшне?
  • 0
    Я ж правильно понимаю, что для 32битной системы объем памяти плюс свопа не должен превышать 4 Гб?
    • 0
      Есть PAE с лимитом в 64Гб ценой некоторого снижения производительности памяти. Но лимит в 4Гб на процесс остаётся.
  • 0
    «Оно больше внутри, чем снаружи!» (с)

    Насколько я понял, каждое ядро распаковывает страницу для себя само.
    Но вот интересно, а если одно из (4-х) ядер сделать dedicated упаковщиком/распаковщиком — получится в среднем быстрее или нет?
  • 0
    А как правильнее сделать монтирование при старте системы?
    • 0
      Автозагрузка модуля и fstab?

      По случаю вопрос: можно ли передавать размер устройства в виде параметра при загрузке модуля?
      • 0
        В 3.9 точно нельзя, на остальных не смотрел.
        modinfo zram
  • 0
    с ядра 3.11 и обычный swap начнёт поддерживать прозрачное сжатие.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.