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

Устранение проблем с производительностью кэша и диспетчера памяти Troubleshoot Cache and Memory Manager Performance Issues

До выхода Windows Server 2012 две основные потенциальные проблемы приводят к увеличению размера кэша системных файлов до тех пор, пока объем доступной памяти не будет почти исчерпан при определенных рабочих нагрузках. Before Windows Server 2012, two primary potential issues caused system file cache to grow until available memory was almost depleted under certain workloads. Если эта ситуация приводит к медленной работе системы, можно определить, является ли сервер одной из этих проблем. When this situation results in the system being sluggish, you can determine whether the server is facing one of these issues.

Счетчики для мониторинга Counters to monitor

\Время существования долгосрочного резервного кэша памяти (в байтах), Memory\Long-Term Average Standby Cache Lifetime (s)

\Нехватка доступной памяти, МБ Memory\Available Mbytes is low

\Резидентные байты в системном кэше памяти Memory\System Cache Resident Bytes

Если объем \ доступной памяти (в МБ) слишком мал и в течение одного \ байта память, резидентная в кэш, занимает значительную часть физической памяти, можно использовать раммап , чтобы узнать, для чего используется кэш. If Memory\Available Mbytes is low and at the same time Memory\System Cache Resident Bytes is consuming significant part of the physical memory, you can use RAMMAP to find out what the cache is being used for.

Системный кэш файлов содержит структуры данных метафайлов NTFS System file cache contains NTFS metafile data structures

Эта проблема обозначается очень большим числом активных страниц метафайлов в выходных данных РАММАП, как показано на следующем рисунке. This problem is indicated by a very high number of active Metafile pages in RAMMAP output, as shown in the following figure. Эта проблема могла быть замечена на занятых серверах, к которым обращаются миллионы файлов, что приводит к кэшированию данных метафайлов NTFS, которые не освобождаются из кэша. This problem might have been observed on busy servers with millions of files being accessed, thereby resulting in caching NTFS metafile data not being released from the cache.

Проблема, используемая для устранения проблемы с помощью средства динкаче . The problem used to be mitigated by DynCache tool. В Windows Server 2012 + архитектура была переработана, и эта проблема больше не должна существовать. In Windows Server 2012+, the architecture has been redesigned and this problem should no longer exist.

Системный кэш файлов содержит файлы, сопоставленные с памятью System file cache contains memory mapped files

Эта проблема обозначается очень большим числом активных страниц, сопоставленных с файлами, в выходных данных РАММАП. This problem is indicated by very high number of active Mapped file pages in RAMMAP output. Обычно это означает, что какое-либо приложение на сервере открывает много больших файлов с помощью API-интерфейса CreateFile с _FLAG_RANDOM_ACCESS. This usually indicates that some application on the server is opening a lot of large files using CreateFile API with FILE_FLAG_RANDOM_ACCESS flag set.

Эта проблема подробно описана в статье базы знаний 2549369. This issue is described in detail in KB article 2549369. _ _ Флаг случайного _ доступа к файлу — это указание для диспетчера кэша, которое сохраняет сопоставленные представления файла в памяти (до тех пор, пока диспетчер памяти не сообщит о нехватке памяти). FILE_FLAG_RANDOM_ACCESS flag is a hint for Cache Manager to keep mapped views of the file in memory as long as possible (until Memory Manager doesn’t signal low memory condition). В то же время этот флаг указывает диспетчеру кэша, что необходимо отключить предзагрузку файловых данных. At the same time, this flag instructs Cache Manager to disable prefetching of file data.

Эта ситуация была устранена в некоторой степени за счет улучшения работы с обрезками в Windows Server 2012 +, но сама по себе проблема должна быть решена поставщиком приложения без использования _ флага файла с _ произвольным _ доступом. This situation has been mitigated to some extent by working set trimming improvements in Windows Server 2012+, but the issue itself needs to be primarily addressed by the application vendor by not using FILE_FLAG_RANDOM_ACCESS. Альтернативным решением для поставщика приложения может быть использование приоритета нехватки памяти при доступе к файлам. An alternative solution for the app vendor might be to use low memory priority when accessing the files. Это можно сделать с помощью API сетсреадинформатион . This can be achieved using the SetThreadInformation API. Страницы, доступ к которым осуществляется с низким приоритетом памяти, более агрессивно удаляются из рабочего набора. Pages that are accessed at low memory priority are removed from the working set more aggressively.

