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

  • Статья

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

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

Сводка

Утечка памяти является распространенной проблемой. Возможно, потребуется выполнить несколько действий, чтобы найти конкретную причину утечки памяти или исключения нехватки памяти (OOM) в Microsoft BizTalk Server. В этой статье рассматриваются важные моменты, которые следует учитывать при оценке использования памяти и возможных проблемах, связанных с памятью. Эти рекомендации включают в себя следующие аспекты:

  • Физический ОЗУ
  • Обработка больших сообщений
  • Использование параметра /3 ГБ
  • Использование пользовательских компонентов
  • Какая версия microsoft платформа .NET Framework работает в системе
  • Число процессоров

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

Использование физической ОЗУ и памяти

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

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

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

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

Сколько времени требуется для воспроизведения утечки памяти

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

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

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

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

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

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

Следует также учитывать виртуальные и частные байты, используемые процессом. Экземпляр узла BizTalk (который является платформа .NET Framework приложением) может получить ошибку нехватки памяти до того, как значение Virtual Bytes достигнет 2 ГБ. Такая ситуация может возникнуть, даже если максимальный объем памяти, доступный процессом в 32-разрядной версии Windows (без параметра /3 ГБ), составляет 2 ГБ. Чтобы объяснить, почему это может произойти, посетите следующий веб-сайт Microsoft Developer Network (MSDN):
ASP.NET мониторинг производительности и когда следует оповещать администраторов

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

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

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

Дополнительные сведения о адресной памяти для 32-разрядных и 64-разрядных версий Windows см. в статье Ограничения памяти для выпусков Windows и Windows Server.

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

Продукт PAE 3 ГБ
BizTalk Server 2004 г. Да Нет
BizTalk Server 2006 г. Да Да
BizTalk Server 2006 R2 Да Да
BizTalk Server 2009 Да Да

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

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

Параметр /3 ГБ не поддерживается на компьютерах под управлением Windows SharePoint Services 2.0 или более поздних версий или SharePoint Portal Server 2003 с пакетом обновления 2 (SP2) или более поздних версий. Параметр 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, убедитесь, что установлена последняя платформа .NET Framework с пакетом обновления 1 (SP1). Эти пакеты обновления устраняют несколько известных проблем с памятью.

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

Среда CLR имеет следующие сборщики мусора (GCs):

  • Рабочая станция (Mscorwks.dll)
  • Сервер (Mscorsvr.dll)

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

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

Важно!

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

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

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

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

  • Ключ: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$BizTalkHostName\CLR Hosting
  • Имя значения: Flavor
  • Данные значений: wks

BizTalk 2004

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

  • Ключ: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BTSSvc{GUID }\CLR Hosting
  • Имя значения: Flavor
  • Данные значений: wks

Дополнительные сведения см. в статье Вопросы производительности для технологий Run-Time в платформа .NET Framework.

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

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

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

Чтобы обойти это поведение, измените значения VirtualMemoryThrottlingCriteria и PrivateMemoryThrottlingCriteria в файле BTSNTSvc64.exe.config. Используйте счетчики \Process\Virtual Bytes и \Process\Private Bytes Монитор производительности, чтобы определить наибольший объем памяти, выделяемый экземпляром оркестрации.

  • Задайте значение OptimalUsage для обоих свойств на основе следующего:

    • VirtualMemoryThrottlingCriteria: \Process\Virtual Bytes value + 10 %
    • PrivateMemoryThrottlingCriteria: \Process\Private Bytes value + 10 %

  • Присвойте параметру MaximalUsage для обоих свойств значение OptimalUsage + 30 %

Например, Если значение счетчика \Process\Virtual Byte Монитор производительности для экземпляра оркестрации равно 5 784 787 695 байт (5 517 МБ), задайте значение OptimalUsage для VirtualMemoryThrottling. Criteria до 6 069 МБ (5 784 787 695 * 1,10 = 6 363 266 464,5 байта).

Задайте значение MaximalUsage для VirtualMemoryThrottlingCriteria равным 7 889 МБ (6 363 266 464,5 * 1,30 = 8 272 246 403,85 байта).

Если значение счетчика \Process\Private Bytes Монитор производительности равно 435689400 байтам (415 МБ), задайте для параметра PrivateMemoryThrottlingCriteria значение OptimalUsage 457 МБ (435689400 * 1,10 = 479258340 байтов).

