Pull to refresh

Comments 85

Статьи такого уровня и определяют класс хабра.

Спасибо.
мммм, пора вводить плашку «Правильный автор», который пишет правильные статьи по нужной тематике.

ЗЫ надо чтоб автор стал №1 — все-таки ресурс не для фотографий кресел…
UFO landed and left these words here
Уровень — да, я считаю любой программист обязан это знать. Но вот новичкам читать будет тяжело, тексту ещё бы пару дней в черновиках надо, чтобы стиль и оформление подкрутить.

Перед употреблением этого материала, чтобы чувствовать себя уверенно, рекомендую посмотреть прекраснейшее выступление Марка Руссиновича на PDC10 на эту тему:
Mysteries of Windows Memory Management Revealed, Part 1 of 2
Mysteries of Windows Memory Management Revealed, Part 2 of 2
Действительно отличные доклады. Гораздо лучше чем у меня. В оправдание могу сказать, что Руссинович имеет громадный опыт в публичных выступлениях и подготовке презентаций. Более того, не удивлюсь если данная презентация собрана из материала, который собирался и полировался несколько лет. Я же написал статью за пару дней на коленке и с нуля.

В общем в черновиках ей сидеть надо было бы хотя с полгода — попробую поправить пост-фактум (если есть конкретные предложения по стилистике — с радостью приму помощь в редактуре)
извините, отправилось раньше срока
>XP — 1 ядро
>Vista — 4
>7 — 8
>это такой тонкий намек?
А не, две мотороллера — не мои (найдены в инете), а один — мой. С другой стороны, примерно так и развивалось железо со временем
МОТОРОЛЛЕР НЕ МОЙ Я ПРОСТО РАЗМЕСТИЛ ОБЬЯВУ!111
Осилил с боооольшим трудом :-)
Все-таки, немного напутано.
Все эти мутки с отключением pagefile или переноса на RAM-Disk — это все страшная утопия?
Что путано — это да. «Это не я такой — это жизнь такая».
Зато есть павершеловские скрипты для «оптимизации» памяти. :-)

Отключение пейджфайла может принести положительный результат в редких случаях. Однако перед отключением следует понимать, что делается, зачем и какие есть альтернативы. Перенос файла подкачки на рамдиск — не может помочь в принципе. То есть вообще никогда.
Спасибо за статью. Поработайте, пожалуйста, над стилем изложения. Нестрашно, если будет больше букв: зато понятнее.
Перенос файла подкачки на рамдиск — не может помочь в принципе. То есть вообще никогда.


А почему, ведь скорость доступа к файлу увеличивается? Объясните, если не трудно :)
Потому, что назначение свопа компенсировать недостаток ОЗУ, а не забивать свободную память.
Очень конструктивно.

Тем не менее размещение свопа в свободной памяти компенсирует медленную скорость доступа находясь на жестком диске.

Есть предположение, что автор имел в виду то, что перемещение свопа в оперативную память равносильно его отключению (лишняя «прослойка»). Я правильно понимаю?
Ну какой в этом вообще может быть смысл? Вы работаете, у вас на столе бумаги, разные книги, в какой-то момент вы решаете, что вам не хватает места и вы прибиваете над столом полочку, куда складываете редко используемые книги. Через некоторое место замечаете, что до полочки слишком долго тянутся, снимаете её и кладете на стол. У вас стало больше места на столе?
А если это ОЗУ не доступно для системы? XP 32бита не видит ничего выше 3гб. А памяти допустим 4гб. Пускай 786мб пропадают?
Эти 786 мб неадресуемы, в т.ч. и неадресуемы для того, чтобы их использовать для pagefile.
Адресуемы. У меня 8гб на XP 32bit. Рамдиск на 4300мб. Там правда не только pagefile, все кэши, темпы и т.д.
Но при этом hibernate ведь не работает?
> Перенос файла подкачки на рамдиск — не может помочь в принципе. То есть вообще никогда.
Вы ошибаетесь. 32-битная Windows (в моем случае — Vista) на ряде ноутбуков не видит памяти свыше 2.5Г (или выше 3Г плюс-минус — все зависит от конфигурации железа). Включенный режим PAE + файл подкачки на RAM-диске позволяют оставшиеся 1.5Г использовать хоть как-то. Понятное дело, что в таком режиме скорость работы с такой «виртуальной» памятью все равно раз в 100 ниже, чем с «обычной» памятью, однако даже этот результат оказывается на 2-3 порядка быстрее, чем если бы файл подкачки был на физическом диске. Подробности я описал тут: friendfeed.com/dklab/9f46792b/windows-32-4-2-5-ram-1

