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

En este artículo se describe cómo solucionar una 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 pérdidas 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 a tener en cuenta al evaluar el uso de memoria y los posibles problemas relacionados con la memoria. Estas consideraciones incluyen las siguientes cosas:

  • 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?
  • El 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 físico de memoria y RAM

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 guía. Por ejemplo, si el BizTalk Server tiene 4 gigabytes (GB) de RAM y el proceso de BizTalk Server usa aproximadamente 500 megabytes (MB) de RAM, es posible que no se filtre. 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 ejecución prolongada. Asegúrese de saber cuánta memoria usa normalmente el host de BizTalk 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 es posible que se espere un uso elevado de memoria si BizTalk Server está procesando mensajes grandes. Es posible que quiera 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 modificador /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 en modo kernel. Además, este modificador puede aumentar el riesgo de quedarse sin memoria del grupo.

Cuando el modificador /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 de 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 alta 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 usados 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 los 2 GB. Esta situación puede producirse aunque la memoria máxima direccionable por un proceso 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é se puede producir esta situación, visite el siguiente sitio web de Microsoft Developer Network (MSDN):
ASP.NET supervisión del rendimiento y cuándo alertar a los administradores

El modificador /3GB también aumenta el número máximo de bytes privados 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 conmutador /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 se incluyen los límites prácticos para bytes virtuales y bytes privados.

Proceso Windows Memoria direccionable (con un proceso compatible con direcciones de gran tamaño) Límite práctico de bytes virtuales Límite práctico para bytes privados
32 bits 32 bits 2 GB 1400 MB 800 MB
32 bits 32 bits con /3 GB 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 64 bits, visite Límites de memoria para versiones de Windows y Windows Server.

En la tabla siguiente se muestra pae y compatibilidad con 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, es posible que desee 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 modificador /3GB está habilitado.

El modificador /3GB no se admite en equipos que ejecutan Windows SharePoint Services 2.0 o versiones posteriores o SharePoint Portal Server 2003 SP2 o versiones posteriores. El conmutador 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. Un problema de memoria común se produce 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 de 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 Mejora del 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, puede ver resultados variables entre ellos. Si usa .NET Framework, confirme que está instalado el Service Pack 1 de .NET Framework más reciente. Estos Service Pack solucionan varios problemas de memoria conocidos.

Número de procesadores

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

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

Si el equipo que ejecuta BizTalk Server es un sistema multiprocesador, .NET Framework usa la versión del servidor del motor de ejecución. Se trata del comportamiento predeterminado. El recolector de elementos no utilizados del servidor está diseñado para obtener el máximo rendimiento. 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 de 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. Sin embargo, pueden producirse problemas graves si modifica el registro incorrectamente. Por lo tanto, asegúrese de seguir estos pasos cuidadosamente. Para mayor protección, cree una copia de seguridad del registro antes de modificarlo. Después, puede restaurar el registro si se produce un problema. Para obtener más información sobre cómo hacer una copia de seguridad del Registro y cómo restaurarlo, consulte Cómo realizar una copia de seguridad del Registro y restaurarlo 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

Create lo 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

Create lo 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, consulte Consideraciones de rendimiento para las tecnologías de Run-Time en .NET Framework.

Las siguientes son causas y resoluciones comunes:

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

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 que el proceso de BizTalk consuma más memoria antes de que se produzca la 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, puede producirse 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, vea Propiedades predeterminadas de deshidratación.

Nota:

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

En hardware equivalente en 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 expandido (16 TB en lugar de 4 GB), a las instancias de host de 64 bits se les asigna 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 que está asignando 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 VirtualMemoryThrottling.Criteria a 6.069 MB (5.784.787.695 * 1,10 = 6.363.266.464,5 bytes).

Establezca el valor MaximalUsage para VirtualMemoryThrottlingCriteria en 7.889 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

A continuación, estos valores se representarán en el archivo BTSNTSvc64.exe.config como se indica a continuación:

<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 hacer coincidir el proceso de identificador de los contadores \BizTalk: Messaging\ID Process y \Process\ID Process Monitor de rendimiento. A continuación, compruebe el valor Promedio que se muestra para los contadores \Process\Virtual Bytes y \Process\Private Bytes Monitor de rendimiento correspondientes.

Nota:

Información que el usuario debe observar incluso si se descremaLa alta deshidratación puede provocar una disminución significativa del rendimiento cuando la BizTalkMsgBoxDb base de datos se ejecuta en SQL Server 2008.

BizTalk Server service pack y actualizaciones acumulativas

BizTalk Server service pack y 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 de montón de confirma cada página de 4 kilobytes (KB) que está disponible. Las operaciones de des commit pueden provocar la fragmentación de la memoria virtual. El tamaño de la HeapDeCommitFreeBlockThreshold configuración en el administrador del montón dependerá del tipo de trabajo que esté realizando 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 problemas de fragmentación de memoria.
  • Este cambio está en todo el sistema. Por lo tanto, la mayoría de los procesos usarán más memoria al iniciarse.
  • Considere este cambio solo para los sistemas que han 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 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 procesos al mismo tiempo.
  • Reduzca el tamaño del mensaje XML que se está transformando.

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 rooteado que no se elimina hasta que se reinicia el servicio de BizTalk.

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

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