Диспетчер кэша, начиная с версии Windows Server 2016, в дальнейшем устраняет эту возможность, игнорируя FILE_FLAG_RANDOM_ACCESS при выполнении обрезки, поэтому она обрабатывается так же, как и любой другой файл, Открытый без флага FILE_FLAG_RANDOM_ACCESS (диспетчер кэша по-прежнему учитывает этот флаг для отключения предварительной выборки данных файлов). Cache Manager, starting in Windows Server 2016 further mitigates this by ignoring FILE_FLAG_RANDOM_ACCESS when making trimming decisions, so it is treated just like any other file opened without the FILE_FLAG_RANDOM_ACCESS flag (Cache Manager still honors this flag to disable prefetching of file data). При наличии большого числа открытых файлов с этим флагом и доступе к ним по-настоящему случайным образом можно вызвать чрезмерное количество системных кэшей. You can still cause system cache bloat if you have large number of files opened with this flag and accessed in truly random fashion. Настоятельно рекомендуется FILE_FLAG_RANDOM_ACCESS не использовать приложения. It is highly recommended that FILE_FLAG_RANDOM_ACCESS not be used by applications.

Устранение неполадок с утечкой памяти или исключением нехватки памяти в процессе BizTalk Server

В этой статье описывается устранение неполадок с утечкой памяти или исключением нехватки памяти в серверном процессе BizTalk на сервере Microsoft BizTalk Server.

Исходная версия продукта: BizTalk Server 2010, 2009
Исходный номер статьи базы знаний: 918643

Аннотация

Распространенной причиной является утечка памяти. Возможно, вам потребуется выполнить несколько действий, чтобы найти определенную причину утечки памяти или исключения нехватки памяти в Microsoft BizTalk Server. В этой статье обсуждаются важные моменты, которые следует учитывать при оценке использования памяти и возможных проблем, связанных с памятью. Ниже приведены возможные соображения.

• Физическая память
• Обработка больших сообщений
• Использование параметра/3gb
• Использование настраиваемых компонентов
• Какая версия Microsoft .NET Framework работает в системе
• Число процессоров

При использовании памяти в диспетчере задач Microsoft Windows процесс BizTalk Server может привести к утечке памяти, если в диспетчере задач Microsoft Windows используется более 50 процентов физического ОЗУ. Утечка памяти может привести к ошибке нехватки памяти при увеличении использования памяти до тех пор, пока процесс не завершится до истечения объема системной памяти или пока процесс не перестанет работать. Для устранения этой неисправности необходимо учитывать следующее:

Физическая память и использование памяти

Так как это может повлиять на половину объема физической памяти, используйте использование памяти в качестве рекомендации. Например, если сервер BizTalk Server имеет 4 гигабайта (ГБ) ОЗУ, а процесс сервера BizTalk использует около 500 мегабайт (МБ) ОЗУ, это может привести к невозможности утечки памяти. Если процесс сервера BizTalk использует около 1 ГБ ОПЕРАТИВной памяти, может возникнуть утечка памяти или высокая объем памяти. Использование памяти может быть вызвано длительными хранимыми процедурами или согласованием. Убедитесь, что вы знаете, какой объем памяти, используемой узлом BizTalk, обычно использует, чтобы определить, происходит ли утечка памяти или высокая память.

Большие сообщения

Когда BizTalk Server обрабатывает большие сообщения, система, вероятно, вызывает утечку памяти. Тем не менее, сообщения могут использовать большой объем памяти.

Кроме того, обратите внимание, что использование высокого объема памяти может быть ожидаемым, если BizTalk Server обрабатывает большие сообщения. Возможно, вы захотите обновить оборудование, чтобы обеспечить соответствие требованиям к производительности сервера BizTalk в вашей среде.

Время, необходимое для воспроизведения утечки памяти

Утечки памяти могут возникать немедленно или накапливаться со временем. Оба сценария являются общими.

Использование переключателя/3GB на 32 — разрядных компьютерах

Как правило, процесс может получить доступ к 2 ГБ виртуального адресного пространства. Параметр /3gb является возможностью для систем, требующих более адресации памяти. Этот параметр позволяет увеличить объем памяти, используемой для обработки сообщений. Однако параметр/3gb позволяет использовать только 1 ГБ адресации памяти для операций в режиме ядра. Кроме того, этот параметр может увеличить риск истечения памяти пула.

