Compartir a través de


Solución de problemas de pérdida de memoria o una excepción de memoria insuficiente en el proceso de BizTalk Server

En este artículo se describe cómo solucionar problemas de pérdida de memoria o una excepción de memoria insuficiente en el proceso de BizTalk Server de Microsoft BizTalk Server.

Versión original del producto: BizTalk Server 2010, 2009
Número de KB original: 918643

Resumen

Las fugas de memoria son un problema común. Es posible que tenga que probar varios pasos para encontrar la causa específica de una pérdida de memoria o una excepción de memoria insuficiente (OOM) en Microsoft BizTalk Server. En este artículo se describen aspectos importantes que se deben tener en cuenta al evaluar el uso de memoria y posibles problemas relacionados con la memoria. Estas consideraciones incluyen lo siguiente:

  • RAM física
  • Procesamiento de mensajes grandes
  • Uso del modificador /3GB
  • Uso de componentes personalizados
  • Qué versión de Microsoft .NET Framework está ejecutando el sistema
  • Número de procesadores

El proceso de BizTalk Server puede estar experimentando una pérdida de memoria cuando el uso de memoria en el Administrador de tareas de Microsoft Windows consume más del 50 % de la RAM física. Una pérdida de memoria puede provocar una excepción de memoria insuficiente cuando el uso de memoria aumenta hasta que el proceso se queda sin memoria del sistema o hasta que el proceso deja de funcionar. Para este problema, tenga en cuenta lo siguiente:

Uso de memoria y RAM física

Dado que puede ser un comportamiento esperado para que un proceso use aproximadamente la mitad de la RAM física, use el uso de memoria como una guía. Por ejemplo, si BizTalk Server tiene 4 gigabytes (GB) de RAM y el proceso de BizTalk Server usa aproximadamente 500 megabytes (MB) de RAM, puede que no haya pérdidas. Si el proceso de BizTalk Server usa aproximadamente 1 GB de RAM, puede haber una pérdida de memoria o una situación de memoria alta. El consumo de memoria puede deberse a un procedimiento almacenado o orquestación de larga duración. Asegúrese de saber cuánta memoria usa el host de BizTalk normalmente para determinar si se está produciendo una pérdida de memoria o una condición de memoria alta.

Mensajes grandes

Cuando BizTalk Server procesa mensajes grandes, el sistema parece tener una pérdida de memoria. Sin embargo, los mensajes pueden usar una gran cantidad de memoria.

Además, tenga en cuenta que se puede esperar un uso elevado de memoria si BizTalk Server está procesando mensajes grandes. Es posible que desee actualizar el hardware para cumplir los requisitos de rendimiento de BizTalk Server en su entorno.

Cuánto tiempo se tarda en reproducir la pérdida de memoria

Las pérdidas de memoria pueden producirse inmediatamente o pueden acumularse con el tiempo. Ambos escenarios son comunes.

Uso del conmutador /3GB en equipos de 32 bits

Normalmente, un proceso puede acceder a 2 GB de espacio de direcciones virtuales. El modificador /3GB es una opción para sistemas que requieren más memoria direccionable. Esta opción puede mejorar el uso de memoria para procesar mensajes. Sin embargo, el modificador /3GB solo permite 1 GB de memoria direccionable para las operaciones del modo kernel. Además, este modificador puede aumentar el riesgo de quedarse sin memoria del grupo.

Cuando el conmutador /3GB está habilitado en una versión de 32 bits de Windows, el proceso puede acceder a 3 GB de espacio de direcciones virtuales si el proceso es compatible con direcciones grandes. Un proceso es compatible con direcciones grandes cuando el ejecutable tiene la marca IMAGE_FILE_LARGE_ADDRESS_AWARE establecida en el encabezado de imagen. Dado que el proceso de BizTalk es compatible con direcciones grandes, BizTalk se beneficiará del modificador /3GB.

Si una instancia de host de BizTalk de 32 bits se ejecuta en una versión de 64 bits de Windows (AMD64), el proceso de BizTalk se beneficia del espacio de direcciones de memoria de 4 GB porque BizTalk es compatible con direcciones grandes. Por lo tanto, mover las aplicaciones de memoria elevada a un servidor de 64 bits puede ser la mejor solución.

Un proceso de BizTalk de 64 bits en una versión de 64 bits de Windows (AMD64) tiene 8 TB de memoria direccionable.

