форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[ Отслеживать ]

"Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."

Сообщение от opennews (??) on 21-Фев-09, 22:57

"Compcache в Linux, сожми свой SWAP (http://itbg.wordpress.com/2009/02/18/compcache-%d0%.../)" - рассказ о Compcache (http://code.google.com/p/compcache/), интересной реализации метода виртуального увеличения фактического объема ОЗУ через хранение раздела подкачки в сжатом виде в области ОЗУ (идея в том, что в сжатый своп влезет больше данных, чем в занимаемую им несжатую память). URL: http://itbg.wordpress.com/2009/02/18/compcache-%d0%.../ Новость: http://www.opennet.me/opennews/art.shtml?num=20405

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."

Сообщение от Аноним (??) on 21-Фев-09, 22:57

Раньше, когда у меня было 512 гигов оперативки, я знал, что такое осуществимо:) И даже как-то размещал своп в XP на сжатом виртуальном RAM-диске...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
	Сообщение от pavlinux (ok) on 21-Фев-09, 23:02
	>Раньше, когда у меня было 512 гигов оперативки, я знал, что такое >осуществимо:) >И даже как-то размещал своп в XP на сжатом виртуальном RAM-диске... Интересно, как это ты в XP сжимал RAM disk, и особенно файл свопа?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
	Сообщение от User294 (ok) on 22-Фев-09, 16:27
	>Интересно, как это ты в XP сжимал RAM disk, и особенно файл >свопа? Форматнув в NTFS и включив сжатие для всего диска? (будет ли по факту сжиматься своп на таком диске я честно гря не знаю и не проверял).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
	Сообщение от pavlinux (ok) on 22-Фев-09, 17:39
	>>Интересно, как это ты в XP сжимал RAM disk, и особенно файл >>свопа? > >Форматнув в NTFS и включив сжатие для всего диска? >(будет ли по факту сжиматься своп на таком диске я честно гря >не знаю и не проверял). Каждый раз при загрузке, а у виндузятников, это по 5 и более раз в день... 1. Создать RAM диск; 2. Форматнуть в NTFS; 3. Сжать; 4. Создать там pagefile.sys Думаю они лучше оперативки прикупят...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "но когда ты докупил до 1 террабайта )))"
	Сообщение от внимательный on 21-Фев-09, 23:48
	Раньше, когда у тебя было 512 гигов оперативки, ты сжимал... но когда ты докупил до 1 террабайта... ))))))) >Раньше, когда у меня было 512 гигов оперативки, я знал, что такое >осуществимо:) >И даже как-то размещал своп в XP на сжатом виртуальном RAM-диске...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."

Сообщение от pavlinux (ok) on 21-Фев-09, 23:00

