Working Set

The working set of a process is the set of pages in the virtual address space of the process that are currently resident in physical memory. The working set contains only pageable memory allocations; nonpageable memory allocations such as Address Windowing Extensions (AWE) or large page allocations are not included in the working set.

When a process references pageable memory that is not currently in its working set, a page fault occurs. The system page fault handler attempts to resolve the page fault and, if it succeeds, the page is added to the working set. (Accessing AWE or large page allocations never causes a page fault, because these allocations are not pageable .)

A hard page fault must be resolved by reading page contents from the page’s backing store, which is either the system paging file or a memory-mapped file created by the process. A soft page fault can be resolved without accessing the backing store. A soft page fault occurs when:

• The page is in the working set of some other process, so it is already resident in memory.
• The page is in transition, because it either has been removed from the working sets of all processes that were using the page and has not yet been repurposed, or it is already resident as a result of a memory manager prefetch operation.
• A process references an allocated virtual page for the first time (sometimes called a demand-zero fault).

Pages can be removed from a process working set as a result of the following actions:

• The process reduces or empties the working set by calling the SetProcessWorkingSetSize, SetProcessWorkingSetSizeEx or EmptyWorkingSet function.
• The process calls the VirtualUnlock function on a memory range that is not locked.
• The process unmaps a mapped view of a file using the UnmapViewOfFile function.
• The memory manager trims pages from the working set to create more available memory.
• The memory manager must remove a page from the working set to make room for a new page (for example, because the working set is at its maximum size).

If several processes share a page, removing the page from the working set of one process does not affect other processes. After a page is removed from the working sets of all processes that were using it, the page becomes a transition page. Transition pages remain cached in RAM until the page is either referenced again by some process or repurposed (for example, filled with zeros and given to another process). If a transition page has been modified since it was last written to disk (that is, if the page is «dirty»), then the page must be written to its backing store before it can be repurposed. The system may start writing dirty transition pages to their backing store as soon as such pages become available.

Each process has a minimum and maximum working set size that affect the virtual memory paging behavior of the process. To obtain the current size of the working set of a specified process, use the GetProcessMemoryInfo function. To obtain or change the minimum and maximum working set sizes, use the GetProcessWorkingSetSizeEx and SetProcessWorkingSetSizeEx functions.

The process status application programming interface (PSAPI) provides a number of functions that return detailed information about the working set of a process. For details, see Working Set Information.

Increase a process working set

Applies to

Describes the best practices, location, values, policy management, and security considerations for the Increase a process working set security policy setting.

Reference

This policy setting determines which users can increase or decrease the size of the working set of a process. The working set of a process is the set of memory pages currently visible to the process in physical RAM. These pages are resident, and they are available for an application to use without triggering a page fault. The minimum and maximum working set sizes affect the virtual memory paging behavior of a process.

Possible values

• User-defined list of accounts
• Not Defined

Best practices

• You should make users aware that adverse performance issues may occur if they modify this security setting.

Location

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

Default values

By default, standard users have this right.

The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.

Server type or GPO	Default value
Default Domain Policy	Not Defined
Default Domain Controller Policy	Users
Stand-Alone Server Default Settings	Users
Domain Controller Effective Default Settings	Users
Member Server Effective Default Settings	Users
Client Computer Effective Default Settings	Users

Policy management

This section describes features, tools, and guidance to help you manage this policy.

A restart of the computer is not required for this policy setting to be effective.

Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.

Group Policy

Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:

1. Local policy settings
2. Site policy settings
3. Domain policy settings
4. OU policy settings

When a local setting is greyed out, it indicates that a GPO currently controls that setting.

Security considerations

This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.

Vulnerability

Increasing the working set size for a process decreases the amount of physical memory that is available to the rest of the system.

Countermeasure

Increase user’s awareness about the impact of increasing the working set of a process and how to recognize that their system is adversely affected if they change this setting.

Potential impact

None. Allowing standard users to increase the working set of a process is the default configuration.

Проблема высокой загрузки памяти системным файловым кэшем на 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 в памяти

Утилита RAMMap предоставляет возможность быстрой очистки используемой памяти от мусора без необходимости перезагрузки сервера. Для этого нужно в меню выбрать раздел Empty -> Empty System Working Set. После этой операции размер памяти под metafile уменьшился в десятки раз, а процент использования RAM сервером упал с 95% до 26%.

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

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

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

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

1. Копируем файл в DynCache.exe в каталог %SystemRoot%\System32
2. Создадим службу DynCache командой sc create DynCache binpath= %SystemRoot%\System32\DynCache.exe start= auto type= own DisplayName= «Dynamic Cache Service»
3. Импортируем файл DynCache.reg в реестр (содержит дефолтные значения)
4. Изменим значения следующих ключей реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DynCache\Parameters
   • MaxSystemCacheMBytes: 4096 (dec) – максимальный размер кэша
   • MinSystemCacheMBytes: 100 (dec) – минимальный размер

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