También debe tener en cuenta los bytes virtuales y los bytes privados utilizados por el proceso. Una instancia de host de BizTalk (que es una aplicación de .NET Framework) puede recibir un error de memoria insuficiente antes de que el valor de Bytes virtuales alcance 2 GB. Esta situación puede producirse aunque el proceso direccionable de memoria máxima en una versión de 32 bits de Windows (sin el modificador /3GB) sea de 2 GB. Para obtener una explicación de por qué puede producirse esta situación, visite el siguiente sitio web de Microsoft Developer Network (MSDN):
ASP.NET Monitor de rendimiento y Cuándo alertar a los administradores

El modificador /3GB también aumenta los bytes privados máximos del proceso de BizTalk de 800 MB a 1800 MB. Para obtener más información sobre el rendimiento de las aplicaciones de .NET Framework con el modificador /3GB habilitado, visite capítulo 17: Optimización del rendimiento de la aplicación .NET.

En la tabla siguiente se resume esta información e incluye los límites prácticos de bytes virtuales y bytes privados.

Proceso Windows Memoria direccionable (con un proceso grande con reconocimiento de direcciones) Límite práctico para bytes virtuales Límite práctico para bytes privados
32 bits 32 bits 2 GB 1400 MB 800 MB
32 bits 32 bits con /3GB 3 GB 2400 MB 1800 MB
32 bits 64 bits 4 GB 3400 MB 2800 MB
64 bits 64 bits 8 TB No aplicable No aplicable

Para obtener más información sobre la memoria direccionable para Windows de 32 bits frente a Windows de 64 bits, visite Límites de memoria para versiones de Windows y Windows Server.

En la tabla siguiente se enumeran la compatibilidad con PAE y 3 GB para diferentes versiones de BizTalk Server.

Producto PAE 3 GB
BizTalk Server 2004 No
BizTalk Server 2006
BizTalk Server 2006 R2
BizTalk Server 2009

Si debe habilitar el modificador /3GB para cumplir los requisitos de rendimiento de un equipo que ejecuta BizTalk Server, puede considerar la posibilidad de agregar servidores al grupo de BizTalk. Esto le permite escalar horizontalmente las instancias de host que consumen mucha memoria.

Los componentes de BizTalk que se ejecutan dentro de un proceso de Internet Information Services (IIS) también pueden beneficiarse cuando el conmutador /3GB está habilitado.

El modificador /3GB no es compatible con equipos que ejecutan Windows SharePoint Services 2.0 o versiones posteriores o SharePoint Portal Server 2003 SP2 o versiones posteriores. El modificador Windows Server 2003 /3GB no se admite en Windows SharePoint Services 2.0 o en versiones posteriores o en SharePoint Portal Server 2003 Service Pack 2 o en versiones posteriores.

Uso de componentes personalizados

Si usa componentes personalizados, como canalizaciones o componentes de servicio, debe saber lo que hacen estos componentes. También debe conocer el posible efecto de estos componentes en el uso de memoria. Se produce un problema de memoria común cuando un componente está transformando un documento. La operación de transformación es una operación que consume mucha memoria. Cuando se transforma un documento, BizTalk Server pasa la secuencia de mensajes a la clase microsoft .NET Framework XslTransform dentro del proceso de BizTalk.

Otro problema común se produce cuando hay una manipulación intensiva de cadenas. La manipulación intensiva de cadenas puede consumir muchos recuerdos. Para obtener más información sobre las formas de mejorar el rendimiento, visite Mejorar el rendimiento del código administrado.

Versión de .NET Framework

Microsoft .NET Framework 2.0 y .NET Framework 1.1 tienen un comportamiento de memoria diferente. Por lo tanto, es posible que vea resultados variables entre ellos. Si usa .NET Framework, confirme que está instalado el Service Pack 1 de .NET Framework más reciente. Este Service Pack soluciona varios problemas de memoria conocidos.

Número de procesadores

Common Language Runtime (CLR) tiene los siguientes recolectores de elementos no utilizados (GCs):

  • Estación de trabajo (Mscorwks.dll)
  • Servidor (Mscorsvr.dll)

Si el equipo que ejecuta BizTalk Server es un sistema multiprocesador, .NET Framework usa la versión server del motor de ejecución. Este es el comportamiento predeterminado. El recolector de elementos no utilizados del servidor está diseñado para un rendimiento máximo. Además, el recolector de elementos no utilizados del servidor se escala para proporcionar un alto rendimiento. Este recolector de elementos no utilizados asigna memoria y, a continuación, libera memoria para proporcionar un alto rendimiento en el sistema. Por lo tanto, un equipo que ejecuta BizTalk Server junto con algunos componentes de .NET Framework parece tener una pérdida de memoria. Sin embargo, en este escenario, el uso elevado de memoria es el comportamiento esperado. Si el equipo se queda sin memoria del sistema o si el proceso deja de funcionar debido a una memoria direccionable insuficiente, puede existir una condición de pérdida de memoria.

