Пользователь
0,0
рейтинг
6 ноября 2010 в 12:32

Here be dragons: Управление памятью в Windows как оно есть [1/3]


Каталог:
Один
Два
Три

Менеджер памяти (и связанные с ним вопросы контроллера кеша, менеджера ввода/вывода и пр) — одна из вещей, в которой (наряду с медициной и политикой) «разбираются все». Но даже люди «изучившие винду досконально» нет-нет, да и начинают писать чепуху вроде (не говоря уже о другой чепухе, написанной там же):
Грамотная работа с памятью!!! За все время использования у меня своп файл не увеличился ни на Килобайт. По этому Фаерфокс с 10-20 окнами сворачивается / разворачивается в/из трея как пуля. Такого эффекта я на винде добивался с отключенным свопом и с переносом tmp файлов на RAM диск.

Или к примеру μTorrent — у меня нет никаких оснований сомневаться в компетентности его авторов, но вот про работу памяти в Windows они со всей очевидностью знают мало. Не забываем и товарищей, производящих софт для слежения за производительностью и не имеющих ни малейшего понятия об управлении памятью в Windows (и поднявших по этому поводу истерику на пол интернета, на Ars-е даже был разбор полетов). Но самое потрясающее, что я видел всвязи с управлением памятью — это совет переместить pagefile на RAM-диск:
Из моих трех гигабайт под RAM disk был выделен один (на тот момент, когда на лаптопе еще была установлена XP), на котором я создал своп на 768МБ ...

Цель данной статьи — не полное описание работы менеджера памяти (не хватит ни места ни опыта), а попытка пролить хоть немного света на темное царство мифов и суеверий, окружающих вопросы управления памятью в Windows.


Disclaimer


Сам я не претендую на то, чтобы знать все и никогда не ошибаться, поэтому с радостью приму любые сообщения о неточностях и ошибках.

Введение


С чего начать не знаю, поэтому начну с определений.

Commit Size — количество памяти, которое приложение запросило под собственные нужды.
Working Set (на картинке выше он так и называется Working Set) — это набор страниц физической памяти, которые в данный момент «впечатаны» в адресное пространство процесса. Рабочий набор процесса System принято выделять в отдельный «Системный рабочий набор», хотя механизмы работы с ним практически не отличаются от механизмов работы с рабочими наборами остальных процессов.
И уже здесь зачастую начинается непонимание. Если присмотреться, можно увидеть, что Commit у многих процессов меньше Working Set-а. То есть если понимать буквально, «запрошено» меньше памяти, чем реально используется. Так что уточню, Commit — это виртуальная память, «подкрепленная» (backed) только физической памятью или pagefile-ом, в то время как Working Set содержит еще и страницы из memory mapped файлов. Зачем это делается? Когда делается NtAllocateVirtualMemory (или любые обертки над heap manager-ом, например malloc или new) — память как бы резервируется (чтоб еще больше запутать, это не имеет никакого отношения к MEM_RESERVE, который резервирует адресное пространство, в данном же случае речь идет о резервировании именно физических страниц, которые система действительно может выделить), но физические страницы впечатываются только при фактическом обращении по выделенному адресу виртуальной памяти. Если позволить приложениям выделить больше памяти, чем система реально может предоставить — рано или поздно может случиться так, что все они попросят реальную страницу, а системе неоткуда будет ее взять (вернее некуда будет сохранить данные). Это не касается memory mapped файлов, так как в любой момент система может перечитать/записать нужную страницу прямо с/на диск(а).
В общем, суммарный Commit Charge в любой момент времени не должен превышать системный Commit Limit (грубо, суммарный объем физической памяти и всех pagefile-ов) и с этим связана одна из неверно понимаемых цифр на Task Manager-ах до Висты включительно.
Commit Limit не является неизменным — он может увеличиваться с ростом pagefile-ов. Вообще говоря, можно считать, что pagefile — это такой очень специальный memory mapped файл: привязка физической страницы в виртуальной памяти к конкретному месту в pagefile-е происходит в самый последний момент перед сбросом, в остальном же механизмы memory mapping-а и swapping-а очень схожи.

