LINUX.ORG.RU

Не пойму как работает zRam

 , ,


6

3

Запустил zRam на ядре 3.2, из 8 гигов отдал 4х1.5 = 6, подключил свапом (дисковый отключил для чистоты эксперимента). Но я все равно вижу 8 гигов оперативы и 6 гигов нового свапа. Запускаю несколько виртуалок, когда они заполняют память до 8 гб, комп виснет (иногда обратимо, когда одна виртуалка падает). Пробовал разные значения swappiness. Судя по данным proc степень сжатия колеблется от 2 до 3. В сислоге только записи о запуске, т.е. все должно работать. Но я этого не ощущаю.

★★★★★

Ответ на: комментарий от fragmentor

Про zRam гуглится много статей, отзывов, есть готовые скрипты запуска, у народа отличаются цифры степени сжатия, ну и стабильность системы. А чтобы вот так просто не работал я нигде не читал. Поэтому я и сомневаюсь, правильно ли я вообще понимаю фичу.

Вот например, доступная оператива должна уменьшится после загрузки модуля или нет?

Lordwind ★★★★★
() автор топика
Ответ на: комментарий от Lordwind

Делал тест zram — абсолютно аналогичное поведение. На тему подписался.

feofan ★★★★★
()
Ответ на: комментарий от Lordwind

А почему она должна уменьшаться?

anonymous
()
Ответ на: комментарий от fragmentor

zram глючный, пользуйся zcache.

Бугатти Вейрон глючный, пользуйся Белазом.

zRam и zcache - абсолютно разные сущности.

server ~ # swapon -s
Filename                                Type            Size    Used    Priority
/dev/sda2                               partition       4194300 0       -1
/dev/zram0                              partition       2097148 599308  16383

У меня работает и неплохо.

// А вообще, для виртуалок попробуй uKSM вместе с transparent hugepage - профит более чем серьезный будет.

devl547 ★★★★★
()
Последнее исправление: devl547 (всего исправлений: 2)
Ответ на: комментарий от devl547

Чем тогда zRam проверить? Хром чтоли покормить?

Lordwind ★★★★★
() автор топика
Ответ на: комментарий от fragmentor

У меня такой:

#! /bin/bash
CPUS=`grep /proc/cpuinfo -e processor --count`
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

Lordwind ★★★★★
() автор топика

Поставил ядро 3.9, поведение аналогичное

Lordwind ★★★★★
() автор топика
Ответ на: комментарий от AEP

сейчас я вернул дисковый свап (4 гига) и отдал половину памяти на сжатие, итого 8

            total       used       free     shared    buffers     cached
Mem:       8128512    7832744     295768          0      79468    6325424
-/+ buffers/cache:    1427852    6700660
Swap:      8258540          0    8258540

Lordwind ★★★★★
() автор топика
Ответ на: комментарий от Lordwind

Ну собственно видно, что своп не используется. Интересует как раз ситуация, когда zram-своп начинает использоваться.

AEP ★★★★★
()
Ответ на: комментарий от AEP

Щас заполнил виртуалками и браузерами память до 6.5 из 8 (это хорошо соответствует реальным юзкейсам):

/dev/zram0                              partition	1016060	5728	100
/dev/zram1                              partition	1016060	5728	100
/dev/zram2                              partition	1016060	5732	100
/dev/zram3                              partition	1016060	5732	100
/dev/sda4                               partition	4194300	0	-1

Compression ratio of zram0: 4.896 net, 2.451 gross.
Compression ratio of zram1: 4.861 net, 2.563 gross.
Compression ratio of zram2: 4.941 net, 2.614 gross.
Compression ratio of zram3: 4.774 net, 2.507 gross.

             total       used       free     shared    buffers     cached
Mem:       8128512    8003040     125472          0       3464    1157068
-/+ buffers/cache:    6842508    1286004
Swap:      8258540      24072    8234468

Lordwind ★★★★★
() автор топика
Последнее исправление: Lordwind (всего исправлений: 1)
Ответ на: комментарий от Lordwind

Вроде работает, причем приоритеты выставлены правильно. Осталось проверить, что при вызове swapon на zram используется ключ -d, иначе zram не отдаст обратно память, которая больше не используется под swap (например, после того, как попользовались чем-то большим и закрыли).

Отмечу еще, что совместное использование zram и традиционного swap'а не рекомендуется. Проблема такая: после того, как zram заполнится, он будет просто лежать мертвым грузом в памяти. Т.е. будем иметь не систему с 8 GB RAM и дисковым свопом, а систему с 8-X GB RAM (где X съел zram) и дисковым свопом.

AEP ★★★★★
()
Ответ на: комментарий от AEP

т.е. будем иметь не систему с 8 GB RAM и дисковым свопом, а систему с 8-X GB RAM (где X съел zram) и дисковым свопом

Вот у меня сейчас поведение системы говорит о том, что zRam или гонит насчет компрессии (т.е. забирает себе память 1:1) или тупо не работает. Потому что при заполнении ровно 8 гигов приходит поручик OOM Killer, а дальше как повезет. Пробовал отдавать на zRam 50, 75 и 100% памяти. В последнем случае, раз zRam смонтирован как свап, он должен сразу заполняться или что-то показывать. Swapiness, к слову, у меня варьируется от 80 до 100.

Lordwind ★★★★★
() автор топика
Ответ на: комментарий от Lordwind