Si el equipo que ejecuta BizTalk Server es un único sistema de procesador, .NET Framework usa la versión de estación de trabajo del motor de ejecución. Es el comportamiento predeterminado. El algoritmo de asignación del recolector de elementos no utilizados de estación de trabajo no está diseñado para el escalado ni para el rendimiento máximo. Este recolector de elementos no utilizados usa métodos simultáneos del recolector de elementos no utilizados. Estos métodos están diseñados para aplicaciones que tienen interfaces de usuario complejas. Estas aplicaciones pueden requerir una recolección de elementos no utilizados más agresiva.

Importante

Esta sección, método o tarea contiene pasos que le indican cómo modificar el Registro. Pero pueden producirse problemas graves si modifica el registro incorrectamente. Por lo tanto, asegúrese de seguir estos pasos cuidadosamente. Para la protección añadida, realice una copia de seguridad del Registro antes de modificarlo. A continuación, puede restaurar el Registro si se produce un problema. Para obtener más información sobre cómo realizar copias de seguridad y restaurar el registro, vea Cómo hacer copia de seguridad y restaurar el registro en Windows.

A veces, puede ser adecuado ejecutar la versión de estación de trabajo del motor de ejecución en un sistema multiprocesador. Puede usar la siguiente clave del Registro para cambiar a la versión de estación de trabajo del motor de ejecución.

BizTalk 2006 y versiones posteriores

Cree la siguiente CRL Hosting clave del Registro de cadena con los valores correspondientes:

  • Clave: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$BizTalkHostName\CLR Hosting
  • Nombre del valor: Flavor
  • Datos de valor: wks

BizTalk 2004

Cree la siguiente CRL Host clave del Registro de cadena con los valores correspondientes:

  • Clave: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BTSSvc{GUID }\CLR Hosting
  • Nombre del valor: Flavor
  • Datos de valor: wks

Para obtener más información, visite Consideraciones de rendimiento para tecnologías en tiempo de ejecución en .NET Framework.

A continuación se muestran las causas comunes y las resoluciones:

Umbrales de limitación de uso de memoria física y proceso

El uso de memoria de proceso y los umbrales de limitación de uso de memoria física se pueden cambiar en BizTalk Server 2006 y en versiones posteriores.

  • De forma predeterminada, el umbral de limitación de uso de memoria de proceso se establece en 25. Si se supera este valor y el uso de memoria del proceso de BizTalk es superior a 300 MB, puede producirse una condición de limitación. En un servidor de 32 bits, puede aumentar el valor de uso de memoria de proceso a 50. En un servidor de 64 bits, puede aumentar este valor a 100. Esto permite un mayor consumo de memoria por parte del proceso de BizTalk antes de que se produzca una limitación.

  • El umbral de limitación de uso de memoria física tiene un valor predeterminado de 0. Este umbral mide la memoria total del sistema. Por lo tanto, si se configura un valor distinto de 0, se puede producir una condición de limitación si un proceso que no es de BizTalk usa memoria alta.

Umbrales de limitación de deshidratación

Los umbrales de deshidratación de memoria predeterminados pueden provocar demasiada deshidratación cuando se ejecutan orquestaciones en un host de 64 bits. Para obtener más información sobre este problema, consulte Propiedades predeterminadas de deshidratación.

Nota:

Los hosts de 64 bits se admiten en BizTalk Server 2006 y versiones posteriores.

En el hardware equivalente de una instancia de host de 32 bits, la deshidratación observada es nominal cuando se ejecutan las mismas orquestaciones mediante los umbrales de limitación de deshidratación de memoria predeterminados.

Dado que la arquitectura de 64 bits proporciona espacio de direcciones de memoria expandida (16 TB en lugar de 4 GB), las instancias de host de 64 bits se asignan más memoria que las instancias de host de 32 bits. Esto puede hacer que se superen los umbrales de limitación de memoria predeterminados.

