System32 11 мая 2010 в 13:21

Продолжаем говорить о памяти – Page Sharing

8 мин

9.3K

Виртуализация *

+44

Комментарии 35

System32 11 мая 2010 в 13:34

Уважаемая хаброобщественность? Чего, по вашему мнению, не хватает в этой и предыдущей статье? Что бы нужно было добавить, и что бы хотелось услышать в следующих?

Razmolot 11 мая 2010 в 13:43

ммм. Букв? :)

System32 11 мая 2010 в 13:46

То есть, Вы считаете, что в статье слишком много букв и слишком мало картинок, что немного затрудняет ее понимание? Постараюсь учесть.

Kolegg 11 мая 2010 в 15:51

Картинки по теме наверное сложно найти, но вот графики смотрелись бы очень хорошо.

braintorch 11 мая 2010 в 16:00

Наоборот. Это была жалоба на то, что статья короткая. =) Хотя, на мой взгляд, размер подобран хорошо. И все нюансы изложены, и не перегружает информацией. Пара картинок, впрочем, не помешает, для наглядности.

Ждём следущую статью, интересно пишете.

omnimod 11 мая 2010 в 14:11

Никто не говорил, что Transparent Page Sharing (и его аналоги в других гипервизорах) — это панацея. Если есть у вас куча виртуальных машин с небольшим количеством ОП (привет, VDI) и/или устаревшими ОС — то получаете плюшки от TPS; нету, и вам требуется выделять виртуальной машине МНОГО памяти — отключаете.

System32 12 мая 2010 в 15:13

Разумеется не панацея. А с Windows 7 и его SuperFetch'ем — и на VDI работать не будет.

Речь тут шла даже не об этом, а о том, что на более современных системах, где размер страницы — 2М, а не 4К — TPS просто не будет работать. И выигрыш в производительности от 2М-страниц намного превысит выгоду от TPS.

omnimod 12 мая 2010 в 16:57

Ну вот вам пример из жизни:

Только 3 машины с Windows Server 2003, остальные — W2K8 R2 и Windows 7. LMP включен, SuperFetch включен (настройки по-умолчанию).

3 Гб экономии за счет TPS при 8 Гб физической памяти, и это еще в high state — неплохо, правда? :)

System32 12 мая 2010 в 17:26

Интересно, интересно. Я не то, чтобы не верю — пруфпик перед глазами, интересно только, как можно добиться такого? Вы точно уверены, что Large Memory Pages — Enabled? :)

AntonVirtual 18 июн 2010 в 11:09

При нехватке памяти ESX автоматически переключается на 4к страницы. Падение производительности (которого лично я, кстати, не заметил) от TPS на пару-тройку порядков меньше, чем при вхождении в глубокий своп.

kirilodius 11 мая 2010 в 15:38

поправьте плиз
сОбственно, все это и Page Sharing. Вот что пишет в своей статье ПРОБЕЛ Алан

System32 12 мая 2010 в 04:08

Здравия желаю, товарищ зондерфюрер граммаррейха! Поправил! :)

fidan 11 мая 2010 в 15:39

maybe появится в Windows Server 2008 R2 SP1?

System32 12 мая 2010 в 04:10

Спасибо!

НЛО прилетело и опубликовало эту надпись здесь

netAn 11 мая 2010 в 17:33

просто в x32 размер максимального адресного пространства 4Гб, а потом нужны ухищрения.
например, в FAT32 максимальный размер файла — 4 Гб

Grox 11 мая 2010 в 16:51

Мне просто понравилась статья. Интересно. Довольно целостно написано и вероятно большего не нужно. На мой взгляд объём можно было немного сократить, часть текста дублируется.

netAn 11 мая 2010 в 17:31

и, кстати, автора ты лично знаешь :) земляк наш.

dimoclus 11 мая 2010 в 17:41

Довольно давно я читал книгу Зубкова об ассемблере для x86 и там упоминалось о 4-мегабайтных страницах памяти. В вашем посте говорится о поддержке 2-мегабайтных страниц в новейших процессорах. Внимание, вопрос: что нового и революционного в 2MB страницах, когда уже давным-давно существует возможность создавать 4-мегабайтные страницы?
Ну и хотелось бы узнать, почему все ОС пошли по пути страничной организации памяти. Разве сегментная адресация так плоха?

