Многократно увеличиваем память

domov0y	# 11 лет, 1 месяц назад
Темы: 5 Сообщения: 819 Участник с: 09 июля 2011	ivand, не скажи. если правильно все организовать, можно получить больший прирост производительности чем от свапа на ssd (прекрасно понимаю что это явное убийство накопителя). сама идея шикарна. ram во много раз быстрее чем ssd или винт. Если удалось быстро и качественно сжать данные то более менее адекватный компьютер (считаем что ядер должно быть заведомо больше одного) будет обгонять такой же компьютер но со свапом на ssd. хотя возможна ситуация когда будет и заведомый проигрыш в скорости. (данные не сжимаемы или когда компьютер с ZRAM уже начал свапить а второй еще нет) Да пребудет с вами знание ip адреса

# 11 лет, 1 месяц назад

Сообщения: 819

Участник с: 09 июля 2011

ivand, не скажи. если правильно все организовать, можно получить больший прирост производительности чем от свапа на ssd (прекрасно понимаю что это явное убийство накопителя). сама идея шикарна. ram во много раз быстрее чем ssd или винт. Если удалось быстро и качественно сжать данные то более менее адекватный компьютер (считаем что ядер должно быть заведомо больше одного) будет обгонять такой же компьютер но со свапом на ssd. хотя возможна ситуация когда будет и заведомый проигрыш в скорости. (данные не сжимаемы или когда компьютер с ZRAM уже начал свапить а второй еще нет)

Да пребудет с вами знание ip адреса

ivand	# 11 лет, 1 месяц назад
Темы: 9 Сообщения: 477 Участник с: 04 января 2013	Так то оно так: на squashfs еще значительный прирост показан на сжатиях usr Вот ключевое- Если удалось быстро и качественно сжать данные то более менее адекватный компьютер (считаем что ядер должно быть заведомо больше одного) будет обгонять такой же компьютер но со свапом На 133 мгц сомнительно- усвописси, дряхлые мы с ним.

ivand

# 11 лет, 1 месяц назад

Темы: 9

Сообщения: 477

Участник с: 04 января 2013

Так то оно так: на squashfs еще значительный прирост показан на сжатиях usr
Вот ключевое-
Если удалось быстро и качественно сжать данные то более менее адекватный компьютер (считаем что ядер должно быть заведомо больше одного) будет обгонять такой же компьютер но со свапом
На 133 мгц сомнительно- усвописси, дряхлые мы с ним.

domov0y	# 11 лет, 1 месяц назад
Темы: 5 Сообщения: 819 Участник с: 09 июля 2011	тут я увы полностью согласен. на меньше чем 3*128 мб рамы +P3 такое чудо будет почти бесполезно. Слишком уж прожорлив нынешний софт до памяти. хотя по чтению записи оно наверное сможет потягаться со свапом на жестком диске. Но не более того. Да пребудет с вами знание ip адреса

domov0y

# 11 лет, 1 месяц назад

Темы: 5

Сообщения: 819

Участник с: 09 июля 2011

тут я увы полностью согласен. на меньше чем 3*128 мб рамы +P3 такое чудо будет почти бесполезно. Слишком уж прожорлив нынешний софт до памяти. хотя по чтению записи оно наверное сможет потягаться со свапом на жестком диске. Но не более того.

Да пребудет с вами знание ip адреса

cucullus	# 11 лет, 1 месяц назад
Темы: 266 Сообщения: 3541 Участник с: 06 июня 2007	firefoxic cucullus этот zram на словах действительно хорош, а вот как до дела доходит, всё колом встаёт. ;) Что конкретно у вас колом встало? Можно поподробнее? система, что ещё... начинаются сначала просто тормоза, потом вечный своп. на длительном аптайме. на паре машин проверено. такие дела.

cucullus

# 11 лет, 1 месяц назад

Темы: 266

Сообщения: 3541

Участник с: 06 июня 2007

firefoxic
cucullus
этот zram на словах действительно хорош, а вот как до дела доходит, всё колом встаёт. ;)
Что конкретно у вас колом встало? Можно поподробнее?