Para solucionar este comportamiento, cambie los valores VirtualMemoryThrottlingCriteria y PrivateMemoryThrottlingCriteria en el archivo BTSNTSvc64.exe.config. Use los contadores \Process\Virtual Bytes y \Process\Private Bytes Monitor de rendimiento para determinar la mayor cantidad de memoria asignada por una instancia de orquestación.

  • Establezca el valor OptimalUsage para ambas propiedades en función de lo siguiente:

    • VirtualMemoryThrottlingCriteria: \Process\Virtual Bytes value + 10%
    • PrivateMemoryThrottlingCriteria: \Process\Private Bytes value + 10%
  • Establezca MaximalUsage para ambas propiedades en el valor OptimalUsage + 30 %

Por ejemplo, si el valor del contador \Process\Virtual Byte Monitor de rendimiento para una instancia de orquestación es de 5.784.787.695 bytes (5.517 MB), establezca el valor OptimalUsage para VirtualMemoryThrott.lingCriteria a 6,069 MB (5,784,787,695 * 1,10 = 6,363,266,464,5 bytes).

Establezca el valor MaximalUsage de VirtualMemoryThrottlingCriteria en 7889 MB (6,363,266,464,5 * 1,30 = 8,272,246,403,85 bytes).

Si el valor del contador \Process\Private Bytes Monitor de rendimiento es 435689400 bytes (415 MB), establezca el valor OptimalUsage para PrivateMemoryThrottlingCriteria en 457 MB (435689400 * 1,10 = 479258340 bytes).

Establezca el valor MaximalUsage para PrivateMemoryThrottlingCriteria en 594 MB (479258340 * 1,30 = 623035842).

En este ejemplo, se especificarían los siguientes valores en el archivo BTSNTSvc64.exe.config para reducir la limitación.

contador de Monitor de rendimiento Memoria asignada OptimalUsage MaximalUsage
\Process\Virtual Bytes 5.784.787.695 bytes (5517 MB) 6069 7889
\Process\Private Bytes 435 689 400 bytes (415 MB) 457 594

Estos valores se representarían en el archivo BTSNTSvc64.exe.config de la siguiente manera:

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

Para determinar qué instancia de host ejecuta la orquestación, puede coincidir con el proceso de identificador desde los contadores \BizTalk: Messaging\ID Process y \Process\ID Process Monitor de rendimiento. A continuación, compruebe el valor promedio mostrado para los contadores \Process\Virtual Bytes y \Process\Private Bytes Monitor de rendimiento correspondientes.

Nota:

Información que el usuario debe tener en cuenta aunque se desmonteLa alta deshidratación puede provocar una disminución significativa del rendimiento cuando la BizTalkMsgBoxDb base de datos se ejecuta en SQL Server 2008.

Service Packs de BizTalk Server y actualizaciones acumulativas

Los Service Packs de BizTalk Server y las actualizaciones acumulativas incluyen las correcciones más recientes. Estos incluyen aquellos que afectan a problemas conocidos System.OutOfMemoryException .

HeapDeCommitFreeBlockThreshold

De forma predeterminada, el valor de la clave del HeapDeCommitFreeBlockThreshold Registro es 0. Un valor de 0 significa que el administrador del montón desafirma cada página de 4 kilobytes (KB) que esté disponible. Las operaciones de desafirmación pueden provocar la fragmentación de memoria virtual. El tamaño de la HeapDeCommitFreeBlockThreshold configuración en el administrador del montón dependerá del tipo de trabajo que realiza el sistema. Un tamaño de 0x00040000 es un valor inicial recomendado.

Tenga en cuenta la siguiente información antes de cambiar el valor de la clave del HeapDeCommitFreeBlockThreshold Registro:

  • Este cambio solo se aplica a los problemas de fragmentación de memoria.
  • Este cambio es de todo el sistema. Por lo tanto, la mayoría de los procesos usarán más memoria al iniciarse.
  • Solo tenga en cuenta este cambio para los sistemas que tienen BizTalk Server como su misión principal.

Para ayudar a reducir la fragmentación de memoria virtual, puede aumentar el tamaño de la HeapDeCommitFreeBlockThreshold configuración en el administrador del montón cambiando el valor de la siguiente clave del Registro en HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager:

  • Nombre del valor: HeapDeCommitFreeBlockThreshold
  • Tipo de valor: REG_DWORD
  • Datos de valor: 0x00040000 (es el valor inicial recomendado).
  • Valor predeterminado: no está presente

Operaciones de transformación

Cuando BizTalk Server realiza operaciones de transformación XML en mensajes bastante grandes en un puerto de recepción, en un puerto de envío o en XLANG, las transformaciones XSL cargan todo el mensaje en la memoria.