Working Set процесса делится на Shareable и Private. Shareable — это memory mapped файлы (в том числе и pagefile backed), вернее те части, которые в данный момент действительно представлены в адресном пространстве процесса физической страницей (это же Working Set в конце концов), а Private — это куча, стеки, внутренние структуры данных типа PEB/TEB и т.д. (опять таки, повторюсь на всякий случай: речь идет только той части кучи и прочих структур, которые физически находятся в адресном пространстве процесса). Это тот минимум информации, с которой уже можно что то делать. Для сильных духом есть Process Explorer, который показывает еще больше подробностей (в частности какая часть вот той Shareable действительно Shared).

И, самое главное, ни один из этих параметров по отдельности не позволяет сделать более менее полноценных выводов о происходящем в программе/системе.

Task Manager


Столбец «Memory» в списке процессов и практически вся вкладка «Performance» настолько часто понимаются неправильно, что у меня есть желание, чтоб Task Manager вообще удалили из системы: те, кому надо смогут воспользоваться Process Explorer-ом или хотя бы Resource Monitor-ом, всем остальным Task Manager только вредит. Для начала, собственно о чем речь


Начну с того, о чем я уже упоминал: Page File usage. XP показывает текущее использование pagefile-а и историю (самое забавное, что в статус баре те же цифры названы правильно), Виста — показывает Page File (в виде дроби Current/Limit), и только Win7 называет его так, чем оно на самом деле является: Commit Charge/Commit Limit.
Эксперимент. Открываем таск менеджер на вкладке с «использованием пейджфайла», открываем PowerShell и копируем в него следующее (для систем, у которых Commit Limit ближе, чем на 3 Гб от Commit Charge можно в последней строчке уменьшить 3Gb, а лучше увеличить pagefile):

add-type -Namespace Win32 -Name Mapping -MemberDefinition @"
[DllImport("kernel32.dll", SetLastError = true)]
public static extern IntPtr CreateFileMapping(
    IntPtr hFile,
    IntPtr lpFileMappingAttributes,
    uint flProtect,
    uint dwMaximumSizeHigh,
    uint dwMaximumSizeLow,
    [MarshalAs(UnmanagedType.LPTStr)] string lpName);
    
[DllImport("kernel32.dll", SetLastError = true)]
public static extern IntPtr MapViewOfFile(
    IntPtr hFileMappingObject,
    uint dwDesiredAccess,
    uint dwFileOffsetHigh,
    uint dwFileOffsetLow,
    uint dwNumberOfBytesToMap);    
"@
 
$mapping = [Win32.Mapping]::CreateFileMapping(-1,  0, 2, 1,  0, $null)
[Win32.Mapping]::MapViewOfFile($mapping, 4,  0,  0, 3Gb)

Это приводит к мгновенному повышению «использования свопфайла» на 3 гигабайта. Повторная вставка «использует» еще 3 Гб. Закрытие процесса мгновенно освобождает весь «занятый свопфайл». Самое интересное, что, как я уже говорил memory mapped файлы (в том числе и pagefile backed) являются shareable и не относятся к какому либо конкретному процессу, поэтому не учитываются в Commit Size никакого из процессов, с другой стороны pagefile backed секции используют (charged against) commit, потому что именно физическая память или пейджфайл, а не какой нибудь посторонний файл, будут использоваться для того, чтобы хранить данные, которые приложение захочет разместить в этой секции. С третьей стороны, после меппинга секции себе в адресное пространство, процесс не трогает ее — следовательно, физические страницы по этим адресам не впечатываются и никаких изменений в Working Set процесса не происходит.

Строго говоря, пейджфайл действительно «используется» — в нем резервируется место (не конкретное положение, а именно место, как размер), но при этом реальная страница, для которой это место было зарезервировано может находиться в физической памяти, на диске или И ТАМ И ТАМ одновременно. Вот такая вот циферка, признайтесь честно, сколько раз глядя на «Page File usage» в Task Manager-е Вы действительно понимали, что она означает.

Что же до Processes таба — там все еще по дефолту показывается Memory (Private Working Set) и несмотря на то, что он называется совершенно правильно и не должен вызывать недоразумений у знающих людей — проблема в том, что подавляющее большинство людей, которые смотрят на эти цифры совершенно не понимают, что они означают. Простой эксперимент: запускаем утилилиту RamMap (советую скачать весь комплект), запускаете Task Manager со списком процессов. В RamMap выбираете в меню Empty->Empty Working Sets и смотрите на то, что происходит с памятью процессов.

