System working set что это

Рабочий набор

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

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

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

Программный интерфейс «состояние процесса» (PSAPI) предоставляет ряд функций, возвращающих подробные сведения о рабочем наборе процесса. Дополнительные сведения см. в разделе сведения о рабочем множестве.

Источник

Программа RAMMap представляет собой утилиту, которая позволяет увидеть как Windows действительно распределяет оперативную память. Благодаря программе на оперативную память компьютера можно взглянуть как не на абстрактную сущность, а действительно составить представление о том, для чего и какими файлами она используется. Работает в версиях от Windows Vista и позднее.

Наиболее интересными для рядового пользователя, наверное, окажутся лишь некоторые из вкладок. Это Use Counts и File Details. Однако для полноты понимания как программа работает, от пользователя требуется понимание работы RAM в принципе.

Теоретические абзацы

Все процессы пользовательского режима и большинство процессов от имени ядра получают доступ к данным через адреса виртуальной памяти. Эти данные и исполняемый код могут находиться как в ячейках физической памяти планок RAM, так и в файле подкачки жёсткого диска, но все они объединены одним условием — в момент запуска система приклеивает их к рабочему набору конкретного процесса, который в данный момент чем-то занимается (то есть читает, записывает и выполняет). И утилита RAMMap подходит к памяти как к общесистемному источнику памяти, который распределяется между запущенными в Windows процессами.

Интерфейс RAMMap

Окно программы представляет из себя интерфейс, напоминающий чем-то Диспетчер задач Windows NT, и включает в себя вкладки (во время работы обновляем состояние позиций клавишей F5):

Посмотрим на каждую из вкладок RAMMap внимательнее.

Use counts

Посмотрим на столбцы вкладки Use Counts

Processes

Вкладка содержит анализ страниц физической памяти, которые ассоциируются с конкретным процессом. Здесь мы можем увидеть номер сессии процесса в текущем сеансе (Session), присвоенный процессу номер (PID). Остальные столбцы вдоль каждого процесса показывают какую часть RAM, выделяемого для этого процесса, занимают страницы пользователя или/и системы: по показаниям в этой вкладке можно судить о том, от чьего имени процесс запущен, не «кривит» ли память. Столбец Page Table показывает общее количество памяти, выделяемой ядром этому процессу. Total суммирует показания по столбцам с Private по Page Table (именно показатель Total и отображается в Windows-ском Диспетчере задач). Однако Диспетчер в окне по умолчанию суммирует всё, что запущено от имени одной службы/программы. Надо лишь развернуть характерный столбец:

Priority Summary

Вкладка отображает объёмы памяти, выделяемые/выделяемых на процессы по присвоенному системой приоритету с момента включения компьютера. Самая интересная здесь вкладка — Repurposed. Она показывает, сколько памяти было отозвано у других задач для удовлетворения нужд более приоритетных процессов с момента запуска Windows. Идеальный вариант с эффективно работающей системой — этот столбец по «нолям». Этого достичь, однако, почти нереально. Более того, высокие числа в этом столбце с процессами в высоком приоритете (с 5-го и выше) говорят о том, что ресурсов системе либо не хватало, либо не хватает до сих пор: впору задуматься о приобретении дополнительной планки:

установленного объёма RAM явно недостаточно для выполнения некоторых задач

Physical Ranges

Следующая вкладка (чисто информационная) отображает эффективные диапазоны адресов физической памяти. Разрывы в диапазонах отображают физические адреса, закреплённые за определёнными устройствами.

File Summary

В этой вкладке отображается полный путь к файлам, отнесённым системой в память. Столбцов несколько: Total — общая сумма, Active — на данный момент, Standby — готовая примкнуть и т.д. Сюда попадает всё: от файлов загрузчика до драйверов для мыши и клавиатуры. Можно взглянуть пристальнее, проранжировав столбцы по имени, месту запуска и т.п.

File Details

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

Помимо информативной части вкладок, по которым можно судить о том, как Windows справляется с запускаемыми процессами, разнося задачи по страницам памяти, и выискивая пропажу гигабайт оперативки, в шапке RAMMap имеется кнопка действий, позволяющая принудительно «изымать» страницы памяти. Как вы понимаете, этот процесс ничего общего с принудительной остановкой какого-то процесса через Диспетчер задач не имеет. Так, нажав по кнопке Empty (Очистить) программы:

взору откроются пять основных команд очистки страниц памяти RAM, работа с которыми сейчас конкретными процессами не ведётся, и которым после очистки может быть присвоен иной статус, что, в свою очередь, позволит им включиться в работу уже в составе приложения, которому, быть может, как раз сейчас памяти и не хватает. Далее по списку вниз:

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

RAMMap — анализ и сохранение результатов

Для работы с системой не обязательно работать с окном непосредственно до эксперимента и после. Разработчики предлагают поместить исполнительный файл программы в папку с другими системными утилитами Windows/System32 и запускайте через cmd от имени администратора:

RAMMap фоном проверит состояние памяти и сохранит данные в файл 1.rmp в той же директории. Чтобы открыть сохранённый вами или присланный на анализ файл, можно запустить cmd с таким скриптом:

или для владельцев Windows 64-x, помогающим 32-х битным соратникам (а вот из 32-х битной версии файлы с 64-х-«битки» уже не прочитать):

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

Источник

Увеличение рабочего набора процесса

Относится к:

Описывает лучшие методы, расположение, значения, управление политикой и соображения безопасности для параметра Increase a process working set security policy.

Справочники