Para solucionar este problema, use uno de los métodos siguientes:

  • Reduzca el número de mensajes que BizTalk Server procesa al mismo tiempo.
  • Reduzca el tamaño del mensaje XML que se va a transformar.

El System.Policy.Security.Evidence objeto se usa con frecuencia en transformaciones y puede consumir mucha memoria. Cuando un mapa contiene un scripting functoid que usa C# insertado (o cualquier otro lenguaje insertado), el ensamblado se crea en memoria. El System.Policy.Security.Evidence objeto usa el objeto del ensamblado de llamada real. Esta situación crea un objeto raíz que no se elimina hasta que se reinicia el servicio de BizTalk.

La mayoría de las opciones predeterminadas de BizTalk functoids se implementan como script insertado. Estos elementos pueden hacer que System.Byte[] los objetos se recopilen en la memoria. Para minimizar el consumo de memoria, se recomienda colocar cualquier asignación que los use functoids en un ensamblado pequeño. A continuación, haga referencia a ese ensamblado. Use el gráfico siguiente para determinar qué functoids uso de script insertado y qué functoids no usan script insertado.

En la segunda columna, significa que esto functoid se implementa como script insertado y que hará System.Byte[] que los objetos se recopilen en la memoria. No significa que esto functoid no se implementa como script insertado y que no hará System.Byte[] que los objetos se recopilen en la memoria.

Functoids ¿Script insertado?
Todos los functoids de cadena
Todos los functoids matemáticos
Todos los functoids lógicos excepto IsNil
Functoid IsNil lógico No
Todos los functoids de fecha y hora
Todos los functoids de conversión
Todos los functoids científicos
Todos los functoids acumulados
Todos los functoids de base de datos No
Functoids avanzados ¿Script insertado?
Functoid de bucle No
Functoid de asignación de valores sin formato No
Functoid de aserción No
Functoid Extractor de tablas No
Functoid Bucle de tabla No
Scripting Functoid con Inline C#
Functoid de scripting con JScript.NET en línea
Functoid de scripting con Visual Basic .NET insertado
Functoid de scripting con XSLT insertado No
Scripting functoid con plantilla de llamada XSLT insertada No
Scripting Functoid que llama a un ensamblado externo No
Functoid de valor nulo No
Functoid de asignación de valores No
Functoid de copia masiva No
Functoid de iteración No
Functoid de índice No
Functoid de número de registros No

BizTalk Server 2006 y versiones posteriores mejoran significativamente la administración de memoria para documentos grandes. Para ello, BizTalk Server implementa un umbral de tamaño de mensaje configurable para cargar documentos en memoria durante las operaciones de transformación. El umbral de tamaño de mensaje predeterminado es de 1 MB. Para obtener más información sobre la configuración TransformThreshold, visite How BizTalk Server Processes Large Messages (Cómo BizTalk Server procesa mensajes grandes).

Valores de atributo grandes y valores de elementos grandes

Cuando BizTalk Server ejecuta una canalización de recepción o una canalización de envío en un documento XML, la carga se procesa en memoria si el documento contiene una o varias de las siguientes entidades:

  • Valores de atributo grandes
  • Valores de elementos grandes
  • Etiquetas de elemento o atributo grandes

Para resolver este problema, limite el tamaño de estas entidades. Si este método no es posible, asegúrese de que la instancia host de BizTalk no procese varios documentos como estos al mismo tiempo.

Componentes de canalización personalizados

Usa un componente de canalización personalizado que carga todo el flujo en la memoria. Todos los componentes que se incluyen con BizTalk Server, excepto las transformaciones, admiten streaming. Estos componentes no usan tanta memoria durante el streaming. Sin embargo, es posible que los componentes de canalización personalizados no admitan streaming.

Streaming bajo estrés pesado

Enviar hosts se quedas sin memoria cuando funcionan bajo un estrés pesado. BizTalk Server envía canalizaciones y envía adaptadores que admiten streaming. En streaming, cada componente carga un pequeño fragmento de la secuencia en memoria. Dado que cada mensaje incluye otras estructuras de datos, junto con un contexto de mensaje que puede ser significativo o pequeño, este comportamiento afecta al comportamiento de BizTalk Server bajo un estrés intensivo.

El comportamiento de BizTalk Server se ve afectado porque el motor carga un número preconfigurado de mensajes. El número de mensajes que carga el motor se basa en los valores que aparecen en el campo LowWaterMark y en el campo HighWaterMark de la Adm_serviceClass tabla. La Adm_serviceClass tabla se encuentra en la base de datos de administración de BizTalk. Estos valores controlan el número de mensajes que BizTalk Server procesa o envía al mismo tiempo.