система, что ещё... начинаются сначала просто тормоза, потом вечный своп. на длительном аптайме.
на паре машин проверено.

такие дела.

akorop	# 11 лет, 1 месяц назад
Темы: 111 Сообщения: 1756 Участник с: 29 февраля 2012	domov0y тут я увы полностью согласен. на меньше чем 3128 мб рамы +P3 такое чудо будет почти бесполезно. Слишком уж прожорлив нынешний софт до памяти. хотя по чтению записи оно наверное сможет потягаться со свапом на жестком диске. Но не более того. А при чём тут именно нынешний* софт, равно как и многоядерные процессоры? Это ж вечнозелёная идея, и софт был всегда прожорлив до современной ему памяти, и память была всегда быстрее, чем любой внешний носитель. Ещё во времен ДОС и Windows 3 (не Win NT 3, а просто Win 3 - это было до Windows 95) была утилита MagnaRam с практически таким же подходом - часть памяти отводилось под сжатый "своп". А в OS/2 сжатый промежуточный буфер был частью штатного функционирования системной системы свопинга, и, кстати, в физический своп данные, если и записывались, то сжатые (что уменьшало обмен с винтом).

akorop

# 11 лет, 1 месяц назад

Темы: 111

Сообщения: 1756

Участник с: 29 февраля 2012

domov0y
тут я увы полностью согласен. на меньше чем 3*128 мб рамы +P3 такое чудо будет почти бесполезно. Слишком уж прожорлив нынешний софт до памяти. хотя по чтению записи оно наверное сможет потягаться со свапом на жестком диске. Но не более того.

А при чём тут именно нынешний софт, равно как и многоядерные процессоры?
Это ж вечнозелёная идея, и софт был всегда прожорлив до современной ему памяти, и память была всегда быстрее, чем любой внешний носитель. Ещё во времен ДОС и Windows 3 (не Win NT 3, а просто Win 3 - это было до Windows 95) была утилита MagnaRam с практически таким же подходом - часть памяти отводилось под сжатый "своп". А в OS/2 сжатый промежуточный буфер был частью штатного функционирования системной системы свопинга, и, кстати, в физический своп данные, если и записывались, то сжатые (что уменьшало обмен с винтом).

domov0y	# 11 лет, 1 месяц назад
Темы: 5 Сообщения: 819 Участник с: 09 июля 2011	как при чем? считаем что дано <=256 мб памяти и пень два. отводим 64 мб под ядро окружение и Х. Пытаемся запустить ООО и еще что нибудь не страшное но среднепрожорливое типа лисы и хрома. Внезапно оказывается что система "ерзает" между свапом и очень маленьким кусочком не вытесненной свапом оперативной памяти, расходуя часть ресурса процессора на постоянную распаковку и вытаскивание из свапа. вот как то так. Да пребудет с вами знание ip адреса

domov0y

# 11 лет, 1 месяц назад

Темы: 5

Сообщения: 819

Участник с: 09 июля 2011

как при чем? считаем что дано <=256 мб памяти и пень два. отводим 64 мб под ядро окружение и Х. Пытаемся запустить ООО и еще что нибудь не страшное но среднепрожорливое типа лисы и хрома. Внезапно оказывается что система "ерзает" между свапом и очень маленьким кусочком не вытесненной свапом оперативной памяти, расходуя часть ресурса процессора на постоянную распаковку и вытаскивание из свапа. вот как то так.

Да пребудет с вами знание ip адреса

