Rendimiento biztalk

136 visualizaciones

Publicado el

0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
136
En SlideShare
0
De insertados
0
Número de insertados
2
Acciones
Compartido
0
Descargas
3
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Rendimiento biztalk

  1. 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. 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. 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. 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. 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. 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. 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.

×