Минусы: - Два дополнительных модуля. - Занимаемая, ими, RAM память. - Нагрузка на процессор, алгоритмами (де)компрессии. - Не ясно что будет в результате окончания места в RAM и в RAM SWAP. Плюсы: - Куй!

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
	Сообщение от Антон (??) on 21-Фев-09, 23:18
	Еще один минус - аллокатор до последнего будет пытаться не залезть в своп, уменьшая размер буферов, сокращая дисковый кеш. Лучше бы сделали kill, не убивающий, а замораживающий состояние процесса на диск, чтобы потом unkill можно было выполнить с того же места начать работу.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
	Сообщение от User294 (ok) on 22-Фев-09, 16:50
	> Лучше бы сделали kill, не убивающий, а замораживающий состояние процесса на диск Круто, "и пусть весь мир подождет" (c) реклама =).Кстати утилиты делающие такое - есть.Только вот смысла так делать именно в OOM-обработчике не больно много: вы делаете вольное допущение что вскоре полегчает.А оно не обязано нифига - полегчать.Гарантировано то только облегчение ровно на вес убитых при OOM процессов.И ... все!Если они не лезли раньше, wtf они влезут позже?И, кроме того, при OOM пристреливаются наиболее жирные процессы.И если процесс сожрал полтора гига памяти - слив этого добра на диск будет не подарок.В итоге все-равно tcp\ip соединения скорее всего успеют сдохнуть до того как процесс разморозится, а раз так... смысл хранения состояния - невелк (некоторые данные все-равно будут утеряны) а рестарт важных демонов и т.п. уже сегодня сполпинка выполняет тривиальный скрипт сунутый в крон или даже такая штука как демон restartd.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
	Сообщение от Michael Shigorin (ok) on 22-Фев-09, 23:42
	>а рестарт важных демонов и т.п. уже сегодня сполпинка выполняет тривиальный Есть ещё monit (http://mmonit.com), рекомендую.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
	Сообщение от Michael Shigorin (ok) on 22-Фев-09, 19:08
	>Плюсы: Ну вот, опять скоропалительные выводы... compcache вовсю используется в ALT Linux 4.0 Terminal (и Линукс Терминал) в ядре для бездисковых клиентов, обкатывался у нас в офисе и на стедне довольно долго, в итоге принято решение включать автоматически (при 64M RAM отрезается ~22M, например). Для клиники вроде firefox2, kpdf и подобных любителей понасовать в иксы на тонком клиенте неплохо жмущихся xpixmap'ов помогает очень даже.  А на случай, если суют всё равно слишком активно -- там есть сетевой своп и патчик имени Peter Zijlstra от дедлоков при оном.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	17. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
	Сообщение от pavlinux (ok) on 22-Фев-09, 23:44
	>Ну вот, опять скоропалительные выводы... > > в итоге принято решение включать автоматически (при 64M RAM отрезается ~22M, например). Будем считать (RAM - SWAP) + SWAP * log[2](SWAP) - больше уже ТЕОРЕТИЧЕСКИ не выжмешь. RAM > SWAP; Уравнение x - k + k * log[2](k), или для наглядности,  k* ( log[2](k) + x - 1) имеет максимум в точке 2/e ~= 0.7358   Что это объясняет??? То, что при идеальном сжатии, может добавить 73.5% всей виртуальной памяти.   Осталось узнать, какой нужон k для оптимального размера. Пойду ещё косяк забъю...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
	Сообщение от pavlinux (ok) on 23-Фев-09, 00:20
	>Осталось узнать, какой нужон k для оптимального размера. Пойду ещё косяк забью... Мужики, огромные формулы, но k = 1.998326 То есть размер свопа, при ИДЕАЛЬНОМ сжатии, должон быть больше 1.998326008 или меньше 50.04%. Строго. Дальше вот такая горка -  http://s47.radikal.ru/i116/0902/81/c412946273fd.jpg Далее надо проводить расчёты на разницу в нагрузке на процессор, их вычитать из полученного. Затем, выяснить отклонение от идеального сжатия... и сделать поправку на него... ... как мне подсказали, LZO, в среднем может плющить до 36%, с этой поправкой вышло, что ~32% от RAM можно выделять... Если что где не правильно поправляйте...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
	Сообщение от pavlinux (ok) on 23-Фев-09, 00:32
	>Затем, выяснить отклонение от идеального сжатия... и сделать поправку на него... Думается эта поправка будет влиять в основном на скорость работы... Вывод: Допустимые пределы использования этой шняги от 32% до 45%  от всей RAM !!! Верхний предел определите сами, сплющив 1.000.000 байт из /var/lib/dict/words или dd if=/dev/zero :) И самый интересный вывод: Вам надо просто добавить треть имеющейся у Вас оперативки!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	30. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
	Сообщение от Michael Shigorin (ok) on 23-Фев-09, 23:51
	>Затем, выяснить отклонение от идеального сжатия... и сделать поправку на него... Говорю же -- пиксмапы там рыхлые, что-то ~50% долетающего до свопа за неделю-две сжималось на том терминале вдвое (Good), а процентов 10--20 так даже и больше (VeryGood -- коллега специально допатчил статистику, ему интересно было). А, даже вот: http://article.gmane.org/gmane.linux.terminal-server.devel/970
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	32. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
	Сообщение от pavlinux (ok) on 24-Фев-09, 01:58
	>>Затем, выяснить отклонение от идеального сжатия... и сделать поправку на него... > >Говорю же -- пиксмапы там рыхлые, что-то ~50% долетающего до свопа за >неделю-две сжималось на том терминале вдвое (Good), а процентов 10--20 так >даже и больше (VeryGood -- коллега специально допатчил статистику, ему интересно >было). > >А, даже вот: http://article.gmane.org/gmane.linux.terminal-server.devel/970 :) amd64:/home/pavel # cat /proc/compcache DiskSize:        1375844 kB NumReads:              1 NumWrites:             0 FailedReads:           0 FailedWrites:          0 InvalidIO:             0 PagesDiscard:          0 GoodCompress:          0 % NoCompress:            0 % PagesStored:           0 PagesUsed:             0 OrigDataSize:          0 kB ComprDataSize:         0 kB MemUsed:               0 kB amd64:/home/pavel # w 01:57:08 up 12:26,  0 users,  load average: 0,21, 0,53, 0,64 USER     TTY        LOGIN@   IDLE   JCPU   PCPU WHAT amd64:/home/pavel # free              total       used       free     shared    buffers     cached Mem:       4127528    3427220     700308          0          0    2185340 -/+ buffers/cache:    1241880    2885648 Swap:      1375840         44    1375796
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."