Оценка и настройка производительности приложений Windows NT Workstation 4.0

Если бы меня спросили, как до предела увеличить скорость работы Windows NT Workstation 4.0, я бы ответила так: выгрузите оболочку Explorer и работайте только с командной строкой, не запуская надоевшие графические приложения, — и Windows NT Workstation 4.0 понесется вскачь.

Обходные пути повышения производительности Windows NT Workstation 4.0

Если бы меня спросили, как до предела увеличить скорость работы Windows NT Workstation 4.0, я бы ответила так: выгрузите оболочку Explorer и работайте только с командной строкой, не запуская надоевшие графические приложения, — и Windows NT Workstation 4.0 понесется вскачь. Такой подход, который я называю «методика запрета излишеств», широко распространен среди поклонников UNIX, полагающих, и иногда справедливо, что графические приложения замедляют работу системы. Однако независимо от того, насколько быстро функционирует ядро операционной системы, Windows NT Workstation 4.0 все-таки работает в графической среде и запускает графические приложения. Поэтому в большинстве случаев отключить оболочку Windows Explorer, не жертвуя функциональностью, нельзя.

Исходя из этого, предлагаю подойти к проблемам оценки и настройки скорости работы приложений Windows NT Workstation 4.0 с другой стороны и попытаться получить от операционной системы максимум производительности иным способом. Так, для выявления ресурсоемких приложений можно использовать счетчики Performance Monitor, а также прибегнуть к помощи ряда утилит из Resource Kit, позволяющих оценить уровень производительности.

Почему именно Performance Monitor?

Performance Monitor — отличный инструмент для оценки производительности NT Workstation или NT Server. О том, как работать с ним в целях сбора информации о компьютере, можно узнать из документации Microsoft и специальной литературы. Однако я хочу обратить внимание на средства Performance Monitor, позволяющие оценивать производительность приложений. Особенно полезными мне представляются два его объекта: Process и Memory. Объект Process собирает информацию обо всех работающих процессах, будь то системные процессы, пользовательские процессы или службы Windows NT. Объект Memory собирает данные, описывающие компоненты подсистемы управления памятью Windows NT, включая файловый кэш, физическую память, а также несколько выгружаемых и невыгружаемых пулов памяти, которые Windows NT использует для системных процессов.

Хотя при оценке производительности Windows NT Workstation может возникнуть необходимость в определении скорости дисковых подсистем, я не буду останавливаться подробно на этой теме. Гораздо важнее разобраться, в чем корень проблемы и рассмотреть порядок использования приложением процессорных ресурсов и памяти, а также того, как этот порядок влияет на общую производительность системы.

Такие проблемы, как «пробуксовка» диска, зачастую являются симптомами некорректной работы самих приложений. Хотя интенсивный рост файла подкачки отчасти можно увязывать с медленной дисковой подсистемой или чрезмерно фрагментированным диском, в первую очередь следует выяснить первопричину этого явления. В Таблице 1 приведены объекты и счетчики, которые позволяют следить за работой приложения, и здесь же кратко описано их назначение. Если на основании показателей этих счетчиков создать файл рабочей области Performance Monitor (.pmw), то всегда можно быстро загрузить его для осуществления контроля за работой приложения. Однако следует помнить, что файлы рабочих областей содержат имя рабочей станции или сервера, на которых они были созданы. Поэтому после загрузки таких файлов на другом компьютере это имя необходимо скорректировать.

Контроль утечки памяти

Первые два счетчика в Таблице 1, Process:Working Set и Process: Pagefile Bytes, дают возможность контролировать уровень потребления памяти приложением. Счетчик Working Set — важный показатель эффективности работы программы, поскольку позволяет определить, сколько физической памяти (т. е. реальных страниц ОЗУ) она занимает. Постоянно отслеживая значение счетчика, можно обнаружить вызываемые приложением утечки памяти. Если, как показано на Экране 1, наблюдается постоянное увеличение показаний счетчика, значит, приложение не обеспечивает корректного освобождения ранее выделенной для него памяти. Однако при этом важно понимать алгоритм работы приложения. Например, если я оставлю в памяти компьютера не выполняющую никаких задач копию Microsoft Word, а ее рабочее пространство будет непрерывно увеличиваться, то можно быть уверенным, что Word инициирует утечки памяти. Однако, когда на моем компьютере функционирует программа сбора данных, размещающая информацию в массивах увеличивающихся размеров, прирост значения Working Set ее процесса будет вполне оправданным (хотя, возможно, и нежелательным).

ЭКРАН 1. Наблюдение за счетчиком Working Set.

