"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
Раньше, когда у меня было 512 гигов оперативки, я знал, что такое осуществимо:)
И даже как-то размещал своп в XP на сжатом виртуальном RAM-диске...
>Раньше, когда у меня было 512 гигов оперативки, я знал, что такое
>осуществимо:)
>И даже как-то размещал своп в XP на сжатом виртуальном RAM-диске...Интересно, как это ты в XP сжимал RAM disk, и особенно файл свопа?
>Интересно, как это ты в XP сжимал RAM disk, и особенно файл
>свопа?Форматнув в NTFS и включив сжатие для всего диска?
(будет ли по факту сжиматься своп на таком диске я честно гря не знаю и не проверял).
>>Интересно, как это ты в XP сжимал RAM disk, и особенно файл
>>свопа?
>
>Форматнув в NTFS и включив сжатие для всего диска?
>(будет ли по факту сжиматься своп на таком диске я честно гря
>не знаю и не проверял).Каждый раз при загрузке, а у виндузятников, это по 5 и более раз в день...
1. Создать RAM диск;
2. Форматнуть в NTFS;
3. Сжать;
4. Создать там pagefile.sys
Думаю они лучше оперативки прикупят...
Раньше, когда у тебя было 512 гигов оперативки, ты сжимал... но когда ты докупил до 1 террабайта... )))))))>Раньше, когда у меня было 512 гигов оперативки, я знал, что такое
>осуществимо:)
>И даже как-то размещал своп в XP на сжатом виртуальном RAM-диске...
Минусы:- Два дополнительных модуля.
- Занимаемая, ими, RAM память.
- Нагрузка на процессор, алгоритмами (де)компрессии.
- Не ясно что будет в результате окончания места в RAM и в RAM SWAP.Плюсы:
- Куй!
Еще один минус - аллокатор до последнего будет пытаться не залезть в своп, уменьшая размер буферов, сокращая дисковый кеш.Лучше бы сделали kill, не убивающий, а замораживающий состояние процесса на диск, чтобы потом unkill можно было выполнить с того же места начать работу.
> Лучше бы сделали kill, не убивающий, а замораживающий состояние процесса на дискКруто, "и пусть весь мир подождет" (c) реклама =).Кстати утилиты делающие такое - есть.Только вот смысла так делать именно в OOM-обработчике не больно много: вы делаете вольное допущение что вскоре полегчает.А оно не обязано нифига - полегчать.Гарантировано то только облегчение ровно на вес убитых при OOM процессов.И ... все!Если они не лезли раньше, wtf они влезут позже?И, кроме того, при OOM пристреливаются наиболее жирные процессы.И если процесс сожрал полтора гига памяти - слив этого добра на диск будет не подарок.В итоге все-равно tcp\ip соединения скорее всего успеют сдохнуть до того как процесс разморозится, а раз так... смысл хранения состояния - невелк (некоторые данные все-равно будут утеряны) а рестарт важных демонов и т.п. уже сегодня сполпинка выполняет тривиальный скрипт сунутый в крон или даже такая штука как демон restartd.
>а рестарт важных демонов и т.п. уже сегодня сполпинка выполняет тривиальныйЕсть ещё monit (http://mmonit.com), рекомендую.
>Плюсы:Ну вот, опять скоропалительные выводы...
compcache вовсю используется в ALT Linux 4.0 Terminal (и Линукс Терминал) в ядре для бездисковых клиентов, обкатывался у нас в офисе и на стедне довольно долго, в итоге принято решение включать автоматически (при 64M RAM отрезается ~22M, например).
Для клиники вроде firefox2, kpdf и подобных любителей понасовать в иксы на тонком клиенте неплохо жмущихся xpixmap'ов помогает очень даже. А на случай, если суют всё равно слишком активно -- там есть сетевой своп и патчик имени Peter Zijlstra от дедлоков при оном.
>Ну вот, опять скоропалительные выводы...
>
> в итоге принято решение включать автоматически (при 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 для оптимального размера. Пойду ещё косяк забъю...
>Осталось узнать, какой нужон k для оптимального размера. Пойду ещё косяк забью...Мужики, огромные формулы, но k = 1.998326
То есть размер свопа, при ИДЕАЛЬНОМ сжатии, должон быть больше 1.998326008 или меньше 50.04%. Строго.
Дальше вот такая горка - http://s47.radikal.ru/i116/0902/81/c412946273fd.jpgДалее надо проводить расчёты на разницу в нагрузке на процессор, их вычитать из полученного.
Затем, выяснить отклонение от идеального сжатия... и сделать поправку на него...
... как мне подсказали, LZO, в среднем может плющить до 36%,
с этой поправкой вышло, что ~32% от RAM можно выделять...
Если что где не правильно поправляйте...
>Затем, выяснить отклонение от идеального сжатия... и сделать поправку на него...Думается эта поправка будет влиять в основном на скорость работы...
Вывод: Допустимые пределы использования этой шняги от 32% до 45% от всей RAM !!!
Верхний предел определите сами, сплющив 1.000.000 байт из /var/lib/dict/words или dd if=/dev/zero :)И самый интересный вывод: Вам надо просто добавить треть имеющейся у Вас оперативки!
>Затем, выяснить отклонение от идеального сжатия... и сделать поправку на него...Говорю же -- пиксмапы там рыхлые, что-то ~50% долетающего до свопа за неделю-две сжималось на том терминале вдвое (Good), а процентов 10--20 так даже и больше (VeryGood -- коллега специально допатчил статистику, ему интересно было).
А, даже вот: http://article.gmane.org/gmane.linux.terminal-server.devel/970
>>Затем, выяснить отклонение от идеального сжатия... и сделать поправку на него...
>
>Говорю же -- пиксмапы там рыхлые, что-то ~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 kBamd64:/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 WHATamd64:/home/pavel # free
total used free shared buffers cached
Mem: 4127528 3427220 700308 0 0 2185340
-/+ buffers/cache: 1241880 2885648
Swap: 1375840 44 1375796
Господа теоретики, я только что сие попробовал. И стало гораздо лучше, по крайней мере на первый взгляд.После охочей до памяти игрушки под вайном, FF больше не хрустит диском по несколько минут. Тормозов в игрушке не замечено, памяти в системе - 768 Мб. Расширить трудно и дорого ибо ноутбук.
можно еще флешку подцепить свопом.
>можно еще флешку подцепить свопом.это ты из висты узнал?
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/swapfilePS: man dd, man mkswap, man swapon, man swapoff
А не торрент/peer2peer/emule слабо свопу посадить??? Пущай по планете свопиться...
>dd if=/dev/zero of=/media/sda1/tmp/swapfile bs=1024 count=65536
>PS: man dd, man mkswap, man swapon, man swapoffman что, чтоб примитивный wear leveling в этом sda1 не угробил флэшку по модулю 12 к вечеру?
Для сомневающихся в статье есть тесты, которые показывают прирост производительности, а теоретические выводе в посте выше ничем не подкреплены и основываются лишь на догатках.
И кто Вам мешает добавить ещё один SWAP раздел?
>"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 (пусть и сжатого) -- "лечение" болезни анестетиками.
>неэффективность Ext3, требующая использования SWAP для ведения журнала метаданных.
>
>Задействование SWAP при наличие свободного ОЗУ -- симптом "болезни".
>Использование RAM-диска для SWAP (пусть и сжатого) -- "лечение" болезни анестетиками.1. Не юзать ext3
2. sysctl -w vm.swappiness = 0
3. # CONFIG_SWAP is not set
>Давно известно, что Linux даже при избытке свободного ОЗУ использует SWAP-раздел пусть
>даже на 5..10% от его объёма.Враньё и провокация. "swap used: 0", что я делаю не так?
>>Давно известно, что Linux даже при избытке свободного ОЗУ использует SWAP-раздел пусть
>>даже на 5..10% от его объёма.
>
>Враньё и провокация. "swap used: 0", что я делаю не так?Ты ничего не делаешь.
>>>Давно известно, что Linux даже при избытке свободного ОЗУ использует SWAP-раздел пусть
>>>даже на 5..10% от его объёма.
>>
>>Враньё и провокация. "swap used: 0", что я делаю не так?
>
>Ты ничего не делаешь.Додик iZen почему у меня начинает работать свап только при заполнении памяти свыше 80%?
>>>Давно известно, что 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 собирать.
>Задействование SWAP при наличие свободного ОЗУ -- симптом "болезни".Вы это IBM с их AIX расскажите, мож на работу примут. Если в двери головой пройдёте, конечно.
А если всё-таки подумать ещё -- то простаивающая память есть выкинутые деньги, и память, забитая неделю не использовавшимся барахлом -- я вот тоже склонен считать простаивающей. Пусть в свопе полежит.
Искренне надеюсь, что в следующий раз сперва немного поизучаете тематику, а потом будете обсуждать VM. Можете вот по kerneltrap.org полазить, чтоб не говорить глупости времён Linux 2.2 примерно. Причём как отмечено выше -- такое понимание необязательно линукс-специфично.
По поводу NTFS в винде. А кто нить вообще в курсе что там за сжатие? Отвечаю: полный примитив, который объединяет идущие подряд 1 или 0... как понимаете сжатием это названо для галочки
>По поводу NTFS в винде. А кто нить вообще в курсе что
>там за сжатие? Отвечаю: полный примитив, который объединяет идущие подряд 1
>или 0... как понимаете сжатием это названо для галочкиа тебе 7zip нужен?
ты бы потестил для начала насколько это сжатие реально эффективно на кучи тхт-шек, а потом уже говорил: "для галочки"