El valor de HighWaterMark es el número total de mensajes que el motor procesa al mismo tiempo. El valor predeterminado es 200 mensajes por CPU. Por lo tanto, en un servidor de 8 procesadores, el host de envío intentará procesar 1600 mensajes (200 * 8) al mismo tiempo.

Si supone que cada mensaje es de 50 KB, los mensajes son iguales a 80 MB (1600 * 50=80 000 KB).

Para resolver este problema, puede cambiar el valor highWaterMark y el valor de LowWaterMark en la base de datos. Los valores que use dependen del tamaño de los mensajes. Para BizTalk Server 2006 y versiones posteriores, puede cambiar la configuración de limitación de host predeterminada.

Intente simplificar el problema

Si ha identificado una pérdida de memoria, intente determinar la causa mediante la eliminación de componentes personalizados o simplifique un mapa. Además, intente reproducir el problema mediante una orquestación simple o una solución sencilla. Normalmente, debe crear hosts de recepción independientes para adaptadores de recepción. También debe crear hosts de envío independientes para adaptadores de envío. Cuando se usa este método, cada adaptador se puede ejecutar en un proceso independiente. Por lo tanto, si el proceso de BizTalk Server experimenta una condición fuera de memoria, sabrá qué componentes están implicados.

Pasos para solucionar problemas

Para solucionar problemas de una condición de memoria insuficiente, use la herramienta Debug Diagnostics para supervisar las asignaciones de memoria a lo largo del tiempo. La herramienta Debug Diagnostics puede crear y analizar un archivo de volcado de memoria (.dmp). Al solucionar problemas de fugas de memoria, el objetivo es asociar Leaktrack.dll antes de que la condición de memoria alta se reproduzca para capturar el crecimiento de la memoria a lo largo del tiempo. Leaktrack.dll se incluye con la herramienta Debug Diagnostics.

  1. Instale la herramienta de diagnóstico de depuración.

    El siguiente archivo se puede descargar desde el Centro de descarga de Microsoft:
    Descargar el paquete de la herramienta de diagnóstico de depuración ahora

    Para más información sobre cómo descargar los archivos de soporte, consulte Cómo obtener los archivos de soporte de Microsoft de los servicios en línea.

    Microsoft examinó este archivo en busca de virus. Microsoft usó el software de detección de virus más reciente que había disponible en la fecha en la que se publicó el archivo. El archivo está guardado en servidores de seguridad mejorada que ayudan a prevenir cambios no autorizados del archivo.

  2. Use Monitor de rendimiento para recopilar datos sobre el rendimiento del sistema. Estos datos pueden proporcionar indicadores importantes sobre la eficacia del entorno de BizTalk Server. El objetivo es capturar el rendimiento del proceso a lo largo del tiempo. Por lo tanto, habilite Monitor de rendimiento registro antes de que se produzca la pérdida de memoria.

Uso del registro de Monitor de rendimiento

En las secciones siguientes se describe cómo usar el registro del monitor de rendimiento.

Selección de los datos que se van a registrar

Para seleccionar los datos que se van a registrar, use el método adecuado para el sistema operativo:

  • Para Windows Server 2008 y Windows Server 2008 R2
    1. En Herramientas administrativas, abra Confiabilidad y Monitor de rendimiento.

    2. Haga clic con el botón derecho en Monitor de rendimiento, haga clic en Nuevo y, a continuación, haga clic en Conjunto de recopiladores de datos.

    3. En el cuadro Nombre , escriba un nombre descriptivo y, a continuación, haga clic en Siguiente.

    4. Anote el directorio Raíz y, a continuación, haga clic en Siguiente.

    5. Haga clic en Iniciar este conjunto de recopiladores de datos ahora y, a continuación, haga clic en Finalizar.

    6. Expanda Conjuntos de recopiladores de datos, expanda Definido por el usuario y, a continuación, seleccione el archivo.

    7. Haga clic con el botón derecho en Registro del Monitor del sistema y, a continuación, haga clic en Propiedades.

    8. Haga clic en Agregar en la pestaña Contadores de rendimiento. Seleccione los siguientes objetos y, a continuación, haga clic en Agregar después de seleccionar cada objeto:

      • Excepciones de .Net CLR
      • Memoria clR de .Net
      • BizTalk: mensajería
      • BizTalk: TDDS
      • Memoria
      • Process
      • Procesador
      • Orquestaciones XLANG/s

      Si SQL Server es local, agregue también los siguientes objetos:

      • SQLServer: Bases de datos
      • SQLServer: Estadísticas generales
      • SQLServer: Administrador de memoria
    9. Haga clic en Aceptar.

    10. Cambie el cuadro De valor intervalo de ejemplo a 5 segundos.

      Nota:

      El valor intervalo de ejemplo y el tiempo de inicio del monitor son subjetivas. Estos valores dependen de cuándo se reproduce la pérdida de memoria. Dado que el archivo de registro puede ser grande, especifique un intervalo en el que pueda obtener la información que debe tener sin sobrecargar el servidor.

    11. Haga clic en Aceptar.