Значение счетчика Process:Pagefile Bytes весьма точно следует за изменением размера рабочего пространства приложения, увеличиваясь по мере роста объема потребляемой приложением памяти. Например, при использовании Working Set для контроля за работой приложения, порождающего утечки памяти, видно, что значение счетчика PageFile Bytes будет находиться в близкой к линейной зависимости от Working Set.

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

Счетчики Commited Bytes, Commit Limit и %Commited Bytes In Use — очень удобный инструментарий для определения интенсивности использования памяти в Windows NT Workstation. Однако, прежде чем говорить о них, необходимо разобраться с принципами формирования файла подкачки.

В документации Microsoft указано, что минимальный размер этого файла должен быть равен объему физической памяти плюс еще примерно 12 Мбайт. Однако это значение может быть оптимизировано, исходя из реальных требований системы. О максимальном же размере беспокоиться нечего, ибо во всех исследованных мною версиях Windows NT, включая NT 4.0 с установленным Service Pack 6 (SP6), операционная система игнорировала любое задаваемое значение. Она увеличивает файл подкачки настолько, насколько это необходимо для удовлетворения потребностей в памяти, вплоть до исчерпания места на диске. Чтобы проверить, как Windows NT реагирует на возрастающий дефицит памяти, во вкладке Performance значка System на Control Panel введем значение максимального размера файла подкачки. Затем возьмем из каталога perftoolmeastool пакета Windows NT Resource Kit файл leakyapp.exe. Это созданное программистами Microsoft приложение My Leaky App, предназначенное для тестирования поведения системы в процессе непрекращающегося выделения памяти. После запуска этой программы размер занимаемой ею системной памяти будет постоянно расти.

ЭКРАН 2. Приложение MyLeakyApp отображает использование файла подкачки.

Запустим приложение и, для инициации тестового процесса, нажмем кнопку Start Leaking. Приложение будет непрерывно отображать уровень использования файла подкачки, позволяя, как показано на Экране 2, останавливать и снова запускать процедуру запроса на дополнительную память. Если программа будет работать достаточно долго, размер файла подкачки начнет увеличиваться сверх предельного уровня, указанного во вкладке Performance. После превышения файлом подкачки установленного минимального значения для его возврата к исходной величине необходимо перезагрузить компьютер.

Когда Windows NT начнет, в целях удовлетворения растущих запросов на память, увеличивать файл подкачки, производительность резко упадет, особенно если файл размещен на медленном или сильно фрагментированном диске. С помощью счетчиков Committed Bytes и Commit Limit можно фиксировать рост потребления памяти, что провоцирует резкий рост файла подкачки. Упрощенно говоря, Windows NT записывает в Commit Limit значение, равное сумме объема установленной на компьютере физической памяти и размера файла подкачки, заданного во вкладке Performance. Значение счетчика Committed Bytes равняется общему размеру выделенной работающему процессу памяти. По мере роста Committed Bytes происходит приближение к предельному значению Commit Limit, достичь которого можно в случае выполнения следующих один за другим запросов на память со стороны одного или нескольких приложений. Следя за счетчиком %Committed Bytes In Use, можно увидеть, что при достижении им величины 100% система начнет увеличивать размеры файла подкачки, пытаясь удовлетворить растущие запросы на память.

Чтобы система могла справиться с этими запросами, увеличение файла подкачки будет производиться до тех пор, пока позволяет размер дискового пространства. При этом возможно появление показанного на Экране 3 сообщения Out of Virtual Memory. Если это произойдет, следует запустить Performance Monitor. Для всех работающих приложений нужно выбрать объект Process, счетчики Working Set и Pagefile Bytes. Довольно скоро выяснится, какое приложение отвечает за столь резкий рост потребления памяти. Следует помнить, что с помощью счетчика %Committed Bytes In Use можно определить оптимальный размер файла подкачки. Если постоянно следить за показаниями этого счетчика, то всегда можно подогнать минимальный размер файла под требования имеющегося на компьютере набора приложений.

ЭКРАН 3. Сообщение Out Of Virtual Memory

Использование процессора

Счетчик Process:%Processor Time оценивает степень загрузки процессора приложением. Это важно знать при выявлении узких мест в работе операционной системы. Вместе с тем, при использовании данного счетчика надо быть очень внимательным. Например, некоторые приложения могут находиться в цикле ожидания в преддверии наступления определенных системных событий. Такие циклы способны вызывать стопроцентную загрузку процессора, что, однако, не мешает рабочей станции запускать другие процессы.

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

Включенная в Windows NT Resource Kit утилита CPU Stress позволяет искусственно загрузить процессор и выяснить, как система должна себя вести в подобных ситуациях. С помощью этого средства можно настраивать приоритеты и уровень активности четырех потоков, контролировать степень загруженности процессора приложениями и определять значимость каждого потока для операционной системы (например, оценивать, какие потоки с низким приоритетом уступают управление более приоритетным потокам).