red	# 11 лет назад
Темы: 30 Сообщения: 1517 Участник с: 31 августа 2011	Давайте разберёмся с преамбулой firefoxic Но иногда, например во время компиляции из AUR чего-то большого, возникают-таки проблемы из-за нехватки памяти. я так понял это описана одна из проблем которая решается если использовать zram, то есть когда что то большое компилится и идёт переполнение /tmp который находится в tmpfs(грубо говоря в оперативке). Итак, имеется одноядерный нетбук с установленным на нём Arch x86_64. Имеется 4г рамы, из которых 256м использует видеокарта. Свопа на диске не создавал. Cистема и запущенные приложения отжирают порядка 1г, под /tmp в озу выделено 2г(максимум который она может занимать), zramswap создал 1 своп порядка 3.6г. Так вот, при компилировании приложения из АУР йогурт вылетает с ошибкой переполнения память когда /tmp начинает превышать порог в 2г, при этом swap не превышает 1 метра. Свободной память остаётся несколько сотен метров. Кто нибуть сталкивался с таким ? И как это побороть ? чтобы система всё же использовала своп когда /tmp заполнится к примеру на 80% ----------------------- и на последок firefoxic Более того, я в tmpfs помимо дефолтного /tmp закинул ещё и /var/tmp и ~/.cache. по поводу /var/tmp это вы зря из англоязычной вики по fstab "Do NOT use it on /var/tmp, because that folder is meant for temporary files that are preserved across reboots."

red

# 11 лет назад

Темы: 30

Сообщения: 1517

Участник с: 31 августа 2011

Давайте разберёмся с преамбулой

firefoxic
Но иногда, например во время компиляции из AUR чего-то большого, возникают-таки проблемы из-за нехватки памяти.

я так понял это описана одна из проблем которая решается если использовать zram, то есть когда что то большое компилится и идёт переполнение /tmp который находится в tmpfs(грубо говоря в оперативке).

Итак, имеется одноядерный нетбук с установленным на нём Arch x86_64.
Имеется 4г рамы, из которых 256м использует видеокарта. Свопа на диске не создавал.
Cистема и запущенные приложения отжирают порядка 1г, под /tmp в озу выделено 2г(максимум который она может занимать),
zramswap создал 1 своп порядка 3.6г.
Так вот, при компилировании приложения из АУР йогурт вылетает с ошибкой переполнения память когда /tmp начинает превышать порог в 2г, при этом swap не превышает 1 метра. Свободной память остаётся несколько сотен метров.
Кто нибуть сталкивался с таким ? И как это побороть ?
чтобы система всё же использовала своп когда /tmp заполнится к примеру на 80%
-----------------------
и на последок

firefoxic
Более того, я в tmpfs помимо дефолтного /tmp закинул ещё и /var/tmp и ~/.cache.

по поводу /var/tmp это вы зря
из англоязычной вики по fstab
"Do NOT use it on /var/tmp, because that folder is meant for temporary files that are preserved across reboots."

nafanja	# 11 лет назад
Темы: 94 Сообщения: 9252 Участник с: 02 июня 2012 заблокирован	red Попробуй сделать /tmp не 2г а 4г. Псевдографический инсталлятор Arch Linux ver. 3.8.2 Благодарности принимаются на ЯД 410012815723874

red	# 11 лет назад
Темы: 30 Сообщения: 1517 Участник с: 31 августа 2011	итак, в начале перед компилингом(yaourt -S wine-mono) имеем такую ситуацию: $date +%X && df -hT /tmp && echo && free -h 14:47:33 Файловая система Тип Размер Использовано Дост Использовано% Cмонтировано в tmpfs tmpfs 4,0G 4,0K 4,0G 1% /tmp total used free shared buffers cached Mem: 3,6G 997M 2,6G 0B 41M 290M -/+ buffers/cache: 664M 3,0G Swap: 3,6G 0B 3,6G где то за 10 минут до конца: 16:57:52 Файловая система Тип Размер Использовано Дост Использовано% Cмонтировано в tmpfs tmpfs 4,0G 2,0G 2,1G 49% /tmp total used free shared buffers cached Mem: 3,6G 3,4G 274M 0B 60M 2,4G -/+ buffers/cache: 930M 2,7G Swap: 3,6G 0B 3,6G в конце: 17:07:30 Файловая система Тип Размер Использовано Дост Использовано% Cмонтировано в tmpfs tmpfs 4,0G 2,4G 1,7G 59% /tmp total used free shared buffers cached Mem: 3,6G 3,5G 165M 0B 13M 2,5G -/+ buffers/cache: 1,0G 2,6G Swap: 3,6G 84M 3,5G при этом в /etc/sysctl.conf выставлен параметр vm.swappiness = 50(по идее при заполнении озу более чем на 50% должен начинать юзатся своп) в данном случае хоть прога и скомпилилась здесь явно не заслуга zramswap, если бы проге понадобилось 3-4г для компиляции в /tmp то всё бы закончилось весьма плачевно. /tmp в tmpfs как видно расширяется за счёт кеша(cached в команде free) что не учитывается zramswap память выбрасывается в своп относительно приложений(строчка -/+ buffers/cache в команде free) а не самой системы(где надо учитывать buffers и cached) тоесть надо заставить как то свопится сам кеш а не программы при достиженни определённого уровня