Если параметр/3gb включен в 32-разрядной версии Windows, то этот процесс может получить доступ к 3 ГБ виртуального адресного пространства, если этот процесс поддерживает большое количество адресов. Процесс является большим адресом, связанным с тем, что для исполняемого файла установлен флаг IMAGE_FILE_LARGE_ADDRESS_AWARE в заголовке изображения. Так как процесс BizTalk имеет большое значение для поддержки адресов, в BizTalk будет выгодно использовать параметр/3gb.

Если экземпляр сервера BizTalk (32-разрядный экземпляр) работает в 64-разрядной версии Windows (AMD64), то преимущества процесса BizTalk из адресного пространства памяти 4 ГБ, так как в BizTalk используется большая адресация. Таким образом, перемещение приложений с большим объемом памяти на сервер 64 бит может оказаться лучшим решением.

64-разрядный процесс BizTalk в 64-разрядной версии Windows (AMD64) содержит 8 ТБ адресации памяти.

Кроме того, следует учитывать виртуальные байты и частные байты, используемые процессом. Экземпляр узла BizTalk (это приложение .NET Framework) может получить сообщение об ошибке «недостаточно памяти», чтобы значение размера виртуального байта достигнет 2 ГБ. Такая ситуация может возникнуть, даже если максимальный адрес памяти для процесса в 32-разрядной версии Windows (без параметра/3gb) РАВЕН 2 ГБ. Чтобы узнать, почему может возникать такая ситуация, посетите следующий веб-сайт Майкрософт Developer Network (MSDN):
Мониторинг производительности ASP.NET и оповещение администраторов

Параметр/3gb также увеличивает максимальное число байтов исключительного пользования для процесса BizTalk от 800 мб до 1800 Мб. Для получения дополнительных сведений о производительности приложений .NET Framework с включенным параметром/3gb , перейдите к главе 17 — Настройка производительности приложений .NET.

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

Процесс	Windows	Адресация памяти (с большим процессом, поддерживающим адресацию)	Практический лимит для виртуальных байтов	Практический лимит для байтов исключительного пользования
32-разрядная	32-разрядная	2 ГБ	1400 МБ	800 МБ
32-разрядный	32 — бит с параметром/3GB	3 ГБ	2400 МБ	1800 МБ
32-разрядная	64-разрядная	4 ГБ	3400 МБ	2800 МБ
64-разрядная	64-разрядная	8 ТБ	Неприменимо	Неприменимо

Для получения дополнительных сведений о адресации памяти для 32 – разрядных VS и 64 — для Windows и Windows Server, посетите страницу пределы памяти для Windows и Windows Server.

В следующей таблице приведены сведения о поддержке PAE и 3 ГБ для разных версий сервера BizTalk Server.

Продукт	ТРУДНО	3 ГБ
BizTalk Server 2004	Да	Нет
BizTalk Server 2006	Да	Да
BizTalk Server 2006 R2	Да	Да
BizTalk Server 2009	Да	Да

Если необходимо включить параметр/3gb в соответствии с требованиями к производительности компьютера, на котором работает сервер BizTalk Server, можно рассмотреть добавление серверов в группу BizTalk. Это позволяет масштабировать экземпляры ведущего приложения с интенсивным использованием памяти.

Компоненты BizTalk, которые запускаются в процессе служб IIS, также могут быть полезны при включенном параметре/3gb .

Параметр/3gb не поддерживается на компьютерах под управлением Windows SharePoint Services 2,0 или более поздних версий или SharePoint Portal Server 2003 или более поздней версии. Параметр/3Gb windows Server 2003/3gb не поддерживается в Windows SharePoint Services 2,0 или более поздних версий, а также в SharePoint Portal Server 2003 с пакетом обновления 2 (SP2) или более поздней версии.

Использование настраиваемых компонентов

Если вы используете пользовательские компоненты, такие как конвейеры или компоненты служб, вам необходимо знать, что именно делают эти компоненты. Кроме того, следует убедиться в потенциальном влиянии этих компонентов на использование памяти. Распространенная проблема с памятью, возникающая при преобразовании компонента в документ. Операция преобразования занимает много памяти. При преобразовании документа сервер BizTalk Server передает поток сообщений в класс Microsoft .NET Framework XslTransform в рамках процесса BizTalk.

Еще одна распространенная проблема возникает при интенсивной обработке строк. Интенсивное манипулирование строкой может потреблять множество воспоминания. Для получения дополнительных сведений о способах повышения производительности посетите страницу улучшения производительности управляемого кода.

Версия .NET Framework