Если кого-то все еще раздражают циферки в Task Manager-е, можете поместить следующий код в профайл павершелла:
add-type -Namespace Win32 -Name Psapi -MemberDefinition @"
[DllImport("psapi", SetLastError=true)]
public static extern bool EmptyWorkingSet(IntPtr hProcess);    
"@
 
filter Reset-WorkingSet {
    [Win32.Psapi]::EmptyWorkingSet($_.Handle)
}
 
sal trim Reset-WorkingSet

После чего станет возможно «оптимизировать» использование памяти одной командой, например для «оптимизации» памяти, занятой хромом: ps chrome | trim
Или вот «оптимизация» памяти всех процессов хрома, использующих больше 100 Мб физической памяти: ps chrome |? {$_.WS -gt 100Mb} | trim
Если хотя бы половина прочитавших отметет саму идею о подобной «оптимизации», как очевиднейший абсурд — можно будет сказать, что я не зря старался.

Кеш


В первую очередь отмечу, что кеш в Windows не блочный, а файловый. Это дает довольно много преимуществ, начиная от более простого поддержания когерентности кеша например при онлайн дефрагментации и простого механизма очистки кеша при удалении файла и заканчивая более консистентными механизмами его реализации (кеш контроллер реализован на основе механизма memory mapping-а), возможностью более интеллектуальных решений на основе более высокоуровневой информации о читаемых данных (к примеру интеллектуальный read-ahead для файлов открытых на последовательный доступ или возможность назначать приоритеты отдельным файловым хендлам).
В принципе из недостатков я могу назвать только значительно более сложную жизнь разработчиков файловых систем: слышали о том, что написание драйверов — это для психов? Так вот, написание драйверов файловых систем — для тех, кого даже психи считают психами.

Если же описывать работу кеша, то все предельно просто: когда файловая система запрашивает у кеш-менеджера какую нибудь часть файла, последний просто меппит часть этого файла в специальный «слот», описываемый структурой VACB (посмотреть все смепленные файлы можно из отладчика ядра с помощью расширения !filecache) после чего просто выполняет операцию копирования памяти (RtlCopyMemory). Происходт Page Fault, так как сразу после отображения файла в память все страницы невалидны и дальше система может либо найти необходимую страницу в одном из «свободных» списков либо выполнить операцию чтения.
Для того, чтобы понять рекурсию нужно понять рекурсию. Каким же образом выполняется операция чтения файла, необходимая для завершения операции чтения этого самого файла? Здесь опять все достаточно просто: пакет запроса на ввод/вывод (IRP) создается с флагом IRP_PAGING_IO и при получении такого пакета файловая система уже не обращается к кешу, а идет непосредственно к нижележащему дисковому устройству за данными. Все эти смепленные слоты идут в System Working Set и составляют ЧАСТЬ кеша.

Страница из лекции какого то токийского университета (эх, мне бы так):


На этом работа собственно кеш-менеджера заканчивается и начинается работа менедера памяти. Когда выше мы делали EmptyWorkingSet это не приводило ни к какой дисковой активности, но тем не менее, физическая память используемая процессом сокращалась (и все физические страницы действительно уходили из адресного пространства процесса делая его почти полностью невалидным). Так куда же она уходит после того, как отбирается у процесса? А уходит она, в зависимости от того, соответствует ли ее содержимое тому, что было прочитано с диска, в один из двух списков: Standby (начиная с Висты это не один список, а 8, о чем позже) или Modified:

Standby список таким образом — это свободная память, содержащая какие то данные с диска (в том числе возможно и pagefile-а).
Если Page Fault происходит по адресу, который спроецирован на часть файла, которая все еще есть в одном из этих списков — она просто возвращается обратно в рабочий набор процесса и впечатывается по искомому адресу (этот процесс называется softfault). Если нет — то, как и в случае со слотами кеш менеджера, выполняется PAGING_IO запрос (называется hardfault).
Modified список может содержать «грязные» страницы достаточно долго, но либо когда размер этого списка чрезмерно вырастает, либо по когда система видит недостаток свободной памяти, либо по таймеру, просыпается modified page writer thread и начинает частями сбрасывать этот список на диск, и перемещая страницы из modified списка в standby (ведь эти страницы опять содержат неизмененную копию данных с диска).