Para dejar de recopilar datos, haga clic en Detener en el menú Acción.

  • Para Windows Server 2003 o para Windows XP

    1. Expanda Registros de rendimiento y Alertas.

    2. Haga clic con el botón derecho en Registros de contador y, a continuación, haga clic en Nueva configuración de registro. Aparece el cuadro de diálogo Nueva configuración de registro.

    3. En el cuadro Nombre , escriba un nombre descriptivo y, a continuación, haga clic en Aceptar.

    4. Anote la ubicación del archivo de registro. (También puede hacer clic en el Pestaña Archivos de registro y, a continuación, haga clic en Configurar para cambiar la ubicación del archivo de registro).

    5. Haga clic en Agregar contadores.

    6. Seleccione Todos los contadores y Todas las instancias.

    7. En la lista Objeto de rendimiento, seleccione los siguientes objetos. Haga clic en Agregar después de seleccionar cada objeto.

      • Excepciones de .Net CLR
      • Memoria clR de .Net
      • BizTalk: mensajería
      • BizTalk: TDDS
      • Memoria
      • Process
      • Procesador
      • Orquestaciones XLANG/s

      Si SQL Server es local, agregue también los siguientes objetos:

      • SQLServer: Bases de datos
      • SQLServer: Estadísticas generales
      • SQLServer: Administrador de memoria
    8. Haga clic en Cerrar.

    9. Cambie el valor de Intervalo de muestreo de datos a 5 segundos.

      Nota:

      El valor del intervalo de muestreo de datos y el tiempo para empezar a supervisar son subjetivas. Estos valores dependen de cuándo se reproduce la pérdida de memoria. Dado que el archivo de registro puede ser grande, especifique un intervalo en el que pueda obtener la información que debe tener sin sobrecargar el servidor.

    10. Haga clic en Aceptar. Para dejar de recopilar datos, haga clic con el botón derecho en el nombre del registro del contador y, a continuación, haga clic en Detener.

Obtener el archivo de volcado de memoria

Para obtener el archivo de volcado de memoria, use uno de los métodos siguientes:

Método 1: Automático

La creación de una regla de pérdida de memoria y control con DebugDiag es el enfoque recomendado para capturar un volcado de memoria. La regla Memoria y control de pérdida adjunta automáticamente Leaktrack.dll. Se usa para realizar un seguimiento de las asignaciones de memoria. Para crear la regla Memoria y controlar fugas, siga estos pasos:

  1. Inicie La herramienta de diagnóstico de depuración 1.1.

  2. Seleccione Memoria y Controlar fugas y, a continuación, haga clic en Siguiente.

  3. Seleccione el proceso de Btsntsvc.exe y, a continuación, haga clic en Siguiente.

  4. En la página Configurar regla de fugas, siga estos pasos:

    1. Haga clic para activar la casilla Iniciar seguimiento de memoria inmediatamente cuando se activa la regla. De lo contrario, puede especificar un tiempo de preparación antes de que LeakTrack.dll se inserte en el proceso de BTSNTSvc.exe.

    2. Haga clic en Configurar y, a continuación, haga lo siguiente:

      • Confirme que está seleccionada la opción Crear automáticamente una regla de bloqueo. Al seleccionar esta opción, se creará automáticamente un volcado de memoria si el proceso de BTSNTSvc.exe se detiene.

      • Haga clic para activar la casilla Generar una marca de usuario cuando se alcancen bytes virtuales y mantenga el valor predeterminado de 1024.

      • Haga clic para seleccionar y cada casilla adicional y mantener el valor predeterminado de 200. Al seleccionar la opción de acceso a bytes virtuales, se creará automáticamente un volcado de memoria cuando los bytes virtuales usen 1024 MB. Si los bytes virtuales aumentan en 200 MB, se creará automáticamente otro volcado de memoria.

    3. Haga clic en Guardar y cerrar.

    4. Haga clic en Next.

    5. En la página Seleccionar ubicación de volcado y nombre de regla, haga clic en Siguiente.

      Nota:

      También puede cambiar la ruta de acceso del archivo de volcado en el cuadro Ubicación de Userdump de esta página.

    6. Haga clic en Finalizar para activar la regla ahora.

      Nota:

      El estado de la regla ahora es Seguimiento. Cada vez que se crea un volcado de memoria, el valor aumentará en la columna Userdump Count de la pestaña Reglas . La ubicación de volcado de memoria predeterminada es C:\Program Files\DebugDiag\Logs.