Microsoft .NET Framework 2,0 и .NET Framework 1,1 имеют различные параметры памяти. Таким образом, вы можете увидеть различные результаты между ними. Если вы используете .NET Framework, убедитесь, что установлен последний пакет обновления 1 (SP1) для .NET Framework. Эти пакеты обновления устраняют несколько известных проблем с памятью.

Число процессоров

Общеязыковая среда выполнения (CLR) имеет следующие сборщики мусора (GC):

Если компьютер, на котором работает сервер BizTalk Server, является многопроцессорной системой, платформа .NET Framework использует серверную версию ядра выполнения. Это значение установлено по умолчанию. Сборщик мусора сервера предназначен для максимальной пропускной способности. Кроме того, сборщик мусора сервера масштабируется для обеспечения высокой производительности. Этот сборщик мусора выделяет память, а затем освобождает память для обеспечения высокой производительности системы. Таким образом, компьютер, на котором работает сервер BizTalk Server вместе с некоторыми компонентами .NET Framework, может иметь утечку памяти. Однако в этом сценарии ожидаемое поведение является самым высоким уровнем использования памяти. Если на компьютере не хватает системной памяти или процесс перестает работать из-за недостаточного количества адресов памяти, может существовать условие утечки памяти.

Если компьютер, на котором работает сервер BizTalk Server, является однопроцессорной системой, .NET Framework использует версию подсистемы выполнения для рабочей станции. Это поведение по умолчанию. Алгоритм выделения сборщика мусора рабочей станции не предназначен для масштабирования или максимальной пропускной способности. Этот сборщик мусора использует параллельные методы сборщика мусора. Эти методы предназначены для приложений с сложными пользовательскими интерфейсами. Такие приложения могут требовать более агрессивной сборки мусора.

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

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

BizTalk 2006 и более поздние версии

Создайте следующий CRL Hosting строковый раздел реестра с соответствующими значениями:

• Разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$BizTalkHostName\CLR Hosting
• Имя значения: тип
• Данные значения: WKS

BizTalk 2004

Создайте следующий CRL Host строковый раздел реестра с соответствующими значениями:

• Разделе HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BTSSvc\CLR Hosting
• Имя значения: тип
• Данные значения: WKS

Ниже приведены распространенные причины и способы их устранения.

Пороги регулирования использования процессов и физической памяти

Пороги использования памяти процесса и регулирования использования физической памяти можно изменить в BizTalk Server 2006 и более поздних версиях.

По умолчанию для параметра регулирования использования памяти процесса задано значение 25. Если это значение превышено, а использование памяти для процесса BizTalk превышает 300 МБ, может произойти условие регулирования. На сервере 32 бит можно увеличить значение использования памяти процесса до 50. На 64 разрядном сервере это значение можно увеличить до 100. Это позволяет процессу BizTalk увеличить потребление памяти перед регулированием.

Пороговое значение регулирования использования физической памяти имеет значение, заданное по умолчанию: 0. Это пороговое значение измеряет общий объем системной памяти. Таким образом, если настроено значение, отличное от 0, это может произойти, если процесс, не являющийся BizTalk, использует высокую память.

Порог регулирования для восстановления

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

64 — битовые узлы поддерживаются в BizTalk Server 2006 и более поздних версиях.

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

Так как 64-разрядная архитектура обеспечивает расширенное адресное пространство памяти (16 ТБ вместо 4 ГБ), 64-разрядный экземпляр узла выделяет больше памяти, чем 32-разрядные экземпляры узла. Это может привести к превышению порогового значения регулирования памяти по умолчанию.

Чтобы обойти эту проблему, измените значения виртуалмеморисроттлингкритериа и приватемеморисроттлингкритериа в файле BTSNTSvc64.exe.config. Используйте счетчики системного монитора \Процесс\виртуал bytes и \Процесс\привате bytes, чтобы определить максимальный объем памяти, выделенный экземпляром согласования.

Задайте для обоих свойств значение оптималусаже в соответствии со следующими сведениями:

• Виртуалмеморисроттлингкритериа: \процесс\виртуал байтов значение + 10%
• Приватемеморисроттлингкритериа: \процесс\привате байтов значение + 10%

Задайте для обоих свойств максималусаже значение оптималусаже + 30%

Например, если значение счетчика \Процесс\виртуал Byte Performance Monitor для экземпляра оркестрации составляет 5 784 787 695 байт (5 517 МБ), задайте значение оптималусаже для виртуалмеморисроттлингкритериа равным 6 069 мб (5 784 787 695 * 1,10 = 6 363 266 464,5 байт).