А как определяется заполнение ровно 8 GB? Есть подозрение, что память, занятая zram, входит в последнюю цифру. Тогда неудивительно - как только сумма сжатого размера данных в zram и размера данных, не попавших в zram, составит 8 GB, придет OOM.

И вообще говорить о том, что какой-то процент памяти отдан zram'у, неправильно. zram эмулирует блочное устройство заданного _несжатого_ размера и в каждый момент занимает столько памяти, сколько записанная в него информация занимает в сжатом виде. Т.е. в начальный момент - нисколько. И если ты уверен, что данные сожмутся в 2 раза, можешь смело делать устройство на 16 GB (т.е. в твоем понимании 200% памяти).

AEP ★★★★★
()
Ответ на: комментарий от Lordwind

Вот кстати более объективный способ заполнения памяти. Запусти python-2.7 и в интерактивном режиме выполни такие строки:

# специально подобрано, чтобы сжималось не слишком хорошо и не слишком плохо
gzippable = ''.join([chr((185 + x * (x + 5) * (x % 10 + 1)) % 256) for x in xrange(4096)])
fatpig = gzippable * 1000000

скушает 1000000 страниц по 4 КБ

Посмотри, сколько страниц сможешь загнать в fatpig до OOM'а без zram'а и с ним.

AEP ★★★★★
()
Ответ на: комментарий от AEP

Отдал zRam'у 100% памяти, поставил swappiness 100, запустил скрипт в расчете на 6 Гб, еще 1.5 Гб занимали браузеры и система. В итоге картина почти аналогичная, в свап почти ничего не попало, но до OOM я решил не доводить пока (подстраховался дисковым свапом). Питон занял 5.8 Гб. Но вот стоило покормить фаербаг, свап начал медленно расти. Потом запустил тощую виртуалку на 0.5 Гб. Итоговая память у меня так и осталась колебаться около 94-96% (7.5 из 8.0), а питон с 5.8 ужался до 4.6. Запустил еще виртуалку на 1.0, питон сдулся до 3.5. Итого получилась такая картина маслом:

Filename				Type		Size	Used	Priority
/dev/zram0                              partition	2032124	768512	100
/dev/zram1                              partition	2032124	768436	100
/dev/zram2                              partition	2032124	768396	100
/dev/zram3                              partition	2032124	768300	100
/dev/sda4                               partition	4194300	8	-1

             total       used       free     shared    buffers     cached
Mem:       8128512    7865720     262792          0       2124     166236
-/+ buffers/cache:    7697360     431152
Swap:     12322796    3073652    9249144
Compression ratio of zram0: 2.699 net, 2.555 gross.
Compression ratio of zram1: 2.698 net, 2.554 gross.
Compression ratio of zram2: 2.697 net, 2.553 gross.
Compression ratio of zram3: 2.699 net, 2.554 gross.

Напрашивается вывод, что для zRam можно смело ставить swappiness 100, а виртуалки хреново сжимаются.

Lordwind ★★★★★
() автор топика
Последнее исправление: Lordwind (всего исправлений: 3)

Не работает у тебя zram. Посмотрел, на бунте для тошибы АС100 зрам по умолчанию. Виден, как своп 216 mb, при этом соответсвенно mem 433mb.

kraftello ★★★★★
()

Провел контрольный эксперимент на виртуалке (ubuntu 13.04, ядро 3.8), все указывает на то, что zRam работает, но фишка именно в сжимаемости данных. Например я отключил весь свап, свободно было 750 из 1000 Мб памяти, питоном заполнил 700, запустил браузер и система встала колом, потом отдал всю память на сжатие (дописав swapon -d, в скрипте из репа этого параметра нет), питону скормил 1000, запустил браузер и страницы довольно бодро открывались, питон усох. Вот что получил в итоге:

		Current		Predicted
Original:	701M		1002M
Compressed:	192M
Total mem use:	212M		304M
Saved:		488M		698M
Ratio:		30%	(27%)

Physical RAM:	1002M
Effective RAM:	1491M		(1701M)
             total       used       free     shared    buffers     cached
Память:       1,0G       889M       112M         0B       1,2M        43M
-/+ буферы/кэш:       844M       158M
Swap:         1,0G       706M       296M
Filename				Type		Size	Used	Priority
/dev/zram0                              partition	1026752	723512	100

Возможно я получил плохое сжатие из-за использования VirtualBox, с KVM может будет иная картина. Хорошо что браузеры (особенно 64 бит, в указателях больше нулей) сжимаются, фаербаги всякие и продукты их жизнедеятельности. Основные вопросы выяснил, всем спасибо.

Lordwind ★★★★★
() автор топика
Ответ на: комментарий от Lordwind

Я сегодня тестил на нетбуке. Там 2 гига оперативы. Сделал Swappines 60, и 2 диска zram каждый по 1 гигу. В итоге получил, что было занято 1700 обычной оперативы и 1600 ZRAM. Был момент когда дошло до 1900 в оперативе и 1900 в ZRAM но там я запускал Firefox и все подвисло...спас sysrq вызов на очистку. В общем как я понимаю, можно ставить ZRAM даже больше памяти. Эдак в полтора раза. Т.е. память будет 2 гига, а своп 3. И учитывая что сжатие ниже 30% обычно не падает все должно работать стабильно. На некоторых ресурсах получал цифру, что человек ужимал в 3 раза. Это видимо у него в оперативе был браузер, который отлично жмется.

Bupyc ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.