Método 2: Manual

También puede adjuntar manualmente Leaktrack.dll y obtener manualmente el archivo de volcado de memoria. Esto le permite controlar cuándo se crea el volcado de memoria. Para ello, siga estos pasos:

  1. Inicie La herramienta de diagnóstico de depuración 1.1.
  2. Haga clic en la pestaña Procesos .
  3. Haga clic con el botón derecho en el proceso de Btsntsvc.exe y, a continuación, haga clic en Supervisar fugas.
  4. En el cuadro de diálogo Herramienta de diagnóstico de depuración, haga clic en Síy, a continuación, haga clic en Aceptar.

Cree una regla de bloqueo para supervisar el mismo proceso de Btsntsvc.exe en caso de que el proceso se detenga antes de poder crear el volcado de memoria:

  1. Inicie La herramienta de diagnóstico de depuración 1.1.
  2. Seleccione Bloquear y, a continuación, haga clic en Siguiente.
  3. Seleccione un proceso específico y, a continuación, haga clic en Siguiente.
  4. Seleccione la misma Btsntsvc.exe proceso y, a continuación, haga clic en Siguiente.
  5. En la página Configuración avanzada (opcional), haga clic en Siguiente.
  6. En el cuadro de diálogo Seleccionar ubicación de volcado y nombre de regla (opcional), haga clic en Siguiente.
  7. Seleccione Activar la regla ahora y, a continuación, haga clic en Finalizar.

Cuando el proceso alcanza el 60 % al 80 % de ram, haga clic con el botón derecho en el proceso de Btsntsvc.exe y, a continuación, haga clic en Crear usuario completo. Si el proceso de BizTalk se detiene antes de poder crear el volcado de usuario, la regla de bloqueo debe surtir efecto y crear el volcado de memoria.

Detener el registro de Monitor de rendimiento

Si va a capturar un volcado de memoria y Monitor de rendimiento datos, detenga Monitor de rendimiento registro aproximadamente dos minutos después de crear el volcado de memoria.

Análisis del archivo de volcado de memoria

Para ayudar a determinar la causa de una pérdida de memoria, puede usar la herramienta Debug Diagnostics para analizar el archivo de volcado de memoria. Para ello, siga estos pasos:

  1. Haga clic en la pestaña Análisis avanzado.
  2. Haga clic en Agregar archivos de datos y busque el archivo .dmp.
  3. Seleccione el script Análisis de presión de memoria y, a continuación, haga clic en Iniciar análisis.

De forma predeterminada, se creará un archivo de informe de análisis (el archivo .mht) en la C:\Program Files\DebugDiag\Reports carpeta cuando finalice el análisis. El archivo de informe también se mostrará en el explorador. El archivo de informe contiene los resultados del análisis. Además, el archivo de informe puede contener recomendaciones sobre cómo resolver la pérdida de memoria.

Si usa archivos DLL personalizados, puede agregar la ruta de acceso de símbolo de los archivos .pdb personalizados para su análisis. Para ello, siga estos pasos:

  1. Abra la herramienta Diagnósticos de depuración.
  2. En el menú Herramientas , haga clic en Opciones y configuración.
  3. En el cuadro Ruta de acceso de búsqueda de símbolos para depuración , escriba la ruta de acceso del símbolo.

Si desea ayuda para analizar el archivo de volcado de memoria, póngase en contacto con los Servicios de soporte técnico de Microsoft. Para obtener una lista completa de los números de teléfono de los Servicios de atención al cliente e información sobre los costos de soporte técnico, visite el contacto con el soporte técnico.

Antes de ponerse en contacto con los Servicios de atención al cliente, comprima el archivo de volcado, el registro de Monitor de rendimiento, el archivo de informe de análisis y los registros de eventos actualizados (archivos.evt). Es posible que tenga que enviar estos archivos a un ingeniero de soporte técnico de BizTalk Server.