1. Biztalk Server Performance
Aumento de la Memoria en Mensajería BizTalk
Por Kartik Paramasivam y Raied Malhas
Traducido desde xxx por Hernaldo González C. Ingeniero de Software
http://darkn.romhackhispano.org
naldo_go1@yahoo.es
(** Notas del traductor)
En este documento expondremos varias razones que hacen que BizTalk caiga en un
Out of Memory y sugeriremos algunas soluciones.
1. Introducción a los Host de BizTalk (Biztalk Hosts):
Antes de discutir acerca de las condiciones que se deben dar para obtener un Out of
Memory, vamos a hablar acerca de los hosts y como los adaptadores son mapeados
en ellos.
Los Adaptadores (de receptor y de envío) y las Orquestaciones corren bajo un
servicio BizTalk NT. Una instancia del Servicio BizTalk NT es llamada instancia host.
Puede recibir adaptadores (HTTP/SOAP) los cuales pueden correr en cualquier otro
proceso (por ejemplo IIS) en vez del Servicio BizTalk NT. Tales adaptadores son
llamados adaptadores aislados (isolated adapters).
Los Hosts en BizTalk tienen 1 o mas instancias host (procesos). La instalación por
defecto de BizTalk tiene 2 Hosts.
1) Host por defecto (Default host) (** BiztalkServerApplication)
2) Host aislado (Isolated Host).
Nota: Puedes tener solo 1 instancia host por cada host sobre un servidor dado.
Lo siguiente es mapear entre los "puntos finales" (puertos receptores y de envío) y
los hosts:
Puerto de Envío (Send port)-> Manejador de Envíos (Send Handler) -> Host de
Envío (Send Host)
Ubicación Receptora (Receive location) -> Manejador de Recepciones (Receive
Handler) -> Host de Recepción (Receive Host)
Típicamente debes crear separados los receive hosts para los receive adapters y
send hosts para todos los adaptadores. Haciendo esto le das a cada adaptador un
proceso separado para que corra. Esto garantiza que un adaptador no afecte a otro.
También si tu BizTalk host/proceso te da Out of Memory, sabrás cuantos
componentes están corriendo sobre ese proceso.
2. Las sospechas obvias cuando se tiene un Out of Memory:
Cuando el proceso entrega un Out Of Memory (OOM), necesitas primero encontrar
que componentes están corriendo sobre ese proceso. Si es posible, sigue las
recomendaciones listadas abajo para los adaptadores de recepción/envío por
separado y orquestaciones dentro de diferentes host. Una vez que lo hagas,
chequea si una de las 3 siguientes condiciones existen en el proceso que lanza el
OOM.
1) Estas ejecutando transformaciones/mapas con mensajes relativamente grandes
en los puertos receive/send o en XLANG. El punto aquí es que la transformación