red

# 11 лет назад

Темы: 30

Сообщения: 1517

Участник с: 31 августа 2011

итак, в начале перед компилингом(yaourt -S wine-mono) имеем такую ситуацию:

$date +%X && df -hT /tmp && echo && free -h
14:47:33
Файловая система Тип   Размер Использовано  Дост Использовано% Cмонтировано в
tmpfs            tmpfs   4,0G         4,0K  4,0G            1% /tmp
             total       used       free     shared    buffers     cached
Mem:          3,6G       997M       2,6G         0B        41M       290M
-/+ buffers/cache:       664M       3,0G
Swap:         3,6G         0B       3,6G

где то за 10 минут до конца:

16:57:52
Файловая система Тип   Размер Использовано  Дост Использовано% Cмонтировано в
tmpfs            tmpfs   4,0G         2,0G  2,1G           49% /tmp
             total       used       free     shared    buffers     cached
Mem:          3,6G       3,4G       274M         0B        60M       2,4G
-/+ buffers/cache:       930M       2,7G
Swap:         3,6G         0B       3,6G

в конце:

17:07:30
Файловая система Тип   Размер Использовано  Дост Использовано% Cмонтировано в
tmpfs            tmpfs   4,0G         2,4G  1,7G           59% /tmp
             total       used       free     shared    buffers     cached
Mem:          3,6G       3,5G       165M         0B        13M       2,5G
-/+ buffers/cache:       1,0G       2,6G
Swap:         3,6G        84M       3,5G

при этом в /etc/sysctl.conf выставлен параметр vm.swappiness = 50(по идее при заполнении озу более чем на 50% должен начинать юзатся своп)

в данном случае хоть прога и скомпилилась здесь явно не заслуга zramswap, если бы проге понадобилось 3-4г для компиляции в /tmp то всё бы закончилось весьма плачевно.

/tmp в tmpfs как видно расширяется за счёт кеша(cached в команде free) что не учитывается zramswap
память выбрасывается в своп относительно приложений(строчка -/+ buffers/cache в команде free) а не самой системы(где надо учитывать buffers и cached)

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

nafanja	# 11 лет назад
Темы: 94 Сообщения: 9252 Участник с: 02 июня 2012 заблокирован	Как мне кажется для правильной проверки нужно создать такую ситуацию когда памяти явно не будет хватать для работы без любого свапа. А уж потом включить zramswap и проделать тоже самое. red, если ты уж задался таким вопросом то попробуй временно убрать 2G оперативы, если конечно это возможно. Думаю задача что была приведена выше с 2G оперативы и без свапа не будет успашно завершена (нужно проверить), а с zramswap все получится (соответственно память взялась "из ниоткуда") Псевдографический инсталлятор Arch Linux ver. 3.8.2 Благодарности принимаются на ЯД 410012815723874

nafanja

# 11 лет назад

Темы: 94

Сообщения: 9252

Участник с: 02 июня 2012

заблокирован

Как мне кажется для правильной проверки нужно создать такую ситуацию когда памяти явно не будет хватать для работы без любого свапа.
А уж потом включить zramswap и проделать тоже самое.

red, если ты уж задался таким вопросом то попробуй временно убрать 2G оперативы, если конечно это возможно.
Думаю задача что была приведена выше с 2G оперативы и без свапа не будет успашно завершена (нужно проверить), а с zramswap все получится (соответственно память взялась "из ниоткуда")

Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874