Утилиты Windows NT Resource Kit для управления производительностью

Помимо My Leaky App и CPU Stress, Resource Kit содержит ряд полезных утилит управления производительностью компьютеров, работающих под Windows NT. Большая часть их размещена в папке Perftool, а список некоторых из них приведен во врезке «Утилиты управления производительностью». Секрет успеха при управлении производительностью Windows NT Workstation — отличное знание своих приложений и порядка использования ими ресурсов операционной системы.

После освоения работы со счетчиками Performance Monitor я рекомендую обратить внимание на утилиту Response Probe из Resource Kit, которая дает возможность создавать скоростные приложения, заранее оценивая их характеристики. С ее помощью можно генерировать искусственные нагрузки, позволяющие моделировать уровень загруженности системы. Вместе с тем, оптимизация производительности при работе с одним приложением — не самая трудная задача. Самое интересное начинается тогда, когда в работу включаются одновременно 20 приложений и целый набор служб и утилит.

ОБ АВТОРЕ:

Даррен Мар-Элиа — внештатный редактор журнала Windows NT Magazine. Специалист по архитектуре NT; занимается планированием развертывания сетей NT 4.0 и Windows 2000 в масштабах США. С автором можно связаться по адресу: dmarelia@earthlink.net.

Таблица 1. Объекты и счетчики.

Объект: Счетчик	Объект контроля	Порядок использования
Process: Working Set (Процесс: Рабочее пространство)	Количество потребляемой процессом физической оперативной памяти.	Непрерывный контроль использования приложением памяти и выявление утечки памяти.
Process: Pagefile Bytes (Процесс: Байт файла подкачки)	Количество памяти, которое процесс использует в файле подкачки.	Непрерывный контроль использования приложением всей доступной памяти.
Memory: Committed Bytes (Память: Байт выделенной виртуальной памяти)	Общий размер выделенной виртуальной памяти, которую в данный момент занимают все пользовательские процессы.	Позволяет установить момент начала роста файла подкачки (путем сравнения с Commit Limit).
Memory: Commit Limit (Память: Предел выделенной виртуальной памяти)	Расчетная величина, которая определяет, какое количество виртуальной памяти система может выделить, не увеличивая размера файла подкачки.	Помогает выяснить, насколько размер файла подкачки соответствует системным требованиям. Используется для расчета значений счетчика %Commited Bytes In Use.
Memory: % Committed Bytes In Use (Память: %использования выделенной памяти)	Соотношение величин счетчиков Commited Bytes и Commit Limit.	Позволяет установить момент начала роста файла подкачки.
Process: % Processor Time (Процесс: %загруженности процессора)	Степень использования процессора заданным процессом.	Позволяет выявить наиболее загружающие процессор приложения.

Утилиты управления производительностью

В состав Microsoft Windows NT Workstation 4.0 Resource Kit входят несколько утилит для настройки производительности. В каталоге Perftool можно найти следующие файлы.

cntrtoolcounters.hlp. В этом файле подсказки перечислены и описаны стандартные счетчики Performance Monitor.

logtools ypeperf.exe. Это утилита командной строки, аналогичная Performance Monitor, которая выводит на экран значения параметров, разделенные запятыми, как показано на Экране А. Typeperf отслеживает параметры, соответствующие объектам и счетчикам Performance Monitor, и возвращает их текущие значения. На Экране А выведены значения, полученные при мониторинге Memory: Committed Bytes и Microsoft Internet Explorer Working Set с интервалом в 1 секунду. Задавая путь в формате UNC перед объектом, за которым проводится наблюдение (например, «machinememorycommitted bytes»), можно следить за производительностью удаленных машин.

ЭКРАН A. Результаты работы утилиты logtools ypeperf.exe.

meastoolempty.exe. Это утилита удаляет набор счетчиков Working Set работающего приложения. Используется для освобождения большего количества физической памяти непосредственно приложению.

meastool timer.exe. Данная утилита показывает время работы конкретного приложения, включая время работы в привилегированном и пользовательском режимах (в процентах).

meastoolpview.exe. Данная утилита выводит детальную информацию о памяти, выделенной процессу системой. Кроме этого она помогает узнать маркер безопасности, который система назначила данному процессу и его потокам.

meastool op.exe. Утилита командной строки, которая в непрерывном режиме выводит основные процессы, занимающие процессор.

meastoolwperf.exe. Графическая утилита, показывающая значения большого числа параметров, характеризующих использование памяти и процессора. Напоминает утилиту Perfmeter в UNIX.

Поделитесь материалом с коллегами и друзьями