Сообщение от Аноним (??) on 21-Фев-09, 23:28

Господа теоретики, я только что сие попробовал. И стало гораздо лучше, по крайней мере на первый взгляд. После охочей до памяти игрушки под вайном, FF больше не хрустит диском по несколько минут. Тормозов в игрушке не замечено, памяти в системе - 768 Мб. Расширить трудно и дорого ибо ноутбук.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
	Сообщение от Аноним (??) on 22-Фев-09, 12:10
	можно еще флешку подцепить свопом.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
	Сообщение от Анонимус2 on 22-Фев-09, 17:12
	>можно еще флешку подцепить свопом. это ты из висты узнал?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	26. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
	Сообщение от Анонимус3 on 23-Фев-09, 17:25
	mount /media/sda1 cd /media/sda1 mkdir tmp dd if=/dev/zero of=/media/sda1/tmp/swapfile bs=1024 count=65536 mkswap /media/sda1/tmp/swapfile swapon /media/sda1/tmp/swapfile PS: man dd, man mkswap, man swapon, man swapoff
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	27. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
	Сообщение от pavlinux (ok) on 23-Фев-09, 19:23
	А не торрент/peer2peer/emule слабо свопу посадить??? Пущай по планете свопиться...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	31. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
	Сообщение от Michael Shigorin (ok) on 24-Фев-09, 00:01
	>dd if=/dev/zero of=/media/sda1/tmp/swapfile bs=1024 count=65536 >PS: man dd, man mkswap, man swapon, man swapoff man что, чтоб примитивный wear leveling в этом sda1 не угробил флэшку по модулю 12 к вечеру?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."

Сообщение от Илья (??) on 22-Фев-09, 00:22

Для сомневающихся в статье есть тесты, которые показывают прирост производительности, а теоретические выводе в посте выше ничем не подкреплены и основываются лишь на догатках. И кто Вам мешает добавить ещё один SWAP раздел?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

15. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."

Сообщение от iZEN (ok) on 22-Фев-09, 23:33