НЛО прилетело и опубликовало эту надпись здесь

System32 12 мая 2010 в 04:14

Довольно давно я читал книгу Зубкова об ассемблере для x86 и там упоминалось о 4-мегабайтных страницах памяти. В вашем посте говорится о поддержке 2-мегабайтных страниц в новейших процессорах. Внимание, вопрос: что нового и революционного в 2MB страницах, когда уже давным-давно существует возможность создавать 4-мегабайтные страницы?

Революционого — ничего. Это эволюция, а не революция. Точно так же, как и постепенный переход на 64-битные системы.

Ну и хотелось бы узнать, почему все ОС пошли по пути страничной организации памяти. Разве сегментная адресация так плоха?

Думаю, об этом лучше всего будет спросить у разработчиков ОС ;)
Мое предположение — для упрощения работы со своп-файлами.

Pilat 11 мая 2010 в 18:43

В этой статье не хватает смысла. Исходные: микрософт и vmware хотят делать page sharing. Вывод: у них не получится, потому что маленькие страницы не хотят, а большие не могут. (с) Ленин 1913-й год?

Ну и… «зачем я тут растекался мысью по древу» — а кто знает, зачем Вы белочкой по веточке скакали?

gribozavr 11 мая 2010 в 18:59

> Процесс подготовки к работе Page Sharing включает в себя хэширование всех страниц памяти, сохранение хэшей в таблицу и затем – побитовое сравнение. Этот процесс долог и ресурсоемок, и может занять часы.

Часы? o_O Уверены, что просто прочитать всю RAM и прохешировать занимает часы?

System32 11 мая 2010 в 19:23

Там не только чтение с хэшированием, но еще и побитовое сравнение. При этом в некоторые ячейки могут вноситься изменения и их придется пересчитывать заново, так что — вполне вероятно. Да и специалисты об этом пишут.

gribozavr 11 мая 2010 в 19:48

Побитовое сравнение только тех страниц, у которых совпали хеши. Сравнить даже тысячу страниц по 4K памяти — ничто.

System32 12 мая 2010 в 04:19

Проблема в том, что их не тысячи, а миллионы. 128 гиг памяти — это 32 миллиона 4К страниц. А терабайт памяти (что вполне реально для 4-голового сервера на Nehalem'ах, поддерживающих 256 гиг на сокет) — это ажно 256 миллионов 4К-страниц.

Pilat 11 мая 2010 в 22:48

Где специалисты об этом пишут?

System32 12 мая 2010 в 04:17

Например — тут:
blogs.technet.com/virtualization/archive/2010/04/07/dynamic-memory-coming-to-hyper-v-part-3.aspx

Page Sharing is a memory technique where the hypervisor inspects and hashes all memory in the system and stores it in a hash table. Over time, which can be hours, the hashes are compared and if identical hashes are found, a further bit by bit comparison is performed.

Pilat 12 мая 2010 в 09:30

Я сделал тест — скорость сравнения страниц действительно очень невелика. Если 1.4 — требуемый коэффициент, то действительно часы получаются.

System32 12 мая 2010 в 09:34

Спасибо за экспериментальное подтверждение!

AntonVirtual 18 июн 2010 в 11:06

У меня эспериментальное подтверждение, что 64ГБ дедуплицируются за час.

blog.vadmin.ru/2010/02/transparent-page-sharing.html

AntonVirtual 18 июн 2010 в 11:07

Это прежде всего конкуренты, которые должны писать про то, какой плохой продукт у других.

kraitos 12 мая 2010 в 06:38

В комментах какие-то неадекватные наезды на автора.

Автору — пишите еще, очень познавательно.

System32 12 мая 2010 в 06:53

Да я уже привык к таким наездам — видимо не сильно здесь любят MS, и еще меньше любят технические статьи с кучей текста.
Конечно, обзор айпада, стотысячный по счету на хабре с кучей гламурных картинок — куда как интересней.

AntonVirtual 18 июн 2010 в 11:11

>Page Sharing при использовании современного оборудования и операционных систем становится в лучшем случае бесполезной, а то и вредной – снижая производительность и не позволяя использовать новые возможности железа и ОС.

Особенно на NUMA системах, ага…
blog.vadmin.ru/2010/05/tps.html
blog.vadmin.ru/2010/05/numa.html

Зарегистрируйтесь на Хабре, чтобы оставить комментарий