Установите значение максималусаже для виртуалмеморисроттлингкритериа равным 7 889 мб (6 363 266 464,5 * 1,30 = 8 272 246 403,85 байт).

Если значение счетчика \Процесс\привате bytes Performance Monitor составляет 435689400 байт (415 МБ), задайте значение оптималусаже для приватемеморисроттлингкритериа равным 457 мб (435689400 * 1,10 = 479258340 байт).

Установите значение максималусаже для приватемеморисроттлингкритериа равным 594 мб (479258340 * 1,30 = 623035842).

Для этого примера в файле BTSNTSvc64.exe.config будут указаны следующие значения для сокращения регулирования.

Счетчик системного монитора	Выделенная память	оптималусаже	максималусаже
Байты \Процесс\виртуал	5 784 787 695 байт (5517 МБ)	6069	7889
Байты \Процесс\привате	435 689 400 байт (415 МБ)	457	594

Затем эти значения будут представлены в файле BTSNTSvc64.exe.config следующим образом:

Чтобы определить, на каком экземпляре узла работает согласование, можно выполнить обработку идентификатора в счетчиках монитора \Бизталк: Мессагинг\ид Process и \Процесс\ид Process. Затем проверьте среднее значение, отображаемое для счетчиков системного монитора \Процесс\виртуал Bytes and \Процесс\привате bytes.

Сведения, которые пользователь должен заметить даже в том случае, если высокая степень восстановления Скиммингсе может привести к значительному снижению производительности при BizTalkMsgBoxDb выполнении базы данных на сервере SQL server 2008.

Пакеты обновления и накопительные пакеты обновления для BizTalk Server

Пакеты обновления и накопительные пакеты обновления для BizTalk Server включают последние исправления. Сюда входят те, которые влияют на известные System.OutOfMemoryException проблемы.

хеапдекоммитфриблокксрешолд

По умолчанию HeapDeCommitFreeBlockThreshold значение параметра реестра равно 0. Значение 0 означает, что диспетчер кучи отменяет каждую доступную страницу 4 килобайт (КБ). Операции отмены фиксации могут привести к фрагментации виртуальной памяти. Размер HeapDeCommitFreeBlockThreshold параметра в диспетчере кучи зависит от типа работы, выполняемой системой. Размер 0x00040000 является рекомендуемым начальным значением.

Прежде чем изменять значение раздела реестра, примите во внимание следующие сведения HeapDeCommitFreeBlockThreshold :

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

Чтобы уменьшить фрагментацию виртуальной памяти, можно увеличить размер HeapDeCommitFreeBlockThreshold параметра в диспетчере кучи, изменив значение следующего раздела реестра в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager :

• Имя значения: Хеапдекоммитфриблокксрешолд
• Тип значения: REG_DWORD
• Data Value: 0x00040000 (рекомендуемое начальное значение).
• Значение по умолчанию: отсутствует

Операции преобразования

Когда BizTalk Server выполняет операции преобразования XML на достаточно больших сообщениях в порте получения, в порте отправки или в XLANG XSL преобразования загружаются все сообщения в памяти.

Чтобы устранить проблему, воспользуйтесь одним из указанных ниже способов.

• Сократите количество сообщений, обрабатываемых сервером BizTalk Server одновременно.
• Уменьшите размер XML-сообщения, которое преобразуется.

System.Policy.Security.Evidence Объект часто используется в преобразованиях и может занимать большой объем памяти. Если карта содержит скрипты functoid , использующие встроенные C# (или любые другие встроенные языки), сборка создается в памяти. System.Policy.Security.Evidence Объект использует объект фактической сборки вызова. В этом случае создается корневой объект, который не удаляется до перезапуска службы BizTalk.

Большая часть BizTalk по умолчанию functoids реализована в виде встроенного скрипта. Эти элементы могут привести к System.Byte[] сбору объектов в памяти. Чтобы свести к минимуму потребление памяти, рекомендуется поместить любую карту, которая использует их, functoids в небольшую сборку. Затем сослаться на эту сборку. Используйте приведенную ниже диаграмму, чтобы определить, какой functoids сценарий используется встроенным сценарием, а functoids не с помощью встроенного скрипта.

Во втором столбце Да означает, что он functoid реализован в виде встроенного скрипта и что он приведет к System.Byte[] сбору объектов в памяти. Нет означает, что это functoid не реализовано в виде встроенного скрипта и не приведет к System.Byte[] сбору объектов в памяти.