Этот параметр политики определяет, какие пользователи могут увеличивать или уменьшать размер рабочего набора процесса. Рабочий набор процесса — это набор страниц памяти, видимых в настоящее время для процесса в физической оперативной памяти. Эти страницы являются резидентами, и они доступны для использования приложения, не запуская ошибку страницы. Минимальные и максимальные размеры рабочих наборов влияют на поведение виртуальной карты памяти процесса.

Возможные значения

Рекомендации

Location

Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Значения по умолчанию

По умолчанию стандартные пользователи имеют это право.

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

Управление политикой

В этом разделе описаны компоненты, средства и рекомендации, которые помогут в управлении этой политикой.

Для активации этого параметра политики не требуется перезагрузка компьютера.

Изменения прав пользователя вступают в силу при его следующем входе в учетную запись.

Групповая политика

Параметры применяются в следующем порядке с помощью объекта групповой политики (GPO), который перезаписывал параметры на локальном компьютере при следующем обновлении групповой политики:

Когда локальный параметр серый, он указывает, что GPO в настоящее время контролирует этот параметр.

Вопросы безопасности

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

Уязвимость

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

Противодействие

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

Возможное влияние

Нет. Разрешение стандартным пользователям увеличивать рабочий набор процесса — это конфигурация по умолчанию.

Источник

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

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

Менеджер памяти (и связанные с ним вопросы контроллера кеша, менеджера ввода/вывода и пр) — одна из вещей, в которой (наряду с медициной и политикой) «разбираются все». Но даже люди «изучившие винду досконально» нет-нет, да и начинают писать чепуху вроде (не говоря уже о другой чепухе, написанной там же):

Грамотная работа с памятью. За все время использования у меня своп файл не увеличился ни на Килобайт. По этому Фаерфокс с 10-20 окнами сворачивается / разворачивается в/из трея как пуля. Такого эффекта я на винде добивался с отключенным свопом и с переносом tmp файлов на RAM диск.

Цель данной статьи — не полное описание работы менеджера памяти (не хватит ни места ни опыта), а попытка пролить хоть немного света на темное царство мифов и суеверий, окружающих вопросы управления памятью в 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):

Это приводит к мгновенному повышению «использования свопфайла» на 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-е, можете поместить следующий код в профайл павершелла:

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

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

На этом работа собственно кеш-менеджера заканчивается и начинается работа менедера памяти. Когда выше мы делали 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-диск, использующий физическую память, невидимую остальной системе написать можно, но такое очень маловероятно.

Источник

Проблема высокой загрузки памяти системным файловым кэшем на Windows Server 2008 R2

На одном из файловых серверов под управлением Windows Server 2008 R2 обнаружилась проблема с высокой загрузки оперативной памяти (RAM), выливающаяся в проблемы с производительностью сервера и запущенных на нем служб. Как оказалось, память забивалась системным файловым кэшем с метаданными файловой системы. Проблеме потенциально подвержены все файловые сервера с большим количеством файлов, к которым обращаются пользователя. Наиболее критична проблема для 64 битных версий Windows, на которых размер метафайла в памяти может занять практически всю емкость установленной оперативной памяти. В статье разберемся как проявляется проблема, выявим ее источники и способы решения.

Высокая загрузка оперативной памяти на файловом сервере Windows

Проблема проявляется следующим образом: в диспетчере задач (Task Manager) видим, что на сервере оперативная память занята на 95-99%.

Перейдя на вкладку процессов, не удастся найти какой-то утекший процесс с аномально высоким потреблением памяти. Кроме того, если навскидку сложить память, занятую всеми процессами, отображаемыми в диспетчере задач, даже близко не удается приблизиться к 50% физической памяти, установленной на сервере. Так кто же съел всю память?

Реальный расклад по использованию оперативной памяти может дать утилита RAMMap (Марка Руссиновича). Качаем архив с утилитой и запускаем из архива файл RAMMap.exe с правами администратора. На вкладке Use Counts, видим, что больше всего физической памяти использует объектом Metafile (в нашем случае на него приходится 11 из 25 Гб оперативной памяти сервера).

Что такое метафайл в Windows?

Метафайл (Metafile) — это часть системного кэша, который содержит метаданные файловой системы NTFS и используется для увеличения быстродействия файловой системы при доступе к файлам. Метаданные NTFS включают в себя данные таблицы MFT (Master File Table). Для каждого файла/папки, к которому обращались пользователи, в метафайле создается соответствующий блок, размером как минимум 1 Кб (запись об атрибуте каждого файла занимает 1кб, и каждый файл имеет как минимум один атрибут). Таким образом, на файловых серверах с большим количеством файлов, к которым идут постоянные обращения, размер системного кэша NTFS (метафайла) может достигать нескольких гигабайт.

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

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

К примеру, оценить размер MFT таблицы можно с помощью еще одной утилиты Руссиновича – ntfsinfo. К примеру, в нашем примере для 2 Тб диска размер MFT таблицы составляет 13 Гб.

Быстрая очистка метафайла MFT в памяти

Основной недостаток такого метода – процесс очистки ручной и никак не автоматизируется.

Служба Dynamic Cache Service для управления файловым кэшем

Другим, более кардинальным, решением проблемы высокой загрузки оперативной памяти метафайлом файловой системы является установка службы Dynamic Cache Service (http://www.microsoft.com/en-us/download/details.aspx?id=9258). Данная служба через системные API позволяет управлять параметрами выделяемого кэша.

Установка DynCache довольно простая (подробные инструкции есть в архиве с программой).

В нашем случае, после установки службы DynCache, использование памяти метафайлом перестало превышать заданного нами значения 4 Гб. Пользователи каких-либо проблем с ухудшением производительности файлового сервера не выявили.

Источник