The OpenNET Project / Index page

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

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

21.02.2009 22:19

"Compcache в Linux, сожми свой SWAP" - рассказ о Compcache, интересной реализации метода виртуального увеличения фактического объема ОЗУ через хранение раздела подкачки в сжатом виде в области ОЗУ (идея в том, что в сжатый своп влезет больше данных, чем в занимаемую им несжатую память).

  1. Главная ссылка к новости (http://itbg.wordpress.com/2009...)
Лицензия: CC-BY
Тип: яз. русский / Практикум
Ключевые слова: swap, memory, linux, patch, compress
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (31) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 22:57, 21/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Раньше, когда у меня было 512 гигов оперативки, я знал, что такое осуществимо:)
    И даже как-то размещал своп в XP на сжатом виртуальном RAM-диске...
     
     
  • 2.3, pavlinux (ok), 23:02, 21/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Раньше, когда у меня было 512 гигов оперативки, я знал, что такое
    >осуществимо:)
    >И даже как-то размещал своп в XP на сжатом виртуальном RAM-диске...

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

     
     
  • 3.10, User294 (ok), 16:27, 22/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Интересно, как это ты в XP сжимал RAM disk, и особенно файл
    >свопа?

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

     
     
  • 4.13, pavlinux (ok), 17:39, 22/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >>Интересно, как это ты в XP сжимал RAM disk, и особенно файл
    >>свопа?
    >
    >Форматнув в NTFS и включив сжатие для всего диска?
    >(будет ли по факту сжиматься своп на таком диске я честно гря
    >не знаю и не проверял).

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

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


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

     
  • 2.6, внимательный (?), 23:48, 21/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Раньше, когда у тебя было 512 гигов оперативки, ты сжимал... но когда ты докупил до 1 террабайта... )))))))

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

     

  • 1.2, pavlinux (ok), 23:00, 21/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Минусы:

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

    Плюсы:

    - Куй!



     
     
  • 2.4, Антон (??), 23:18, 21/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Еще один минус - аллокатор до последнего будет пытаться не залезть в своп, уменьшая размер буферов, сокращая дисковый кеш.

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

     
     
  • 3.11, User294 (ok), 16:50, 22/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    > Лучше бы сделали kill, не убивающий, а замораживающий состояние процесса на диск

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

     
     
  • 4.16, Michael Shigorin (ok), 23:42, 22/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >а рестарт важных демонов и т.п. уже сегодня сполпинка выполняет тривиальный

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

     
  • 2.14, Michael Shigorin (ok), 19:08, 22/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Плюсы:

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

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

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

     
     
  • 3.17, pavlinux (ok), 23:44, 22/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Ну вот, опять скоропалительные выводы...
    >
    > в итоге принято решение включать автоматически (при 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 для оптимального размера. Пойду ещё косяк забъю...

     
     
  • 4.18, pavlinux (ok), 00:20, 23/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Осталось узнать, какой нужон k для оптимального размера. Пойду ещё косяк забью...

    Мужики, огромные формулы, но k = 1.998326

    То есть размер свопа, при ИДЕАЛЬНОМ сжатии, должон быть больше 1.998326008 или меньше 50.04%. Строго.
    Дальше вот такая горка -  http://s47.radikal.ru/i116/0902/81/c412946273fd.jpg

    Далее надо проводить расчёты на разницу в нагрузке на процессор, их вычитать из полученного.
    Затем, выяснить отклонение от идеального сжатия... и сделать поправку на него...


    ... как мне подсказали, LZO, в среднем может плющить до 36%,
    с этой поправкой вышло, что ~32% от RAM можно выделять...


    Если что где не правильно поправляйте...

     
     
  • 5.19, pavlinux (ok), 00:32, 23/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Затем, выяснить отклонение от идеального сжатия... и сделать поправку на него...

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

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


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

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


     
  • 5.30, Michael Shigorin (ok), 23:51, 23/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Затем, выяснить отклонение от идеального сжатия... и сделать поправку на него...

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

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

     
     
  • 6.32, pavlinux (ok), 01:58, 24/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >>Затем, выяснить отклонение от идеального сжатия... и сделать поправку на него...
    >
    >Говорю же -- пиксмапы там рыхлые, что-то ~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

     

  • 1.5, Аноним (5), 23:28, 21/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Господа теоретики, я только что сие попробовал. И стало гораздо лучше, по крайней мере на первый взгляд.

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

     
     
  • 2.9, Аноним (1), 12:10, 22/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    можно еще флешку подцепить свопом.

     
     
  • 3.12, Анонимус2 (?), 17:12, 22/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >можно еще флешку подцепить свопом.

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

     
     
  • 4.26, Анонимус3 (?), 17:25, 23/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    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

     
     
  • 5.27, pavlinux (ok), 19:23, 23/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    А не торрент/peer2peer/emule слабо свопу посадить??? Пущай по планете свопиться...


     
  • 5.31, Michael Shigorin (ok), 00:01, 24/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >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 к вечеру?

     

  • 1.7, Илья (??), 00:22, 22/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Для сомневающихся в статье есть тесты, которые показывают прирост производительности, а теоретические выводе в посте выше ничем не подкреплены и основываются лишь на догатках.
    И кто Вам мешает добавить ещё один SWAP раздел?
     
  • 1.15, iZEN (ok), 23:33, 22/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >"Compcache в Linux, сожми свой SWAP (http://itbg.wordpress.com/2009/02/18/compcache-%d0%b2-linux-%d)" - рассказ о Compcache (http://code.google.com/p/compcache/),
    >интересной реализации метода виртуального увеличения фактического объема ОЗУ через хранение раздела
    >подкачки в сжатом виде в области ОЗУ (идея в том, что
    >в сжатый своп влезет больше данных, чем в занимаемую им несжатую
    >память).

    Давно известно, что Linux даже при избытке свободного ОЗУ использует SWAP-раздел пусть даже на 5..10% от его объёма.

    Аллокатор памяти в Linux настолько самокритичен, что не позволяет как в FreeBSD всё "до последнего" держать в ОЗУ. Одна из причин такого положения -- неэффективность реализации транзакционности основной файловой системы Ext3, требующая использования SWAP для ведения журнала метаданных.

    Задействование SWAP при наличие свободного ОЗУ -- симптом "болезни".
    Использование RAM-диска для SWAP (пусть и сжатого) -- "лечение" болезни анестетиками.

     
     
  • 2.20, pavlinux (ok), 00:43, 23/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >неэффективность Ext3, требующая использования SWAP для ведения журнала метаданных.
    >
    >Задействование SWAP при наличие свободного ОЗУ -- симптом "болезни".
    >Использование RAM-диска для SWAP (пусть и сжатого) -- "лечение" болезни анестетиками.

    1. Не юзать ext3
    2. sysctl -w vm.swappiness = 0
    3. # CONFIG_SWAP is not set

     
  • 2.21, Аноним (1), 02:53, 23/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Давно известно, что Linux даже при избытке свободного ОЗУ использует SWAP-раздел пусть
    >даже на 5..10% от его объёма.

    Враньё и провокация. "swap used: 0", что я делаю не так?

     
     
  • 3.23, iZEN (ok), 12:10, 23/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >>Давно известно, что Linux даже при избытке свободного ОЗУ использует SWAP-раздел пусть
    >>даже на 5..10% от его объёма.
    >
    >Враньё и провокация. "swap used: 0", что я делаю не так?

    Ты ничего не делаешь.

     
     
  • 4.24, Lindemidux (??), 12:40, 23/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >>>Давно известно, что Linux даже при избытке свободного ОЗУ использует SWAP-раздел пусть
    >>>даже на 5..10% от его объёма.
    >>
    >>Враньё и провокация. "swap used: 0", что я делаю не так?
    >
    >Ты ничего не делаешь.

    Додик iZen почему у меня начинает работать свап только при заполнении памяти свыше 80%?

     
  • 4.29, Michael Shigorin (ok), 23:42, 23/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >>>Давно известно, что 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 собирать.

     
  • 2.28, Michael Shigorin (ok), 23:38, 23/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Задействование SWAP при наличие свободного ОЗУ -- симптом "болезни".

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

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

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

     

  • 1.22, Nexor (?), 09:26, 23/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    По поводу NTFS в винде. А кто нить вообще в курсе что там за сжатие? Отвечаю: полный примитив, который объединяет идущие подряд 1 или 0... как понимаете сжатием это названо для галочки
     
     
  • 2.25, none (??), 16:34, 23/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >По поводу NTFS в винде. А кто нить вообще в курсе что
    >там за сжатие? Отвечаю: полный примитив, который объединяет идущие подряд 1
    >или 0... как понимаете сжатием это названо для галочки

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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

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