функтоидс	Встроенные скрипты?
Все строковые Функтоидс	Да
Все математические Функтоидс	Да
Все логические Функтоидс, за исключением Иснил	Да
Логическая Иснил функтоид	Нет
Все даты и время Функтоидс	Да
Все Функтоидс преобразования	Да
Все научные Функтоидс	Да
Все накопительные Функтоидс	Да
Все базы данных Функтоидс	Нет

Расширенные Функтоидс	Встроенные скрипты?
Циклическое функтоид	Нет
Функтоид сведение по сопоставлению значений	Нет
Утверждение функтоид	Нет
Средство извлечения таблиц функтоид	Нет
Циклическая таблица функтоид	Нет
Написание сценариев функтоид с помощью встроенного языка C #	Да
Написание скриптов функтоид с помощью встроенного JScript.NET	Да
Написание скриптов для функтоид с помощью встроенного Visual Basic .NET	Да
Написание скриптов для функтоид с помощью встроенного XSLT	Нет
Создание сценариев функтоид с помощью встроенного шаблона XSLT-вызова	Нет
Выполнение скрипта для внешней сборки функтоид вызовов	Нет
Пустое значение функтоид	Нет
Функтоид сопоставления значений	Нет
Массовое копирование функтоид	Нет
Итерация функтоид	Нет
Функтоид индекса	Нет
Число записей функтоид	Нет

BizTalk Server 2006 и более поздние версии значительно улучшают управление памятью для больших документов. Для этого BizTalk Server реализует Настраиваемое пороговое значение размера сообщения для загрузки документов в память во время операций преобразования. По умолчанию пороговое значение размера сообщения составляет 1 МБ. Для получения дополнительных сведений о параметре Трансформсрешолд посетите страницу обработки больших сообщений в BizTalk Server.

Большие значения атрибутов и значения больших элементов

Когда сервер BizTalk Server выполняет конвейер приема или конвейер отправки для XML-документа, полезная нагрузка обрабатывается в памяти, если документ содержит одну или несколько из следующих сущностей:

• Большие значения атрибутов
• Значения больших элементов
• Крупный атрибут или теги элементов

Чтобы устранить эту проблему, ограничьте размер этих сущностей. Если этот метод невозможен, убедитесь, что экземпляр BizTalk HOST не обрабатывает несколько документов одновременно.

Настраиваемые компоненты процесса продаж

Вы используете пользовательский компонент конвейера, загружающий весь поток в память. Все компоненты, входящие в состав сервера BizTalk Server, за исключением преобразований, поддерживают потоковую передачу. Эти компоненты не используют столько памяти во время потоковой передачи. Однако пользовательские компоненты конвейера могут не поддерживать потоковую передачу.

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

При интенсивной нагрузке на узлы отправки недостаточно памяти. BizTalk Server отправляет конвейеры и отправляет адаптеры для поддержки потоковой передачи. В потоковой передаче каждый компонент загружает небольшой фрагмент потока в память. Так как каждое сообщение содержит другие структуры данных, а также контекст сообщения, который может быть значительным или небольшим, это поведение влияет на поведение сервера BizTalk при большой нагрузке.

Поведение сервера BizTalk Server зависит от того, что обработчик загружает предварительно настроенное количество сообщений. Количество сообщений, загружаемых ядром, зависит от значений, которые отображаются в полях ловватермарк и хигхватермарк Adm_serviceClass таблицы. Adm_serviceClass Таблица находится в базе данных управления BizTalk. Эти значения управляют количеством сообщений, которые сервер BizTalk обрабатывает или отправляет одновременно.

Значение хигхватермарк — это общее количество сообщений, обрабатываемых ядром одновременно. Значение по умолчанию — 200 сообщений на ЦП. Таким образом, на 8-процессорном сервере Узел отправки попытается обрабатывать сообщения 1 600 (200 * 8) одновременно.

Если предполагается, что каждое сообщение равно 50 КБ, то оно будет равно 80 МБ (1 600 * 50 = 80000 КБ).

Чтобы устранить эту проблему, можно изменить значение хигхватермарк и значение ловватермарк в базе данных. Значения, которые вы используете, зависят от размера сообщений. Для сервера BizTalk Server 2006 и более поздних версий можно изменить параметры регулирования узла по умолчанию.

Попытаться упростить эту задачу