У меня сейчас в итоге: 32-битная Windows, 3Г памяти обычной, около 1Г — файл подкачки на RAM-диске, и еще есть файл подкачки на SSD (который, впрочем, практически всегда близок к нулевому размеру).

В 64-битной ОС, конечно же, этой проблемы нет, видны все 4Г.
Рекомендую подробности этой небезынтересной конфигурации памяти переопубликовать также и на Хабрахабре.
Лушче отключить файл подкачки, чем переносить его в RAM
Аргументируйте, пожалуйста. Только в контексте «32-битная Windows не видит памяти свыше 2.5Г (или выше 3Г плюс-минус — все зависит от конфигурации железа). Включенный режим PAE + файл подкачки на RAM-диске позволяют оставшиеся 1.5Г использовать хоть как-то.»
Согласен с Мицголом, надо написать топик. В рамках недели просвещения на Хабре.
А мне кажется, что там нечего особенно писать — ссылки достаточно, это не rocket science.
Ну с тестами надо для доказательства. Я вот хотел про пользу от рам диска для компиляции написать — так провёл кое какие тесты с сорцами FireFox и писать передумал — ибо оказалось не о чем.
Отрицательный результат — тоже результат )
С доказательствами того, что запись в RAM-диск на несколько порядков быстрее, чем запись на диск (даже SSD)? Мне кажется, это излишне.
Я повторюсь, я тоже думал что компиляция на рам диске сильно быстрее чем на hdd. Однако разница была:
ALL IN RAM = 1915 seconds
ALL ON HDD = 1945 seconds
ALL — это всё, исходники объёктники и temp.
Это совершенно ожидаемо — запись на диск ОС производит отложено: когда памяти много, почти нет разницы, куда пишется — на RAM-диск или на HDD. В случае с файлом подкачки это, очевидно, не так.
О таком сценарии не подумал — действительно имеет место быть. Добавил в апдейты
Либо я чего-то не понял, либо Вы тоже заблуждаетесь. Та память, которую «не видно» — это memory mapped I/O и области для доступа к видеокарте например, к ее памяти через адресное пространство оперативной. Так или иначе, эти адреса недоступны физически на уровне PCI-мостов, никакими ухищрениями с пейджингом увидеть их не получится. Это тот случай, когда памяти ровно 4 гига. Если памяти больше, скажем 8 гигов, тогда можно написать свой драйвер RAM-disk-а, который сможет использовать память выше 4 гигов (то что между 3,3 и 4 увидеть все-равно не получится) но смысла в этом никакого, тут надо ставить x64.
У современных чипсетов есть такая фича — memory remap feature, которая позволяет отмапить часть оперативки в пространство выше 4Gb, на первый взгляд кажется, что это то что нужно, пишем свой драйвер, работающий с этой памятью и размещаем своп там, выше 4 гигов. На практике это опять же лишено всякого смысла, потому что для доступа к этой памяти нужен диапазон адресов в первых 4-х гигах, которые придется попросить из системного адресного пространства и вручную поправить таблицы страниц, но мы при этом забираем у системы виртуальные адреса, которые ей возможно нужнее, чем дополнительный своп, можно конечно каждый раз выделять/освобождать при каждом обращении к этому «свопу», но в этом еще меньше смысла.
В общем я бы сказал так, теоретически при наличии должной поддержки со стороны желаза и в каком-то особом случае, когда известно что можно безболезненно забрать у системы часть системного виртуального адресного пространства, это может и принесет какую-то пользу, но всем и каждому я бы это не рекомендовал. Это примерно как кошке пятая нога иногда может быть полезна. Поправьте меня.
Позвольте с вами не согласиться!
Включенный режим PAE позволяет 32-битной операционной системе эффективно использовать доступную физическую память далеко за пределами 4 ГБ (вплоть до 64 ГБ).
Конечно же, виртуальное адресное пространство одного конкретного процесса останется неизменным. Но при этом физическая страница ОЗУ, соответствующая какой-либо странице виртуальной памяти, может лежать за пределами 4 ГБ.
Я не буду вдаваться в подробности, все уже расписано до меня, почитайте, интересно: http://en.wikipedia.org/wiki/Physical_Address_Extension
Зная этот факт, я бы не стал утверждать, что pagefile в RAM-диске — это выгодно. А вы проверяли? Делали какие-нибудь тесты?

Кстати, неправильно говорить, что 32-битное приложение не может использовать больше 4 ГБ ОЗУ;) На windows это делается посредством AWE: http://msdn.microsoft.com/en-us/library/aa366527(VS.85).aspx
Сомневающимся настоятельно рекомендую написать простенькую программку своими руками. Это очень занимательно:)
Здесь и здесь
Вкратце, PAE теоретически использовать можно, оно будет работать не всегда, часть физических адресов недоступна из-за меппинга пространства ввода/вывода и никакими способами ее не вытащить (адрес на шине адресует, к примеру видеокарту, а не память). Даже если ядро включает PAE (к примеру для включения NX) это не значит, что оно будет поддерживать PAE адресацию выше 4Gb (из-за лицензионных ограничений и некоторых глюков с драйверами PAE на клиентских 32-битных виндах не адресует больше 4Gb). Пытаться напрямую работать с директорией страниц чревато очень серьезными глюками. Завязывать драйвер RAM-диска на патченное ядро не имеет смысла.

Это технические проблемы. Если же говорить о практике: я не видел драйверов RAM диска, которые бы работали с фической памятью, да еще через PAE (в частности потому, что как сказано выше, это не имеет смысла на 32-битных виндах) — они все поголовно выделяют либо из Paged либо из Non-paged пула и хранят данные там. Ну и во-вторых, в том примере, на который я дал ссылку использует 3 Gb памяти, которые отлично адресуются системой и могут быть использованы кеш-менеджером.

Что же до тестов: как я уже сказал, теоретически такой драйвер существовать может, практически же он мне не попадался — так что тестов не было за неимением объекта тестирования. Вместо кривого решения надуманных проблем лучше взять x64 версию ОС и не мучаться.
Мне кажется, вы меня не правильно поняли: я хотел поспорить с пользователем DmitryKoterov, который утверждает, что использовать своп в рам-диск эффективно, и его спрашивал, на чем основана уверенность, что используемая им конфигурация лучше стандартной со включенным PAE.
От вас ожидал поддержки. Кстати, ее и получил, спасибо:)
Ну и конечно, правильнее взять x64, если есть возможность:)
О, не посмотрел кому Вы отвечали, а вопрос действительно неоднозначный — поэтому решил прояснить. Приношу свои извинения :-)
Мало что понял… Знаю только что сейчас проги леплят всякими конструкторами и они огромные, тогда как раньше программы занимали места меньше (и на диске и в озу) Конечно нельзя сравнить текстовый интерфейс например 5-го ворда под дос и ворда из новых офисов, но все равно новые программы хотять слишком много…

Если подумать то даже 10 мегабайт, это ж 10 000 000 символов, таким количеством букв/знаков можно описать дофига всего, даже представить не могу… а для новых программ это очень мало… Вот здесь мне кажется что-то не то, не так должно быть
Например в книге, букв наверно меньше, но когда ее читаешь сколько всего себе можно пердставить… Тоже самое должно быть с компами, ты ему основные указания, а он все делает на ходу
Здесь не столько про проги, сколько про саму винду. Базовые принципы не менялись со времен NT3.51 (1993-й год — когда компьютеры были большими, а программы маленькими).

Если кратко: смотреть в таск менеджер бесполезно, смотреть на «используемую память» и «используемый своп» бесполезно, перезапускать «Оперу», отожравшую гиг памяти — бесполезно. Ну и т.д… Просто поразительно, насколько много мифов не основаны вообще ни о чем (собственно именно поэтому статья и называется «Here be dragons»)
Ну не знаю, возможно… я любитель старых прог так как они меньше кушают озу и главное быстро работают, а более старые даже не знают что такое интернет чтобы туда лазить за обновлениями и проверкой лицензии, как вот например айсидиси 3.0… Винда у меня ХР и своп отключен, озу 4 гига но видно 3.25, меня это не беспокоит, все равно озу как г-на, мне хватает…
4 гига и до сих пор на XP x86. Мсье знает толк в извращениях :-)
так без свопа же, так что ограничения в 4 гига на адресное пространство вполне хватает.
Сразу вопрос про XP:

Так куда же она уходит после того, как отбирается у процесса? А уходит она, в зависимости от того, соответствует ли ее содержимое тому, что было прочитано с диска, в один из двух списков: Standby (начиная с Висты это не один список, а 8, о чем позже) или Modified...

Всё это в равной степени примеримно к XP? Есть ли её кеш-менеджера есть какие-то свои особенности (кроме отсутствия приоритетов)?

И ещё, на скриншоте с XP System Cache — это Cached? Если да, почему System Cache > Available (ведь весь кеш можно освободить под нужды)?
На XP Standby список хоть и один, но он все еще есть. Так что к XP применимо все, кроме приоритетов памяти.
Почему Cached > Available. Полагаю потому, что Modified list — тоже является кешем данных с диска, но не является «доступной» памятью в том смысле, что перед тем как ее можно будет использовать нужно сделать как минимум одну дисковую операцию (сбросить измененную страницу на диск)
перезапускать «Оперу», отожравшую гиг памяти — бесполезно.

когда файрбаг течет и память поднимается до верху — машина начинает ужасно тормозить.
перезапуск фокса помогает.

может в теории оно всё так, как вы говорите, но на практике оно ведёт себя совершенно иначе
У меня тоже чисто практический опыт. До хрома я пользовался оперой что то около восьми лет. В рамках программы по легализации всего и вся, я стал слушать музыку с пандоры, ласт.фм и имеем при этом никогда не перегружаясь без острой необходимости (апдейты и пр). Не знаю, был ли это лик или флеш так кеширует, но опера достаточно быстро вырастала за гигабайт. Причем система использовалась достаточно активно (виртуалки, большие проекты в VS, всякий дотнетовский lob и пр.) — тормозов не наблюдалось.

Здесь как в теории так и на практике есть некоторый «конфликт интересов»: система пытается не вырезать Working Set-ы и скорее выбросит кеш, так что повершеловский скрипт, который я привел, может ИНОГДА помочь вручную сбросить «утекшую память» сначала в modified список, а потом и в пейджфайл. Но на практике, я этого никогда не делал и никогда не имел проблем с производительностью (в смысле по причине нехватки памяти)
UFO landed and left these words here
Именно. Только у него побольше и попонятнее. Я забрел сразу в три главы: I/O Manager, Memory Manager, Cache Manager.
Побольше — да, а вот насчёт попонятнее… Тому, кто уже в теме — возможно.
Большое спасибо за вашу статью.
вот у меня сейчас modified=50mb и не меняется. правильно ли я понимаю, что в случае экстренного вырубания компа эти данные будут потеряны с непредсказуемыми последствиями?
Тысячи данных будут утеряны в случае экстренного вырубания компа. Но в основном это память приложений, которую они заново нагенерируют при следующем старте.
память приложений — это in use
In use — это вроде как Working Set всех приложений. Stend by и modified — помеченные для освобождения страницы. В принципе, в modified могут быть и измененные проекции файлов, открытых для записи. Но мне почему-то кажется, что проекции редко делают для записи, и в основном это могут быть какие-нибудь торренты, которые все равно хеши от частей файлов считают.
у меня сейчас никаких торрентов не запущено. и если приложение что-то изменило в файле, но это фиг знает когда сбросится на диск… наверно именно из-за этого у меня хром после восстановления сессии открывает давно закрытые мной вкладки и забывает про текущие =_="
RamMap умеет «чистить» (сбрасывать данные на диск и переводить страницы в Standby) modified список.
Данные можно сбрасывать вызовом FlushFileBuffers (утилита sync умеет делать это)
ну я опять же не буду вручную ничего чистить %-) просто неприятно, что ось ленится сбросить каких-то 50 метров на диск…
Private данные собираются и долго хранятся еще и для того, чтобы можно было их кластеризовать. Линейное чтение/запись — достаточно быстрая операция, это head seek убивает производительность. Вот страницы, находящиеся по соседству в памяти с большой вероятностью в будущем понадобятся тоже вместе. Винда складывает их одну за другой на диск. Фактически время записи/чтения скажем мегабайта мало отличается чтения/записи четырех килобайт
И да, я не имел в виду, что Вы можете сбросить Ваши данные при помощи FlushFileBuffers. Я имел в виду, что приложение может сбросить данные на диск при помощи этой функции, если считает это достаточно важным. Если же нужны ACID гарантии — есть KTM
Да, то что приложения использую прямо сейчас — это In Use. Если приложение получило физическую страницу в свой рабочий набор, но после того как эта страница была «подрезана», в случае приватных данных она попадает в Modified список с «намерением» сбросить ее в pagefile. В этом списке ее можно держать сколь угодно долго — это данные могут быть потеряны только вместе с единственным процессом, который может их использовать
тада ясно, надеюсь там ничего важного не валяется…
Да, эти данные будут потеряны. С другой стороны, чаще всего неопределенно должно в modified списке сидият только Private (те которые были выделены в куче, стеки потоков и пр) страницы, которые все равно не будут иметь смысла после перезагрузки. То есть как раз те страницы, которые должны пойти в пейджфайл, а не в пользовательские файлы.

Вообще говоря, никаких гарантий сохранности ДАННЫХ большинство файловых систем не дает. Журналируются только метаданные — то есть структуры самой файловой системы. Программа, которая хочет предоставить ACID гарантии, должна использовать Kernel Transaction Manager
s/неопределенно должно/неопределенно долго/
Я правильно понял, что Commit Charge — это объем виртуальной памяти, который суммарно запросили все приложения в системе?
Грубо говоря да. Сложности с pagefile backed memory mapped файлами, которые не являются виртуальной памятью, но при этом чаржат лимит
Но самое потрясающее, что я видел всвязи с управлением памятью — это совет переместить pagefile на RAM-диск:
Из моих трех гигабайт под RAM disk был выделен один (на тот момент, когда на лаптопе еще была установлена XP), на котором я создал своп на 768МБ ...
Всё нормально. Windows XP не умеет нормально использовать память выше 3ГБ, поэтому иногда там создают RAM-диск, на который помещают своп.
Здесь был выделен один из трёх гигабайт, которые использовались системой.
Объясните кто-нибудь случай с этой темой на КЫВТе:
rsdn.ru/forum/flame.comp/3805844.1.aspx
(см картинку)
Что это за выделение памяти хитрое, которое не попадает ни в Commit Charge, ни в Working Set?
Может она в nonpaged pool-е в ядре? В пользу этого предположения говорит еще и то, что при очевидном бешенном давлении на память, система не освободила себе памяти путем подрезания (вернее рабочие наборы процессов выглядят подрезанными, но память все равно забита). Я бы искал драйвер с утечками

Вообще, мне не известно о способах потребления физической памяти таким образом, чтоб это потребление нельзя было отследить стандартными средствами (хотя я предпочитаю Process Explorer). Единственное, что можно потреблять незаметно — это commit charge.
Нет, это не драйвер. Там в конце темы есть объяснение, что за прога потребляла память таким образом. Но каким образом она это делала — по прежнему загадка.
Хм, я тоже совершенно не представляю, как они это делали :-)
По моим нынешним представлениями, как я уже сказал, невозможно взять у системы физическую память так, чтобы она не отобразилась в Working Set. Вполне допускаю, что я чего не знаю, но сильно подозреваю, что здесь что то другое, чего автор просто не учел: к примеру, какой то драйвер (наподобие обсуждаемого там же eboostr) кешировал файлы для оперы и делал это в non paged pool. Это должно было бы быть видно на Task Manager-овском Performance Tab-е.
В общем, я тут поэкспериментировал с оперой и получил занятные результаты. В целом, всё аналогично — память пожирается, commit charge и commit limit без изменений. Но вот что интересно, task manager и resource monitor показывают что cached memory в это время уменьшается до 0, а вот process explorer показывает что system cache увеличивается на весь объем зохаванной памяти.
Получается, что понятие кэш в этих программах понимается совсем по разному. И в чем там различие, хотелось бы знать?
А у Вас случайно не осталось скриншота Process Explorer-овского System Information? Ну и желательно вкладку Performance из свойств процесса оперы и system в procexp?
А ты посмотри сам, это же куда информативнее ;)
Воспроизводится очень просто. Запустить закачку большого торрента (> RAM size) оперой, стопнуть, запустить снова.
Мне просто не очень хочется ставить оперу и качать 10-гиговый файл.
Не нужно качать, достаточно просто запустить.
Случайно не сохранилось, так что пришлось делать специально ;)

img695.imageshack.us/i/clipboard01jg.png/
img44.imageshack.us/i/clipboard02zt.png/
img338.imageshack.us/i/clipboard03y.png/
img844.imageshack.us/i/clipboard04y.png/
img405.imageshack.us/i/clipboard05j.png/
Ухтыха. Ради этого можно даже поставить оперу. Спасибо
Скачал, посмотрел. RamMap показывает, что память уходит в mapped file и даже показывает в какой (там кстати тоже приоритет 5, который выталкивает из памяти всех подряд), но вот почему эта памяти не отображается в Shared WS для меня загадка — надо будет поковырять
Она и в cached у task manager тоже почему-то не засчитывается. Какой-то очень странный mapped file :)
Кстати, еще интересно было бы узнать, менялся ли commit limit (когда кто-то выделяет non-paged pool — это не увеличивает commit charge, а уменьшает commit limit). В общем скриншот Process Explorer-овского system info мог бы помочь при выяснении причин
Странно, но эта и другие ваши статьи должна быть на хабре!

Прочитал. Что-то понял, но мало. Можно примеров? Есть у меня 1С, работают в ней какие-то пользователи, цифры процессов 1С которых разнообразнейше плавают в диспетчерах задач от 300 до 1800 МБ. Захотелось мне новый сервер завести - как память считать? 300 на RDP, к этому мы привыкли, а 1С как понять, когда working set одно, private другое, что-то там третье. Привыкли считать по столбцу в диспетчере задач, а он, оказывается, разное показывает от системы к системе. Получается, по peak working set считать, если с надёжным запасом?

Отображение памяти процесса 1С через ProcessExplorer
Отображение памяти процесса 1С через ProcessExplorer
Тот же процесс через диспетчер задач WS2008R2
Тот же процесс через диспетчер задач WS2008R2
Он же через VMMap
Он же через VMMap

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

Only those users with full accounts are able to leave comments. Log in, please.