>"Compcache в Linux, сожми свой SWAP (http://itbg.wordpress.com/2009/02/18/compcache-%d0%.../)" - рассказ о Compcache (http://code.google.com/p/compcache/), >интересной реализации метода виртуального увеличения фактического объема ОЗУ через хранение раздела >подкачки в сжатом виде в области ОЗУ (идея в том, что >в сжатый своп влезет больше данных, чем в занимаемую им несжатую >память). Давно известно, что Linux даже при избытке свободного ОЗУ использует SWAP-раздел пусть даже на 5..10% от его объёма. Аллокатор памяти в Linux настолько самокритичен, что не позволяет как в FreeBSD всё "до последнего" держать в ОЗУ. Одна из причин такого положения -- неэффективность реализации транзакционности основной файловой системы Ext3, требующая использования SWAP для ведения журнала метаданных. Задействование SWAP при наличие свободного ОЗУ -- симптом "болезни". Использование RAM-диска для SWAP (пусть и сжатого) -- "лечение" болезни анестетиками.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
	Сообщение от pavlinux (ok) on 23-Фев-09, 00:43
	>неэффективность Ext3, требующая использования SWAP для ведения журнала метаданных. > >Задействование SWAP при наличие свободного ОЗУ -- симптом "болезни". >Использование RAM-диска для SWAP (пусть и сжатого) -- "лечение" болезни анестетиками. 1. Не юзать ext3 2. sysctl -w vm.swappiness = 0 3. # CONFIG_SWAP is not set
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	21. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
	Сообщение от Аноним (??) on 23-Фев-09, 02:53
	>Давно известно, что Linux даже при избытке свободного ОЗУ использует SWAP-раздел пусть >даже на 5..10% от его объёма. Враньё и провокация. "swap used: 0", что я делаю не так?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	23. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
	Сообщение от iZEN (ok) on 23-Фев-09, 12:10
	>>Давно известно, что Linux даже при избытке свободного ОЗУ использует SWAP-раздел пусть >>даже на 5..10% от его объёма. > >Враньё и провокация. "swap used: 0", что я делаю не так? Ты ничего не делаешь.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	24. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
	Сообщение от Lindemidux (??) on 23-Фев-09, 12:40
	>>>Давно известно, что Linux даже при избытке свободного ОЗУ использует SWAP-раздел пусть >>>даже на 5..10% от его объёма. >> >>Враньё и провокация. "swap used: 0", что я делаю не так? > >Ты ничего не делаешь. Додик iZen почему у меня начинает работать свап только при заполнении памяти свыше 80%?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	29. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
	Сообщение от Michael Shigorin (ok) on 23-Фев-09, 23:42
	>>>Давно известно, что Linux даже при избытке свободного ОЗУ использует SWAP-раздел >>пусть даже на 5..10% от его объёма. >>Враньё и провокация. "swap used: 0", что я делаю не так? >Ты ничего не делаешь. Врёте.  Бук под руками: pad:~> df -Th | egrep -v '^Filesystem|tmpfs|ext3' pad:~> free              total       used       free     shared    buffers     cached Mem:       1554916    1489184      65732          0     204208    1148428 -/+ buffers/cache:     136548    1418368 Swap:      2096440          0    2096440 pad:~> PS: свопа столько -- барахлишко в tmpfs собирать.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	28. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
	Сообщение от Michael Shigorin (ok) on 23-Фев-09, 23:38
	>Задействование SWAP при наличие свободного ОЗУ -- симптом "болезни". Вы это IBM с их AIX расскажите, мож на работу примут.  Если в двери головой пройдёте, конечно. А если всё-таки подумать ещё -- то простаивающая память есть выкинутые деньги, и память, забитая неделю не использовавшимся барахлом -- я вот тоже склонен считать простаивающей.  Пусть в свопе полежит. Искренне надеюсь, что в следующий раз сперва немного поизучаете тематику, а потом будете обсуждать VM.  Можете вот по kerneltrap.org полазить, чтоб не говорить глупости времён Linux 2.2 примерно.  Причём как отмечено выше -- такое понимание необязательно линукс-специфично.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

22. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."

Сообщение от Nexor on 23-Фев-09, 09:26

По поводу NTFS в винде. А кто нить вообще в курсе что там за сжатие? Отвечаю: полный примитив, который объединяет идущие подряд 1 или 0... как понимаете сжатием это названо для галочки

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	25. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
	Сообщение от none (??) on 23-Фев-09, 16:34
	>По поводу NTFS в винде. А кто нить вообще в курсе что >там за сжатие? Отвечаю: полный примитив, который объединяет идущие подряд 1 >или 0... как понимаете сжатием это названо для галочки а тебе 7zip нужен? ты бы потестил для начала насколько это сжатие реально эффективно на кучи тхт-шек, а потом уже говорил: "для галочки"
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]