The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (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.ru/opennews/art.shtml?num=20405

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

 Оглавление

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

1. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."  
Сообщение от Аноним (??) on 21-Фев-09, 22:57 
Раньше, когда у меня было 512 гигов оперативки, я знал, что такое осуществимо:)
И даже как-то размещал своп в XP на сжатом виртуальном RAM-диске...
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

2. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."  
Сообщение от pavlinux email(ok) on 21-Фев-09, 23:00 
Минусы:

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

Плюсы:

- Куй!



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

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

Интересно, как это ты в XP сжимал RAM disk, и особенно файл свопа?  

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

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

Лучше бы сделали kill, не убивающий, а замораживающий состояние процесса на диск, чтобы потом unkill можно было выполнить с того же места начать работу.

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

5. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."  
Сообщение от Аноним (??) on 21-Фев-09, 23:28 
Господа теоретики, я только что сие попробовал. И стало гораздо лучше, по крайней мере на первый взгляд.

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

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

6. "но когда ты докупил до 1 террабайта )))"  
Сообщение от внимательный on 21-Фев-09, 23:48 
Раньше, когда у тебя было 512 гигов оперативки, ты сжимал... но когда ты докупил до 1 террабайта... )))))))

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

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

7. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."  
Сообщение от Илья email(??) on 22-Фев-09, 00:22 
Для сомневающихся в статье есть тесты, которые показывают прирост производительности, а теоретические выводе в посте выше ничем не подкреплены и основываются лишь на догатках.
И кто Вам мешает добавить ещё один SWAP раздел?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

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

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

Форматнув в NTFS и включив сжатие для всего диска?
(будет ли по факту сжиматься своп на таком диске я честно гря не знаю и не проверял).

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

11. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."  
Сообщение от User294 (ok) on 22-Фев-09, 16:50 
> Лучше бы сделали kill, не убивающий, а замораживающий состояние процесса на диск

Круто, "и пусть весь мир подождет" (c) реклама =).Кстати утилиты делающие такое - есть.Только вот смысла так делать именно в OOM-обработчике не больно много: вы делаете вольное допущение что вскоре полегчает.А оно не обязано нифига - полегчать.Гарантировано то только облегчение ровно на вес убитых при OOM процессов.И ... все!Если они не лезли раньше, wtf они влезут позже?И, кроме того, при OOM пристреливаются наиболее жирные процессы.И если процесс сожрал полтора гига памяти - слив этого добра на диск будет не подарок.В итоге все-равно tcp\ip соединения скорее всего успеют сдохнуть до того как процесс разморозится, а раз так... смысл хранения состояния - невелк (некоторые данные все-равно будут утеряны) а рестарт важных демонов и т.п. уже сегодня сполпинка выполняет тривиальный скрипт сунутый в крон или даже такая штука как демон restartd.

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

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

это ты из висты узнал?

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

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

Каждый раз при загрузке, а у виндузятников, это по 5 и более раз в день...

1. Создать RAM диск;
2. Форматнуть в NTFS;
3. Сжать;
4. Создать там pagefile.sys


Думаю они лучше оперативки прикупят...

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

14. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."  
Сообщение от Michael Shigorin email(ok) on 22-Фев-09, 19:08 
>Плюсы:

Ну вот, опять скоропалительные выводы...

compcache вовсю используется в ALT Linux 4.0 Terminal (и Линукс Терминал) в ядре для бездисковых клиентов, обкатывался у нас в офисе и на стедне довольно долго, в итоге принято решение включать автоматически (при 64M RAM отрезается ~22M, например).

Для клиники вроде firefox2, kpdf и подобных любителей понасовать в иксы на тонком клиенте неплохо жмущихся xpixmap'ов помогает очень даже.  А на случай, если суют всё равно слишком активно -- там есть сетевой своп и патчик имени Peter Zijlstra от дедлоков при оном.

Высказать мнение | Ответить | Правка | ^ | Наверх | 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ообщить модератору

16. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."  
Сообщение от Michael Shigorin email(ok) on 22-Фев-09, 23:42 
>а рестарт важных демонов и т.п. уже сегодня сполпинка выполняет тривиальный

Есть ещё monit (http://mmonit.com), рекомендую.

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

17. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."  
Сообщение от pavlinux email(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 email(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 email(ok) on 23-Фев-09, 00:32 
>Затем, выяснить отклонение от идеального сжатия... и сделать поправку на него...

Думается эта поправка будет влиять в основном на скорость работы...

Вывод: Допустимые пределы использования этой шняги от 32% до 45%  от всей RAM !!!


Верхний предел определите сами, сплющив 1.000.000 байт из /var/lib/dict/words или dd if=/dev/zero :)

И самый интересный вывод: Вам надо просто добавить треть имеющейся у Вас оперативки!


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

20. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."  
Сообщение от pavlinux email(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ообщить модератору

22. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."  
Сообщение от Nexor on 23-Фев-09, 09:26 
По поводу NTFS в винде. А кто нить вообще в курсе что там за сжатие? Отвечаю: полный примитив, который объединяет идущие подряд 1 или 0... как понимаете сжатием это названо для галочки
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

23. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."  
Сообщение от iZEN email(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ообщить модератору

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

а тебе 7zip нужен?
ты бы потестил для начала насколько это сжатие реально эффективно на кучи тхт-шек, а потом уже говорил: "для галочки"

Высказать мнение | Ответить | Правка | ^ | Наверх | 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 email(ok) on 23-Фев-09, 19:23 
А не торрент/peer2peer/emule слабо свопу посадить??? Пущай по планете свопиться...


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

28. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."  
Сообщение от Michael Shigorin email(ok) on 23-Фев-09, 23:38 
>Задействование SWAP при наличие свободного ОЗУ -- симптом "болезни".

Вы это IBM с их AIX расскажите, мож на работу примут.  Если в двери головой пройдёте, конечно.

А если всё-таки подумать ещё -- то простаивающая память есть выкинутые деньги, и память, забитая неделю не использовавшимся барахлом -- я вот тоже склонен считать простаивающей.  Пусть в свопе полежит.

Искренне надеюсь, что в следующий раз сперва немного поизучаете тематику, а потом будете обсуждать VM.  Можете вот по kerneltrap.org полазить, чтоб не говорить глупости времён Linux 2.2 примерно.  Причём как отмечено выше -- такое понимание необязательно линукс-специфично.

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

29. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."  
Сообщение от Michael Shigorin email(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ообщить модератору

30. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."  
Сообщение от Michael Shigorin email(ok) on 23-Фев-09, 23:51 
>Затем, выяснить отклонение от идеального сжатия... и сделать поправку на него...

Говорю же -- пиксмапы там рыхлые, что-то ~50% долетающего до свопа за неделю-две сжималось на том терминале вдвое (Good), а процентов 10--20 так даже и больше (VeryGood -- коллега специально допатчил статистику, ему интересно было).

А, даже вот: http://article.gmane.org/gmane.linux.terminal-server.devel/970

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

31. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."  
Сообщение от Michael Shigorin email(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ообщить модератору

32. "Виртуальное увеличение памяти через хранение в ОЗУ сжатого s..."  
Сообщение от pavlinux email(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ообщить модератору


Архив | Удалить

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру