Вопрос по оперативной памяти

[Don Leno]

К примеру у меня есть приложение которое написано на vb и весит это добро - 2 Мегабайта. Сколько при запуске этой проги, будет занято места в оперативной памяти?
Если приложение использует Апи функцию из Длл к примеру с названием My.dll. В длл несколько функций и весит она - 1 Мегабайт. Сколько будет занято оперативной памяти в случае вызова Апи функций из моей программы?

[Хакер]

Оперативную память как термин оставим для детей в детском саду.

Есть физическая память.
Есть виртуальное адресное пространство процесса.

О чём вопрос?

[Don Leno]

Хакер ты меня озадачил? Мне надо чтобы прога меньше нагружало оперативку. Скорее всего физическуб память.

[bon818]

О чём вопрос?

Вопрос как раз понятен, можно сказать смешной вопрос.
Он хочет знать, есть ли какая-нить зависимость между размером исполняемого файла и занимаемого им размера в оперативной памяти(потребление).
Ответ : нет такой зависимости!
Проще это узнать в диспетчере задач сколько потребляет твоя прога.

[Don Leno]

Уже что-то Мож кто еще чего интересного напишет...

[Don Leno]

А можно заранее узнать сколько прога будет хавать оперативы?

[Хакер]

Вопрос как раз понятен, можно сказать смешной вопрос.

Не надо писать ерунду.

Он хочет знать, есть ли какая-нить зависимость между размером исполняемого файла и занимаемого им размера в оперативной памяти(потребление).
Ответ : нет такой зависимости!

Не надо писать ерунду.

Он хочет знать, есть ли какая нибудь зависимость между «А» и «Б», при этом сам по себе термин «Б» лишён всякого смысла. На такой вопрос несуществует осмысленного ответа.

Люди, которые на вопрос «сколько килограммов весят двадцать миль в час» бросаются давать какие-то ответы, отличные от ответа «вопрос лишён смысла» — меня бесят. Они считают это круто, что они, давая какие-то там заведомо неправильные ответы, помогают другим людям, что это классно. Это не классно. Это не помощь. Это вредительство и лишённый смысла поток информации.

Единственно правильный ответ такой:

Когда модуль (не важно, EXE или DLL) загружается в АП процесса, затраты будут следующими:

• В виртуальном адресном пространстве процесса будет зарезервировано (но не выделено) столько страниц памяти, сколько составляет величина поля SizeOfImage из OptionalHeader-а, округлённая вверх до границы в 64 кб, потому что память всегда резервируется блоками, кратными 64 кб и выровненными по границе 64 кб.
  
• В виртуальном адресном пространстве процесса будет выделено столько страниц памяти, сколько составляет величина поля SizeOfImage из OptionalHeader-а.
  
• Из этого числа страниц, часть страниц будет image-backed, а часть страниц будет swap-backed. Image-backed страницы не занимают места в файле подкачки (в файлах подкачки, если их несколько). Swap-backed страницы — занимают. Количество всех swap-backed страниц во всех процессах в сумме не может превысить размер файла подкачки (размер всех файлов подкачки, если их несколько). В данном случае из всех выделенных страниц, описанных в предыдущем пункте, количество swap-backed страниц будет равно числу страниц спроецированного образа, на которые приходятся: так называемые фрагменты «неинициализированных данных» в составе секций, и страниц, модифицированных в результате простановки адресов в IAT и резолвинга релоков (и прочих модификаций страниц при загрузке). Остальные страницы будут image-backed, в роли backing storage будет EXE или DLL-файл.
  
• Количество страниц, которые после загрузки образа окажутся в физпамяти, постоянно меняется: одни страницы загружаются в физпамять, другие выгружаются, в физпамяти лежат все страницы всех процессов вперемешку одновременно. Программе не должно быть никакого дела до этог аспекта, т.к. код программ полностью абстрагирован от этого и вообще изолирован от факта существования физ. памяти (кроме аспекта использования AWE).
  
• Параллельно с этим, при загрузке модуля в ядре будут создаваться служебные структуры, что так же съест некоторую часть страниц АП ядра, фреймов файла подкачки и в какой-то степени — физической памяти.
  
• Кроме того, если речь идёт о загрузке EXE-файла, то будет зарезервирована память под стек в объёме, равном значению поля SizeOfStackReserve (с округлением вверх до границы 64 кб), и из этого объёма старниц будет выделено страниц в объёме, равном значению поля SizeOfStackCommit + 1 страница. Аналогичная ситуация с кучей по-умолчанию (default process heap) за исключением «плюс одной страницы». Все 4 поля принадлежат OptionalHeader-у в заголовочной части PE-файла.
  
• Дальше управление рано или поздно будет передано в точку входа загруженного PE-модуля, и её код зарезервирует и выделит столько памяти, сколько ему нужно.
  
• В дальнейшем, любые изменения в страницы загруженного модуля, которые всё ещё оставались image-backed, будут переводить эти страницы в swap-backed тип, и эти страницы будут начинать занимать место в файле подкачки, а я напоминаю, что все процессы в сумме не могут иметь объём swap-backed страниц превышающий объём файла подкачки.
  
• Все дальнейшие операции выделения (закоммичивания) страниц с помощью VirtualAlloc будут отнимать место в файле подкачки. Аналогично с любыми функциями, которые являются надстройками над VirtualAlloc.
  
• Все дальнейшие операции резервирования страниц с помощью VirtualAlloc будут только фрагментировать адресное пространство процесса (и VAD-структуры, поддерживаемые для АП ядром), но эти страницы не будут занимать места нигде: ни в файле подкачки, ни в физической памяти. Это чисто юридический формальный математический жест общения между прикладной программой и ОС.
  
• Все страницы АП процесса, оказавшиеся там в результате вызова MapViewOfFile, будут являться image-backed страницами, и соответственно не будут занимать место в файле подкачки, и даже при модификации будут оставаться такими, кроме случая, когда им присвоен атрибут copy-on-write, в случае чего они при модификации будут становится page-backed-страницами.
  
• Часть всех выделенных (и page-backed, и swap-backed) страниц виртуального АП процесса всегда присутствует в физпамяти, причём в данный момент присутствуют только те из них, к которым сейчас или сравнительно недавно было обращение, причём всё подмножество страниц АП одного процесса, представленных в данный момент в ФП, называется working-set-ом (рабочим набором), и размер рабочего набора меняется по хожу работу в некоторых пределах.

Диспетчер задач, которым тут так уверенно предлагает пользоваться bon818, показывает кучу слабо связанных между собой величин, которые к тому же и подписаны часто неправильно:

• Данные по использованию физпамяти всеми процессами и ядром
• Суммарное кол-во всех swap-backed страниц всех процессов (включая ядро) — большой зелёный столбик
• В таблице процессов: сумма всех swap-backed страниц.
• В таблице процессов: текущий размер working-set-а процесса

Как видишь, там нет таких показателей, как кол-во всех закоммиченных страниц АП, кол-во зарезервированных блоков (размером по 64К).

[Don Leno]

Хакер спс за такой широкомасштабный ответ. Но для нубов в этом деле можно как нить простым языком плиз!!!

[Хакер]

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

Нельзя. Изучай устройство памяти.

Та же информация но в менее сумбурном изложении: viewtopic.php?f=44&t=28535

[bon818]

Люди, которые на вопрос «сколько килограммов весят двадцать миль в час» бросаются давать какие-то ответы, отличные от ответа «вопрос лишён смысла» — меня бесят. Они считают это круто, что они, давая какие-то там заведомо неправильные ответы, помогают другим людям, что это классно. Это не классно. Это не помощь. Это вредительство и лишённый смысла поток информации.

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

[Qwertiy]

Оперативную память как термин оставим для детей в детском саду.

Да ладно...

все процессы в сумме не могут иметь объём swap-backed страниц превышающий объём файла подкачки

А что в случае, когда объём файла подкачки меньше объёма физической памяти?

Сколько при запуске этой проги, будет занято места в оперативной памяти?

Столько, сколько потребуется. Зависимости между размером exe-файла и потребляемой памятью нет.

[Хакер]

например убежден вредно грузить начинающего программиста теорией, которая ему некогда не пригодится и запутает окончательно

Значит, когда ребёнок спросит, почему небо голубое, ты расскажешь ему не про рэлеевское рассеяние, а про то, что волшебная фея Лиухан-Лджы любила много цветов, но голубой был её наиболее любимым?

Тфу.

И плевать, что ребёнок не поймёт сразу, что такое «рэлеевское рассеяние», у него сам термин отложится и если ему сильно интересно, он уйдёт искать или читать сам. Сейчас, или через 3 года. Но направление поиска ты ему дашь.

Ты же своими нерелевантными ответами вместо того, что рассеивать тьму незнания, только укрепляешь у человека картину «это всё магия, просто прими это». Только вот ты не учитываешь, что это форум, а не приватный чат, и ответы читает не только тот, кто спросил, а ещё и тысячи других людей, которые читают топик впоследствии. Они могут быть не начинающими, они могут быть ищущими правды, но нет же, надо дать людям фигню вместо знания.

[Хакер]

А что в случае, когда объём файла подкачки меньше объёма физической памяти?

То же самое.

[Qwertiy]

Значит, когда ребёнок спросит, почему небо голубое, ты расскажешь ему не про рэлеевское рассеяние, а про то, что волшебная фея Лиухан-Лджы любила много цветов, но голубой был её наиболее любимым?

Зачем такие крайности-то?

То же самое.

Это странно... Какой тогда смысл от файла подкачки, если он меньше объёма физической памяти?
Кстати, если на все страницы на диске и так есть место (либо в файле подкачки, либо в файлах образов), то зачем для гибирнации нужен отдельный файл объёмом с оперативную память?

[Хакер]

Зачем такие крайности-то?

Почему крайности. Заранее понятно, что ребёнок, спрашивающий про цвет неба, не знает сути механизма рэлеевского рассеяния. Тем не менее, считаю важным сказать именно про него, нежели вешать на уши лапшу. Пусть ребёнок дальше либо сам сам идёт разбирается, либо спрашивает «а что такое рэлеевское рассеяние и как оно работает». С радостью расскажу.

Вот так и тут. Я по вопросу вижу сразу, что человек абсолютно не разбирается в устройстве виртуальной памяти. Тем не менее, я пишу правдивые вещи. Дальше либо пусть сам разбирается, либо задаёт встречные вопросы. С радостью отвечу.

Это странно... Какой тогда смысл от файла подкачки, если он меньше объёма физической памяти?

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

Кстати, если на все страницы на диске и так есть место (либо в файле подкачки, либо в файлах образов), то зачем для гибирнации нужен отдельный файл объёмом с оперативную память?

О, это хороший вопрос.

Ключевой момент здесь в том, что подчёркнутое утверждение — абсолютно ложное.

Если идти снизу вверх:
Страницы физпамяти, в которых располагаются PDE→PTE-деревья, необходимые для преобразования линейных адресов в физические — не выгружаются в файл подкачки.
Страницы физпамяти, в которых располагаются структуры, описывающие файлы подкачки — не выгружаются в своп.
Страницы памяти, в которых живёт код, который подгружает недостающие страницы из файла подкачки — никогда не выгружается в своп.
Загруженные образы драйверов, вовлечённых в работу своппинга, такие как шинные драйверы, драйверы дисков, драйверы томов, драйверы файловых систем (они образуют цепочку обработки IRP для IO-операций, так необходимых для подкачки) — никогда не выгружаются в своп.

В ядро может быть загружено много драйверов, драйверы могут обладать невыгружаемыми секциями (кода, данных — не важно), в процессе работы они могут выделять память себе память с помощью ExAllocatePool (non-paged pool), или выделять себе MDL.

Что касается обычных пользовательских процессах, то в них страницы, полученные процессом через механизм AWE, — тоже никогда не выгружаются в своп и им не соответствует место в файлах подкачки.

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

Кроме того, чтобы гибернация была быстрой и гарантированной, она должна действовать по модели: сняли цельный образ всей памяти при засыпании — накатали обратно цельный образ всей памяти при просыпании.

Почему, к примеру, Alcohol 120% снимает образ диска одним файлом, а не просто копирует все файлы с диска?