Если определена утечка памяти, попробуйте определить причину, удалив пользовательские компоненты или выполнив сопоставление. Кроме того, попробуйте воспроизвести ошибку с помощью простого согласования или простого решения. Как правило, следует создавать отдельные узлы получения для адаптеров получения. Кроме того, необходимо создать отдельные узлы отправки для адаптеров отправки. При использовании этого метода каждый адаптер может работать в отдельном процессе. Таким образом, если в процессе BizTalk Server возникают условия нехватки памяти, вы узнаете, какие компоненты задействованы.

Действия по устранению неполадок

Для устранения неполадок, связанных с нехватка памяти, используйте средство диагностики отладки для мониторинга выделения памяти с течением времени. Средство диагностики отладки может создавать и анализировать файл дампа утечки памяти (DMP). При устранении неполадок с утечками памяти необходимо присоединить Leaktrack.dll , прежде чем высокая память будет воспроизведена для захвата роста памяти с течением времени. Leaktrack.dll входит в состав средства диагностики отладки.

Установите средство диагностики отладки.

Следующий файл доступен для скачивания из центра загрузки Майкрософт:
Загрузить пакет средства диагностики отладки

Для получения дополнительных сведений о том, как скачать файлы поддержки Майкрософт, ознакомьтесь со статьей Получение файлов поддержки Майкрософт из веб-служб.

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

Используйте системный монитор для сбора данных о производительности системы. Эти данные могут предоставлять важные показатели эффективности среды BizTalk Server. Цель состоит в том, чтобы собрать производительность процесса с течением времени. Поэтому включите ведение журнала системного монитора, прежде чем произойдет утечка памяти.

Использование журнала системного монитора

В следующих разделах описано, как использовать ведение журнала системного монитора.

Выбор данных для ведения журнала

Чтобы выбрать данные для ведения журнала, используйте метод, соответствующий вашей операционной системе:

Для Windows Server 2008 и Windows Server 2008 R2

В меню Администрирование откройте Монитор надежности и производительности.

Щелкните правой кнопкой мыши системный монитор, щелкните создать , а затем выберите группу сборщиков данных.

В поле имя введите описательное имя, а затем нажмите кнопку Далее.

Запишите корневой каталог и нажмите кнопку Далее.

Выберите запустить группу сборщиков данных сейчаси нажмите кнопку Готово.

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

Щелкните правой кнопкой мыши Журнал системного монитораи выберите пункт свойства.

Нажмите кнопку Добавить на вкладке счетчики производительности . Выберите следующие объекты и нажмите кнопку Добавить после выбора каждого объекта:

• Исключения среды CLR .NET
• Память CLR .NET
• BizTalk: обмен сообщениями
• BizTalk: ТДДС
• Память
• Процесс
• Процессор
• Согласование КСЛАНГ/s

Если SQL Server является локальным, добавьте также следующие объекты:

• SQLServer: базы данных
• SQLServer: Общая статистика
• SQLServer: диспетчер памяти

Нажмите кнопку ОК.

Измените значение поля интервал для выборки на 5 секунд.

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

Нажмите кнопку ОК.

Чтобы остановить сбор данных, нажмите кнопку остановить в меню Action (действие ).

Для Windows Server 2003 или Windows XP

Разверните раздел журналы и оповещения производительности.

Щелкните правой кнопкой мыши журналы счетчикови выберите пункт новые параметры журнала. Откроется диалоговое окно » Создание параметров журнала «.

В поле имя введите описательное имя, а затем нажмите кнопку ОК.

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

Нажмите кнопку Добавить счетчики.

Выберите все счетчики и все экземпляры.

В списке объект производительности выберите следующие объекты. Нажмите кнопку Добавить после выбора каждого объекта.

• Исключения среды CLR .NET
• Память CLR .NET
• BizTalk: обмен сообщениями
• BizTalk: ТДДС
• Память
• Процесс
• Процессор
• Согласование КСЛАНГ/s

Если SQL Server является локальным, добавьте также следующие объекты:

• SQLServer: базы данных
• SQLServer: Общая статистика
• SQLServer: диспетчер памяти

Нажмите кнопку Закрыть.

Измените значение интервала выборки данных на 5 секунд.

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

Нажмите кнопку ОК. Чтобы остановить сбор данных, щелкните правой кнопкой мыши имя журнала счетчика и выберите команду остановить.

Получение файла дампа

Чтобы получить файл дампа, воспользуйтесь одним из указанных ниже способов.

Способ 1: автоматический