Upd:
Пользователь m17 дал ссылки на выступление Руссиновича на последнем PDC на ту же тему (хм, я честно его до этого не смотрел, хотя пост во много перекликается). Если понимание английского на слух позволяет, то чтение данного топика можно заменить прослушиванием презентаций:
Mysteries of Windows Memory Management Revealed, Part 1 of 2
Mysteries of Windows Memory Management Revealed, Part 2 of 2

Пользователь DmitryKoterov подсказывает, что перенос пейджфайла на RAM диск иногда действительно может иметь смысл (вот уж никогда б наверное и не догадался, если б не написал топик), а именно, если RAM-диск использует физическую память, недоступную остальной системе (PAE + x86 + 4+Gb RAM).

Пользователь Vir2o в свою очередь подсказывает что хотя при некоторых условиях и пожертвовав стабильностью системы ram-диск, использующий физическую память, невидимую остальной системе написать можно, но такое очень маловероятно.
@amirul
карма
465,7
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (84)

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

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

      ЗЫ надо чтоб автор стал №1 — все-таки ресурс не для фотографий кресел…
      • +6
        Я предлагал пару месяцев назад — всем похоже индифферентно:

        habrahabr.ru/blogs/ilhh/104721/
      • НЛО прилетело и опубликовало эту надпись здесь
        • –1
          WIN!
    • +5
      Уровень — да, я считаю любой программист обязан это знать. Но вот новичкам читать будет тяжело, тексту ещё бы пару дней в черновиках надо, чтобы стиль и оформление подкрутить.

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

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

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


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

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

            Есть предположение, что автор имел в виду то, что перемещение свопа в оперативную память равносильно его отключению (лишняя «прослойка»). Я правильно понимаю?
            • +30
              Ну какой в этом вообще может быть смысл? Вы работаете, у вас на столе бумаги, разные книги, в какой-то момент вы решаете, что вам не хватает места и вы прибиваете над столом полочку, куда складываете редко используемые книги. Через некоторое место замечаете, что до полочки слишком долго тянутся, снимаете её и кладете на стол. У вас стало больше места на столе?
          • +3
            А если это ОЗУ не доступно для системы? XP 32бита не видит ничего выше 3гб. А памяти допустим 4гб. Пускай 786мб пропадают?
            • 0
              Эти 786 мб неадресуемы, в т.ч. и неадресуемы для того, чтобы их использовать для pagefile.
              • +4
                Адресуемы. У меня 8гб на XP 32bit. Рамдиск на 4300мб. Там правда не только pagefile, все кэши, темпы и т.д.
                • +1
                  Но при этом hibernate ведь не работает?
      • +10
        > Перенос файла подкачки на рамдиск — не может помочь в принципе. То есть вообще никогда.
        Вы ошибаетесь. 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Г.
        • +1
          Рекомендую подробности этой небезынтересной конфигурации памяти переопубликовать также и на Хабрахабре.
        • –3
          Лушче отключить файл подкачки, чем переносить его в RAM
          • +3
            Аргументируйте, пожалуйста. Только в контексте «32-битная Windows не видит памяти свыше 2.5Г (или выше 3Г плюс-минус — все зависит от конфигурации железа). Включенный режим PAE + файл подкачки на RAM-диске позволяют оставшиеся 1.5Г использовать хоть как-то.»
        • +1
          Согласен с Мицголом, надо написать топик. В рамках недели просвещения на Хабре.
          • 0
            А мне кажется, что там нечего особенно писать — ссылки достаточно, это не rocket science.
            • +1
              Ну с тестами надо для доказательства. Я вот хотел про пользу от рам диска для компиляции написать — так провёл кое какие тесты с сорцами FireFox и писать передумал — ибо оказалось не о чем.
              • 0
                Отрицательный результат — тоже результат )
              • 0
                С доказательствами того, что запись в RAM-диск на несколько порядков быстрее, чем запись на диск (даже SSD)? Мне кажется, это излишне.
                • 0
                  Я повторюсь, я тоже думал что компиляция на рам диске сильно быстрее чем на hdd. Однако разница была:
                  ALL IN RAM = 1915 seconds
                  ALL ON HDD = 1945 seconds
                  ALL — это всё, исходники объёктники и temp.
                  • +1
                    Это совершенно ожидаемо — запись на диск ОС производит отложено: когда памяти много, почти нет разницы, куда пишется — на RAM-диск или на HDD. В случае с файлом подкачки это, очевидно, не так.
        • +1
          О таком сценарии не подумал — действительно имеет место быть. Добавил в апдейты
        • +1
          Либо я чего-то не понял, либо Вы тоже заблуждаетесь. Та память, которую «не видно» — это memory mapped I/O и области для доступа к видеокарте например, к ее памяти через адресное пространство оперативной. Так или иначе, эти адреса недоступны физически на уровне PCI-мостов, никакими ухищрениями с пейджингом увидеть их не получится. Это тот случай, когда памяти ровно 4 гига. Если памяти больше, скажем 8 гигов, тогда можно написать свой драйвер RAM-disk-а, который сможет использовать память выше 4 гигов (то что между 3,3 и 4 увидеть все-равно не получится) но смысла в этом никакого, тут надо ставить x64.
          У современных чипсетов есть такая фича — memory remap feature, которая позволяет отмапить часть оперативки в пространство выше 4Gb, на первый взгляд кажется, что это то что нужно, пишем свой драйвер, работающий с этой памятью и размещаем своп там, выше 4 гигов. На практике это опять же лишено всякого смысла, потому что для доступа к этой памяти нужен диапазон адресов в первых 4-х гигах, которые придется попросить из системного адресного пространства и вручную поправить таблицы страниц, но мы при этом забираем у системы виртуальные адреса, которые ей возможно нужнее, чем дополнительный своп, можно конечно каждый раз выделять/освобождать при каждом обращении к этому «свопу», но в этом еще меньше смысла.
          В общем я бы сказал так, теоретически при наличии должной поддержки со стороны желаза и в каком-то особом случае, когда известно что можно безболезненно забрать у системы часть системного виртуального адресного пространства, это может и принесет какую-то пользу, но всем и каждому я бы это не рекомендовал. Это примерно как кошке пятая нога иногда может быть полезна. Поправьте меня.
        • 0
          Позвольте с вами не согласиться!
          Включенный режим 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
          Сомневающимся настоятельно рекомендую написать простенькую программку своими руками. Это очень занимательно:)
          • –1
            Здесь и здесь
            Вкратце, PAE теоретически использовать можно, оно будет работать не всегда, часть физических адресов недоступна из-за меппинга пространства ввода/вывода и никакими способами ее не вытащить (адрес на шине адресует, к примеру видеокарту, а не память). Даже если ядро включает PAE (к примеру для включения NX) это не значит, что оно будет поддерживать PAE адресацию выше 4Gb (из-за лицензионных ограничений и некоторых глюков с драйверами PAE на клиентских 32-битных виндах не адресует больше 4Gb). Пытаться напрямую работать с директорией страниц чревато очень серьезными глюками. Завязывать драйвер RAM-диска на патченное ядро не имеет смысла.

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

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

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

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

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

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

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

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

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

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

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

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

                    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/
                    • +1
                      Ухтыха. Ради этого можно даже поставить оперу. Спасибо
                    • +1
                      Скачал, посмотрел. RamMap показывает, что память уходит в mapped file и даже показывает в какой (там кстати тоже приоритет 5, который выталкивает из памяти всех подряд), но вот почему эта памяти не отображается в Shared WS для меня загадка — надо будет поковырять
                      • 0
                        Она и в cached у task manager тоже почему-то не засчитывается. Какой-то очень странный mapped file :)
        • +1
          Кстати, еще интересно было бы узнать, менялся ли commit limit (когда кто-то выделяет non-paged pool — это не увеличивает commit charge, а уменьшает commit limit). В общем скриншот Process Explorer-овского system info мог бы помочь при выяснении причин
  • 0
    Странно, но эта и другие ваши статьи должна быть на хабре!

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.