2. XSL carga todo el mensaje en memoria para transformarlo.
Solución 1: Disminuir el número de mensajes que tu proceso opera a la vez
(sección sobre Send Host de abajo debe darte alguna idea).
Solución 2: Disminuir el tamaño del mensaje XML que estas transformando.
2) Estás ejecutando un pipeline XML receive/send sobre un documento que
contiene uno o más items como estos:
- Grandes valores en los atributos.
- Grandes valores en los elementos.
- Grandes atributos o tags.
Si uno de los elementos de arriba se encuentra en tu documento XML, entonces ese
ítem es completamente cargado en memoria.
Solución 1: trata de disminuir el tamaño de los objetos descritos anteriormente.
Solución 2: si no puedes disminuir el tamaño, asegúrate de que el proceso no
trabaja múltiples documentos concurrentemente (**a la vez). (Ve las secciones
siguientes sobre el limite de la concurrencia)
3) Tienes pipelines o adaptadores personalizados, que cargan documentos
completos en memoria. La mayoría de los componentes usados con BizTalk
(excepto transformaciones) soportan uso de stream que es contrario a cargar el
documento completo en memoria, y por lo tanto tiene bajo impresión de memoria.
Sin embargo, hemos visto que un pipeline personalizado escrito por clientes puede
o no soportar streaming.
3. Out of Memory en los Send Host:
Los Send Host de Adaptadores BizTalk pueden dar Out of Memory cuando se están
procesando un gran número de mensajes (por ejemplo cuando el sistema esta bajo
una alta carga de stress). Esto puede causar que la memoria usada por el Send
Host alcance rápidamente una condición de Out of Memory. Usualmente, los
grandes mensajes son procesados mas rápidos utilizando la memoria que usando
los procesos Host de BizTalk.
Calculando el numero Máximo de mensajes que son cargados en memoria por
procesos Send Host de BizTalk:
Bajo altas cargas de stress, el proceso de Send Host de BizTalk se cargará como
muchas instancias de mensajes dentro de la memoria como pueda hasta que el
numero de mensajes exceda el “HighWatermark”. (** Descarga este programa
para manejar parámetros Biztalk). Por defecto en BizTalk Server 2004 SP1, este
valor es 200 para mensajes. Lo siguiente te ayudará a configurar este valor, mas
detalles en las opciones de Watermark del documento “BizTalk Server Performance
Characteristics” en: http://www.gotdotnet.com/team/wsservers). Así, si tienes un
procesador Dual que está procesando grandes números de mensajes, el Host de
BizTalk carga un máximo de:
[Valor HighWatermark] * Numero de Procesadores
= 200 * 2
= 400 mensajes en memoria

3. (** Imagen agregada por el traductor)
Para un servidor Hyper-threaded: Si tienes un servidor hyper-threaded, entonces el
número de procesadores que percibe el Host de Envío de BizTalk es el doble que el
actual numero de procesadores. Así si tienes un Servidor Biztalk con procesador
Dual y si asumimos que el valor máximo por defecto para el número de de
instancias de mensajes procesadas a la vez es 200 (así, el valor ”HighWatermark”
es igual a 200), entonces el proceso BizTalk aloja un Send Host que cargará un
máximo de:
[valor HighWatermark]*[Numero Procesadores por una máquina Hyper-threaded]
= 200 * [Numero Procesadores * 2]
= 200 * [2 * 2]
= 200 * 4
= 800 mensajes en memoria
Así, en caso que tengas un servidor Biztalk con procesador hyper-threaded Dual
BizTalk con 2GigaBytes de RAM que está bajo alto stress, existe un posibilidad que
el SendHost caiga en un estado Out of Memory. El proceso en este caso cargará
800 mensajes (como se calculó arriba) en memoria. El siguiente gráfico muestra un
ejemplo donde la memoria usada del proceso send host aumenta rápidamente a
1.5 Giga Bytes en menos de 15 minutos:

4. Gráfico 1: Un ejemplo de un test donde se da la condición Out of Memory en un
SendHost que contiene un Adaptador tipo FILE.
Nota: La memoria usada por los Host BizTalk puede ser monitoreada usando
Performance Monitor (*o Process Explorer) para ver los “Private Bytes” usados por
las instancias host (receive, send, etc…) bajo el objeto "Proceso”.
Note: En un PC de 32 bit, el proceso puede subir 1.5 GB como Máximo (2 GB en
algunos caso muy raros) incluso si tienes mas memoria física de sobra (por ejemplo
8 GB RAM).
Como evitar el Out of Memory en un SendHost:
Afortunadamente, un Out of Memory puede ser evitado configurando la opción que
controla el máximo número de mensajes que pueden ser cargadas en memoria a la
vez.
Para configurar el número máximo de instancias de mensajes, en la Base de Datos
de Administración de BizTalk (el nombre por defecto es: “BizTalkMgmtDB”), abre la
tabla “adm_ServiceClass”. Ve la fila “Messaging InProcess”, por defecto, el valor
para LowWatermark es 100 y del HighWatermark es 200. El valor de
HighWatermark es el que dice el máximo de número de instancias de mensajes que
pueden ser cargados en memoria del proceso del Send Host. Cambia el valor de
Low y High Watermark a números menores, por ejemplo:
LowWatermark = 25
HighWatermark = 50
Si con esos valores (25-50) aun te da un OOM, debes bajar esos valores aun más
hasta que que no salga el Out of Memory.
El siguiente gráfico muestra un ejemplo del mismo test que se mostró arriba. En
este gráfico el valor de Low y HighWatermark fueron cambiados a 25-50