Functoids ¿Script en línea?
Todos los functoids de cadena Yes
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 acumulativos Yes
Todos los functoids de base de datos No
Functoids avanzados ¿Script en línea?
Bucle functoid No
Value-Mapping functoid de aplanamiento No
Aserción de functoid No
Functoid del extractor de tablas No
Functoid de bucle de tabla No
Functoid de scripting con C insertado#
Functoid de scripting con JScript.NET en línea
Functoid de scripting con Visual Basic en línea .NET Yes
Functoid de scripting con XSLT en línea No
Functoid de scripting con plantilla de llamada XSLT insertada No
Scripting functoid que llama al ensamblado externo No
Functoid de valor nil No
Functoid de asignación de valores No
Functoid de copia masiva No
Functoid de iteración No
Functoid de índice No
Functoid de recuento 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 la 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 atributos 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 atributos o elementos 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 de HOST de BizTalk no procese varios documentos como estos al mismo tiempo.

Componentes de canalización personalizados

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

Streaming bajo mucho estrés

Los hosts de envío se que ejecutan sin memoria cuando operan bajo un fuerte estrés. 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 la 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 una gran tensión.

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 está 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 (1.600 * 50=80.000 KB).

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

Intente simplificar el problema.

Si ha identificado una pérdida de memoria, intente determinar la causa quitando componentes personalizados o simplificando 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 de memoria insuficiente, sabrá qué componentes están implicados.

Pasos para la solución de problemas

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

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

    El siguiente archivo está disponible para su descarga desde el Centro de descarga de Microsoft:
    Descargue el paquete de la herramienta de diagnóstico de depuración ahora

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

    Microsoft ha examinado este archivo en busca de virus. Microsoft usó el software de detección de virus más actual que estaba disponible en la fecha en que se publicó el archivo. El archivo se almacena en servidores mejorados de seguridad que ayudan a evitar cambios no autorizados en el archivo.

  2. Use Monitor de rendimiento para recopilar datos sobre el rendimiento del sistema. Estos datos pueden proporcionar indicadores importantes sobre la eficacia de su entorno de BizTalk Server. El objetivo es capturar el rendimiento de los procesos con el 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 de 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, después, haga clic en Agregar después de seleccionar cada objeto:

      • Excepciones CLR de .Net
      • Memoria CLR de .Net
      • BizTalk: Mensajería
      • BizTalk: TDDS
      • Memoria
      • Proceso
      • 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 Valor de intervalo de ejemplo a 5 segundos.

      Nota:

      El valor intervalo de ejemplo y el tiempo para empezar a supervisar son subjetivos. 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 saturar el servidor.

    11. Haga clic en Aceptar.

Para detener la recopilación de datos, haga clic en Detener en el menú Acción .

  • Para Windows Server 2003 o 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 la pestaña Archivos de registro y, a continuación, hacer 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 Objetos de rendimiento , seleccione los siguientes objetos. Haga clic en Agregar después de seleccionar cada objeto.

      • Excepciones CLR de .Net
      • Memoria CLR de .Net
      • BizTalk: Mensajería
      • BizTalk: TDDS
      • Memoria
      • Proceso
      • 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 intervalo de muestreo de datos y el tiempo para empezar a supervisar son subjetivos. 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 saturar el servidor.

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

Obtención del archivo de volcado

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 de pérdida de memoria y control se asocia automáticamente Leaktrack.dll. Esto se usa para realizar un seguimiento de las asignaciones de memoria. Para crear la regla de pérdida de memoria y control, siga estos pasos:

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

  2. Seleccione Memory and Handle Leak (Pérdida de memoria y control) 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 active la regla . De lo contrario, puede especificar un tiempo de preparación antes de que se inserteLeakTrack.dllen el proceso de BTSNTSvc.exe.

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

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

      • Haga clic para activar la casilla Generar un control de usuario cuando alcancen los bytes virtuales y mantenga el valor predeterminado de 1024.

      • Haga clic para seleccionar la casilla y cada otra adicional y mantenga el valor predeterminado de 200. Al seleccionar la opción de alcance de 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 & Cerrar.

    4. Haga clic en Siguiente.

    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 Userdump Location 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 si hay fugas.
  4. En el cuadro de diálogo Herramienta de diagnóstico de depuración , haga clic en y, a continuación, haga clic en Aceptar.

Create 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 el mismo proceso de Btsntsvc.exe 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 la RAM, haga clic con el botón derecho en el proceso de Btsntsvc.exe y, a continuación, haga clic en Create Control de usuario completo. Si el proceso de BizTalk se detiene antes de 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 unos dos minutos después de crear el volcado de memoria.

Análisis del archivo de volcado

Para ayudar a determinar la causa de una pérdida de memoria, puede usar la herramienta Diagnósticos de depuración para analizar el archivo de volcado. Para ello, siga estos pasos:

  1. Haga clic en la pestaña Análisis avanzado .
  2. Haga clic en Agregar archivos de datos y, a continuación, 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 del 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 Símbolo Búsqueda Ruta de acceso para depuración, escriba la ruta de acceso del símbolo.

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

Antes de ponerse en contacto con los servicios de soporte 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.