Для захвата дампа памяти рекомендуется создать правило утечки памяти и обработку с помощью Дебугдиаг. Правило утечки памяти и обработкиLeaktrack.dllавтоматически прикрепляет * *. Используется для отслеживания выделения памяти. Чтобы создать правило утечки памяти и обработки утечек, выполните следующие действия:

Запустите средство диагностики отладки 1,1.

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

Выберите процесс Btsntsvc.exe, а затем нажмите кнопку Далее.

На странице » Настройка правила утечек » выполните следующие действия:

Установите флажок начать отслеживание памяти немедленно, когда правило активируется . В противном случае вы можете указать время прогрева до того, как LeakTrack.dll будет вставлен в процесс BTSNTSvc.exe.

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

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

Установите флажок создать Userdump при достижении виртуального байта и оставьте значение по умолчанию 1024.

Установите флажок и все дополнительные флажки и оставьте значение по умолчанию 200. При выборе параметра достижимости виртуального байта дамп памяти будет автоматически создан при использовании виртуальной памяти 1024 МБ. Если размер виртуальной памяти увеличивается на 200 МБ, будет автоматически создан другой дамп памяти.

Нажмите кнопку сохранить & закрыть.

Нажмите кнопку Далее.

На странице » Выбор расположения и имени правила » нажмите кнопку Далее.

Путь к файлу дампа также можно изменить в поле Расположение Userdump на этой странице.

Нажмите кнопку Готово , чтобы сделать правило активным.

Состояние правила теперь отслеживается. При каждом создании дампа памяти его значение увеличится в столбце » число Userdump » на вкладке » правила «. По умолчанию используется расположение дампа памяти C:\Program Files\DebugDiag\Logs .

Способ 2: вручную

Вы также можете вручную присоединить Leaktrack.dll и получить файл дампа памяти вручную. Это позволяет управлять моментом создания дампа памяти. Для этого выполните следующие действия:

1. Запустите средство диагностики отладки 1,1.
2. Выберите вкладку Процессы.
3. Щелкните процесс Btsntsvc.exe правой кнопкой мыши и выберите пункт Отслеживание утечек.
4. В диалоговом окне средство отладки диагностики нажмите кнопку Да, а затем нажмите кнопку ОК.

Создайте правило аварийного восстановления для наблюдения за одним Btsntsvc.exe процессом в случае остановки процесса до создания дампа памяти:

1. Запустите средство диагностики отладки 1,1.
2. Выберите сбой, а затем нажмите кнопку Далее.
3. Выберите конкретный процесс, а затем нажмите кнопку Далее.
4. Выберите один и тот же процесс Btsntsvc.exe, а затем нажмите кнопку Далее.
5. На странице Расширенная конфигурация (необязательно) нажмите кнопку Далее.
6. В диалоговом окне Выбор расположения дампа и имени правила (необязательно) нажмите кнопку Далее.
7. Выберите активировать правило, а затем нажмите кнопку Готово.

Когда процесс достигает 60 процентов до 80 процентов оперативной памяти, щелкните процесс Btsntsvc.exe правой кнопкой мыши и выберите команду создать полную Userdump. Если процесс BizTalk завершается до того, как вы сможете создать дамп пользователя, правило сбоя вступит в силу и создаст дамп памяти.

Остановить ведение журнала системного монитора

Если вы захватываете дамп памяти и данные системного монитора, остановите ведение журнала системного монитора около двух минут после создания дампа памяти.

Анализ файла дампа

Для определения причины утечки памяти можно использовать средство диагностики отладки для анализа файла дампа. Для этого выполните следующие действия:

1. Перейдите на вкладку Расширенный анализ .
2. Нажмите кнопку Добавить файлы данныхи найдите DMP файл.
3. Выберите скрипт анализа нехватки памяти и нажмите кнопку начать анализ.

По умолчанию при завершении анализа в папке будет создан файл отчета об анализе (файл с расширением MHT) C:\Program Files\DebugDiag\Reports . Файл отчета также будет отображаться в браузере. Файл отчета содержит результаты анализа. Кроме того, в файле отчета могут содержаться рекомендации по устранению утечек памяти.

При использовании настраиваемых библиотек DLL можно добавить путь к настраиваемым PDB-файлам для анализа. Для этого выполните следующие действия:

1. Откройте средство диагностики отладки.
2. В меню Сервис выберите пункт Параметры и параметры.
3. В поле путь поиска символов для отладки введите путь к символам.

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

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