Задайте для параметра PrivateMemoryThrottlingCriteria значение MaximalUsage (479258340 * 1,30 = 623035842).

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

счетчик Монитор производительности Выделенная память OptimalUsage MaximalUsage
\Process\Virtual Bytes 5 784 787 695 байт (5517 МБ) 6069 7889
\Process\Private Bytes 435 689 400 байт (415 МБ) 457 594

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

<xlangs>
    <Configuration>
       <Dehydration>
         <VirtualMemoryThrottlingCriteria OptimalUsage="6069" MaximalUsage="7889" IsActive="true" />
         <PrivateMemoryThrottlingCriteria OptimalUsage="457" MaximalUsage="594" IsActive="true" />
       </Dehydration>
    </Configuration>
</xlangs>

Чтобы определить, какой экземпляр узла выполняет оркестрацию, можно сопоставить процесс идентификатора из счетчиков \BizTalk: Messaging\ID Process и \Process\ID Process Монитор производительности. Затем проверка значение Average, отображаемое для соответствующих счетчиков \Process\Virtual Bytes и \Process\Private Bytes Монитор производительности.

Примечание.

Информация, которую пользователь должен заметить, даже если скимминг. Высокий уровень обезвоженности может привести к значительному снижению производительности при BizTalkMsgBoxDb запуске базы данных в SQL Server 2008.

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

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

HeapDeCommitFreeBlockThreshold

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

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

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

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

  • Имя значения: HeapDeCommitFreeBlockThreshold
  • Тип значения: REG_DWORD
  • Данные о значении: 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[] объектов в памяти.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Попробуйте упростить проблему

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

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

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

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

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

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

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

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

Использование ведения журнала Монитор производительности

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

Выбор данных для записи в журнал

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

  • Для Windows Server 2008 и Windows Server 2008 R2

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

    2. Щелкните правой кнопкой мыши Монитор производительности, выберите Создать, а затем — Набор сборщиков данных.

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

    4. Обратите внимание на корневой каталог и нажмите кнопку Далее.

    5. Нажмите кнопку Запустить этот набор сборщиков данных сейчас, а затем нажмите кнопку Готово.

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

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

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

      • Исключения .Net CLR
      • Память .Net CLR
      • BizTalk: обмен сообщениями
      • BizTalk: TDDS
      • Память
      • Процесс
      • Процессор
      • Оркестрации XLANG/s

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

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

    9. Нажмите кнопку OK.

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

      Примечание.

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

    11. Нажмите кнопку OK.

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

  • Для Windows Server 2003 или Windows XP

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

    2. Щелкните правой кнопкой мыши Журналы счетчиков, а затем выберите Пункт Новые параметры журнала. Откроется диалоговое окно Новые параметры журнала .

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

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

    5. Щелкните Добавить счетчики.

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

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

      • Исключения .Net CLR
      • Память .Net CLR
      • BizTalk: обмен сообщениями
      • BizTalk: TDDS
      • Память
      • Процесс
      • Процессор
      • Оркестрации XLANG/s

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

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

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

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

      Примечание.

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

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

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

Чтобы получить файл дампа, используйте один из следующих методов:

Метод 1. Автоматический

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

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

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

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

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

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

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

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

      • Щелкните, чтобы выбрать поле Создать userdump, когда виртуальные байты достигают проверка, и сохраните значение по умолчанию 1024.

      • Щелкните, чтобы выбрать поле и каждое дополнительное проверка и оставьте значение по умолчанию 200. Выбрав параметр "Достичь виртуальных байтов", автоматически создается дамп памяти, если виртуальные байты используют 1024 МБ. Если виртуальные байты увеличиваются на 200 МБ, автоматически создается другой дамп памяти.

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

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

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

      Примечание.

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

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

      Примечание.

      Теперь состояние правила — Отслеживание. При каждом создании дампа памяти значение будет увеличиваться в столбце Число пользователей на вкладке Правила . Расположение дампа памяти по умолчанию — C:\Program Files\DebugDiag\Logs.

Способ 2. Вручную

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

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

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

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

Когда процесс достигает 60-80 процентов ОЗУ, щелкните правой кнопкой мыши Btsntsvc.exe процесс и выберите Create Полный userdump. Если процесс BizTalk останавливается перед созданием дампа пользователя, правило сбоя должно вступить в силу и создать дамп памяти.

Остановка ведения журнала Монитор производительности

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

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

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

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

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

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

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

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

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