5. respectivamente. Nota como la memoria faltante se mantiene sin aumentar para
entrar en un Out of Memory:
Gráfico 2: Un ejemplo de un test que evita el Out of Memory en un SendHost con
un Adaptador FILE.
Nota: Bajando los valores de Watermark puede bajar el performance. Así que solo
baja esos valores si estás con un Out of Memory.
** Si estás en el caso que no logras bajar la memoria utilizada cuando estás
usando tus Pipelines propios, revisa el código de este como las variables mas
pesadas, por ejemplo: XMLDocuments, Arrays, ArrayList, etc, y si tienes, haz que
apunten a Null antes de salir del Pipeline, también puedes llamar al
GarbageCollector (instrucción GC.Collect()) antes de que termine de ejecutar el
Pipeline, esto ayuda a la liberación.
** Para ver la memoria usada por el Host (o los Host) de Biztalk más fácilmente,
puedes usar el ProcessExplorer, no se instala y es gratis. En View coloca los Private
Bytes parav ver la memoria que gasta cada proceso de tu sistema:

6. 4. Out of Memory en los Receive Hosts:
Es poco común ver un host que contenga un adaptador receptor que de out of
memory. Si esto pasara es típicamente debido a uno de los casos listados en la
sección 2.
Si ninguna de las recomendaciones sugeridas en la sección 2 puede ser realizada,
entonces reducir el número de mensajes procesadas a la vez puede ayudar al
receive host de caer en un out of memory.
Nota: Recuerda sin embargo que haciendo esto, disminuimos la concurrencia y por
lo tanto el performance bajará.
1) Reducir el tamaño del pool de mensajería (messaging engine thread pool): Un
usuario puede controlar el numero de hilos usados por el motor de mensajería para
publicar mensajes dentro del message box. Al reducir el número de hilos usados
por el motor de mensajería reducimos la taza por la cual el adaptador receptor
recibirá mensajes dentro del message box. Recuerda que esta opción solo necesita
ser hecha para el host correspondiente del receive handler del adaptador.
Por defecto el messaging engine crea 10 hilos por cpu para mensajes publicados.
Para especificar el tamaño del pool de mensajería:
1. Clic en Start, luego Run.
2. En la caja de diálogo escriba regedit y luego OK.
3. En el Editor de Registros, expande HKEY_LOCAL_MACHINE, abre SYSTEM, abre
CurrentControlSet, abre Services, botón derecho sobre BTSSvc* (debes primero
saber cual de los registros BTSSvc* corresponden al host correspondiente al receive

7. handler), escoge New, selecciona DWORD Value, coloca MessagingThreadPoolSize y
presiona ENTER.
4. En el Editor de Registros haz doble clic en MessagingThreadPoolSize.
En la ventana de dialogo Edit DWORD Value, en la caja Value, tipea un número
entre 1 y 30 y luego OK.
5. Nota para Adaptadores Personalizados (Custom Adapters):
Si has verificado todas las condiciones mostradas anteriormente y crees que tu
adaptador receptor/envío personalizado está causando un OOM, entonces ve el
código fuente de tu adaptador y chequea lo siguiente:
Lo siguiente se aplica solo a Adaptadores escritos en Código Administrados
(Managed code):
Los adaptadores obtienen un objeto de tipo IBTTransportBatch usando la API
GetBatch() sobre el objeto TransportProxy. Una vez que el adaptador es hecho
usando el objeto IBTTransportBatch el adaptador necesita hacer un
Marshal.ReleaseComObject(batch) en un loop para liberar ese objeto.
Básicamente el .net GarbageCollector no libera en tiempo real la memoria no
usada. Por lo tanto la falla al llamar ReleaseComObject() resulta en lo que parece
ser un memory leak.
Published Saturday, April 16, 2005 2:03 PM by BizTalkPerf
**Traducido el 06/06/2007. Comentarios a naldo_go1@yahoo.es.