Compartir a través de

Cuellos de botella en el nivel de BizTalk Server

  • Artículo

El nivel de BizTalk se puede dividir en las siguientes áreas funcionales:

  • Recepción

  • Procesamiento

  • Transmisión

  • Seguimiento

  • Otros

    Para estas áreas, si los recursos del sistema (CPU, memoria y disco) parecen estar saturados, actualice el servidor mediante el escalado vertical o horizontal de la plataforma en función de las características de la aplicación. Si los recursos del sistema no están saturados, siga los pasos descritos en esta sección.

Cuellos de botella en la ubicación de recepción

Si los mensajes se acumulan en la ubicación de recepción (por ejemplo, la carpeta de recepción de archivos crece grande), esto indica que el sistema no puede absorber los datos lo suficientemente rápido como para mantenerse al día con la carga entrante. Esto se debe a la limitación interna. Es decir, BizTalk Server reduce la tasa de recepción si los suscriptores no pueden procesar los datos lo suficientemente rápido como para provocar la compilación del trabajo pendiente en las tablas de base de datos. Si el cuello de botella se debe a limitaciones de hardware, intente escalar verticalmente. Para obtener más información sobre el escalado vertical, consulte los temas siguientes en la documentación de BizTalk Server 2010:

Procesamiento de cuellos de botella

Si el contador de rendimiento Cola de host: longitud está subiendo, indica que las orquestaciones no se completan lo suficientemente rápido. Para obtener más información, vea la tabla de contadores de Perfmon en este tema. Esto se puede deber a la contención de memoria o a la saturación de CPU.

Si los servidores de orquestación son los causantes del cuello de botella, use Perfmon para identificar el origen.

Si el servidor está enlazado a la CPU, tenga en cuenta lo siguiente:

  • Si el flujo de trabajo es complejo, considere la posibilidad de dividir la orquestación en varias orquestaciones más pequeñas.

    Nota:

    Dividir una orquestación en varios flujos de trabajo puede producir una latencia adicional y agregar complejidad. Varios flujos de trabajo también pueden provocar un aumento en el número de mensajes publicados y consumidos desde BizTalkMsgBoxDb, lo que supone una presión adicional en la base de datos.

  • Si usa mapas complejos, tenga en cuenta si se pueden mover a los puertos de recepción o envío. Asegúrese de comprobar qué puertos tienen ancho de banda adicional.

  • Considere la posibilidad de escalar verticalmente el hardware o el escalado horizontal mediante la configuración de un servidor de procesamiento adicional.

Transmisión de cuellos de botella

Si el servidor que hospeda los adaptadores de envío está saturado de recursos (por ejemplo, disco, memoria o CPU), considere la posibilidad de escalar verticalmente el servidor o escalar horizontalmente a servidores host de envío adicionales. El nivel de envío se podría convertir en el cuello de botella si el destino (externo a BizTalk) no puede recibir los datos a la velocidad suficiente. Esto provocará una acumulación de mensajes en la base de datos de cuadro de mensajes (SendHostQ de aplicación).

Si todos los puntos de conexión están dentro del ámbito de la topología, aísle la causa en el destino. Por ejemplo, determine si la ubicación HTTP está configurada de forma óptima para recibir la carga. Si no es así, considere la posibilidad de escalar horizontalmente. Determine también si el destino crece debido a mensajes de salida excesivos entregados por BizTalk. Si es así, es posible que necesite un plan de mantenimiento para archivar y purgar los mensajes de destino. Un gran número de archivos en una carpeta de destino puede afectar gravemente a la capacidad del servicio biztalk para confirmar los datos en la unidad de disco.

Seguimiento de cuellos de botella

La instancia de host de seguimiento es responsable de mover los datos de supervisión de actividad empresarial (BAM) y seguimiento de actividad (HAT) de la base de datos messagebox (tabla TrackingData) a las tablas de base de datos de importación principal de BizTalk o seguimiento de actividad de BAM. Si se configuran varias bases de datos de cuadro de mensajes, la instancia de host de seguimiento usa cuatro subprocesos por base de datos de cuadro de mensajes.

Es posible que la instancia de host de seguimiento esté enlazada a la CPU. Si es así, considere la posibilidad de escalar verticalmente el servidor o el escalado horizontal mediante la configuración de un servidor adicional con el seguimiento de host habilitado. Las instancias de host múltiples equilibrarán automáticamente la carga de las varias bases de datos de Cuadro de mensajes configuradas. Para obtener más información sobre el escalado, consulte el tema Escalado de las soluciones (https://go.microsoft.com/fwlink/?LinkId=158078).

Si la tabla TrackingData de la base de datos messagebox crece de gran tamaño, suele deberse a que los trabajos de mantenimiento de datos de la base de datos de importación principal de BizTalk o seguimiento de BizTalk no se ejecutan según lo configurado, lo que provoca el crecimiento de las bases de datos de importación principal de BizTalk o de Seguimiento de BizTalk. Después de que estas bases de datos crezcan demasiado grandes, puede tener un impacto negativo en la capacidad del host de seguimiento para insertar datos en la tabla TrackingData. Esto hace que se realice un seguimiento de los datos de los que se realiza una copia de seguridad en las tablas de base de datos de Cuadro de mensajes. El crecimiento de la tabla TrackingData hace que se inicie la limitación.

Solo debe habilitar el seguimiento mínimo necesario para la aplicación, ya que esto reducirá la cantidad de datos registrados y reducirá el riesgo de realizar el seguimiento de cuellos de botella. Para obtener información sobre cómo deshabilitar la configuración de seguimiento para elementos individuales, como orquestaciones y puertos de envío y recepción, vea Cómo deshabilitar el seguimiento (https://go.microsoft.com/fwlink/?LinkId=160064).

Otros

Configure la topología de implementación en la que las distintas funcionalidades se ejecuten en instancias de host aisladas dedicadas. De este modo, cada instancia de host obtiene su propio conjunto de recursos (por ejemplo, en un sistema de 32 bits, espacio de direcciones de memoria virtual de 2 GB, identificadores, subprocesos). Si el servidor tiene suficiente espacio de cpu y memoria para hospedar varias instancias de host, se pueden configurar para que se ejecuten en el mismo equipo físico. Si no es así, considere la posibilidad de escalar horizontalmente moviendo la funcionalidad a servidores dedicados. Ejecutar la misma funcionalidad en varios servidores también sirve para proporcionar una configuración de gran disponibilidad.

Contadores de rendimiento del sistema de BizTalk

Object Instancia Contador Finalidad de la supervisión
Procesador _Total % de tiempo de procesador Contención de recursos
Proceso BTSNTSvc Bytes virtuales Pérdida o inundación de memoria
Proceso BTSNTSvc Bytes privados Pérdida o inundación de memoria
Proceso BTSNTSvc Recuento de identificadores Contención de recursos
Proceso BTSNTSvc Número de subprocesos Contención de recursos
Disco físico _Ejemplo % de tiempo de inactividad Contención de recursos
Disco físico _Ejemplo Average Disk Queue Length Contención de recursos

Contención de CPU

Si el procesador está saturado, puede fragmentar la aplicación separando la recepción del envío y la orquestación. Para ello, cree hosts independientes, asigne los hosts a una funcionalidad específica (recepción, envío, orquestaciones y seguimiento) y agregue servidores dedicados a estos hosts independientes. La funcionalidad de orquestación suele consumir mucha CPU. Si configura el sistema para que las orquestaciones se ejecuten en un servidor dedicado independiente, esto puede ayudar a mejorar el rendimiento general del sistema.

Si se implementan varias orquestaciones, puede inscribirlas en diferentes hosts de orquestación dedicados. La asignación de servidores físicos diferentes a los hosts de orquestación dedicados garantiza que las distintas orquestaciones están aisladas y no compiten por los recursos compartidos, ya sea en el mismo espacio de direcciones físicos o en el mismo servidor.

Detenga las instancias de host sin usar. Las instancias de host sin usar pueden competir por los recursos de CPU y memoria comprobando periódicamente el cuadro de mensajes para que los mensajes se procesen. Además, detenga las ubicaciones de recepción sin usar, los puertos de envío y las orquestaciones.

Crecimiento de la tabla de cola

Los cuellos de botella de bajada o la contención de recursos pueden hacer que la cola empiece a crecer excesivamente y reducir el rendimiento general. Para obtener más información, vea "Crecimiento de la tabla de colas" en Cómo identificar cuellos de botella en la base de datos de cuadro de mensajes1.

Hambre de memoria

Los escenarios de gran rendimiento pueden suponer una mayor demanda de la memoria del sistema. Dado que un proceso de 32 bits está limitado por la cantidad de memoria que puede consumir, se recomienda separar la funcionalidad de recepción, proceso y envío en instancias de host independientes de modo que cada host reciba su propio espacio de direcciones de 2 GB. Además, si varias instancias de host se ejecutan en el mismo servidor físico, puede actualizar a 4/8 GB de memoria para evitar el intercambio de datos al disco de la memoria real. Las orquestaciones de larga duración pueden mantenerse en la memoria asignada más tiempo. Esto puede hacer que se inicie el sobredimensionamiento y la limitación de la memoria. Los mensajes grandes también pueden provocar un consumo elevado de memoria.

Puede facilitar el problema de sobredimensionamiento de memoria que se produce cuando se procesan mensajes grandes reduciendo el tamaño de cola de mensajes internos y los mensajes en proceso por valores de CPU para el host específico.

Nota:

Si la latencia es un problema, los cambios en el tamaño de la cola de mensajes internos y los mensajes en proceso por CPU se deben tener precaución, ya que esto puede aumentar la latencia de un extremo a otro del sistema.

Contención de disco

Si los discos están saturados (por ejemplo, con un gran número de transportes FILE/MSMQ), considere la posibilidad de actualizar a varios ejes y seccionar los discos con RAID 10. Además, siempre que use el transporte de ARCHIVOS, es importante asegurarse de que las carpetas de recepción y envío no crezcan más de 50 000 archivos.

La carpeta de recepción puede crecer de gran tamaño si BizTalk Server limita los datos entrantes en el sistema. Es importante mover datos de la carpeta de envío para que el crecimiento de esta carpeta no afecte a la capacidad de BizTalk Server escribir datos adicionales. En el caso de las colas de MSMQ no transaccionales, se recomienda crear de forma remota las colas de recepción para que la contención de disco se reduzca en la BizTalk Server.

La configuración remota de cola no transaccional también proporciona alta disponibilidad, ya que el servidor remoto que hospeda la cola se puede agrupar en clúster.

Otra contención de recursos del sistema

Según el tipo de transporte, puede ser necesario configurar recursos del sistema como IIS para HTTP (por ejemplo, MaxIOThreads, MaxWorkerThreads).

Con ASP.NET 2.0 y ASP.Net 4, el <valor processModel autoConfig="true"> del archivo machine.config configurará automáticamente las siguientes opciones para obtener un rendimiento óptimo:

  • Máximo de subprocesos de trabajo

  • Máximo de subprocesos de E/S

  • atributo minFreeThreads del elemento httpRuntime

  • atributo minLocalRequestFreeThreads del elemento httpRuntime

  • Atributo maxConnection del <elemento connectionManagement> Element (Network Settings)

    Para obtener más información sobre la configuración de parámetros que afectan al rendimiento del adaptador, vea ASP.NET Opciones de configuración para el elemento processModel (https://go.microsoft.com/fwlink/?LinkId=158080).

    Para obtener más información sobre las opciones de configuración que pueden afectar a los adaptadores de BizTalk Server, vea Parámetros de configuración que afectan al rendimiento del adaptador (https://go.microsoft.com/fwlink/?LinkID=154200).

    Además de optimizar las aplicaciones de BizTalk Server, otras aplicaciones de ASP.NET que se ejecutan en el mismo servidor pueden afectar al rendimiento general. Es importante optimizar todas las aplicaciones de ASP.NET para reducir la demanda de recursos del sistema. Para obtener más información, vea rendimiento de ASP.NET (https://go.microsoft.com/fwlink/?LinkId=158081).

    Al configurar para obtener el máximo rendimiento, considere la posibilidad de optimizar otros sistemas externos, como motores de mensajería (Message Queuing, MQSeries), aplicaciones, bases de datos, Active Directory, etc. que forman parte de la solución general de BizTalk. Los cuellos de botella de rendimiento en cualquiera de estos otros sistemas externos pueden tener un efecto negativo en la solución de BizTalk.

Cuellos de botella de bajada

Si el sistema de bajada no puede recibir datos lo suficientemente rápido de BizTalk, estos datos de salida se realizarán en las bases de datos de BizTalk. Esto da como resultado un sobredimensionamiento, hace que se inicie la limitación, se reduce la canalización de recepción y afecta al rendimiento general del sistema de BizTalk. Una indicación directa de esto es el crecimiento de la tabla de colas. Para obtener más información sobre los cuellos de botella y la tabla Spool, vea How to Identify Bottlenecks in the MessageBox Database1.How to Identify Bottlenecks in the MessageBox Database1.

Impacto de la limitación

La limitación comenzará finalmente a proteger el sistema de alcanzar un estado irrecuperable. Por lo tanto, puede usar la limitación para comprobar si el sistema funciona normalmente y detectar el origen del problema. Después de identificar la causa del cuello de botella del estado de limitación, analice los otros contadores de rendimiento para determinar el origen del problema. Por ejemplo, la contención alta en la base de datos MessageBox podría deberse a un uso elevado de la CPU, causado por la paginación excesiva en el disco causado por condiciones de memoria baja. La contención alta en la base de datos MessageBox también podría deberse a una contención de bloqueo alta debido a unidades de disco saturadas. Aunque la limitación ocasional no es una amenaza significativa para el rendimiento, la limitación persistente puede indicar un problema subyacente más significativo. Para obtener más información sobre esas condiciones en las que BizTalk Server usará la limitación, consulte How BizTalk Server Implements Host Throttling (https://go.microsoft.com/fwlink/?LinkID=155286).

Para obtener más información sobre cómo BizTalk Server limitación puede ayudar a administrar el uso de recursos disponibles y minimizar la contención de recursos, consulte Optimización del uso de recursos a través de la limitación de host (https://go.microsoft.com/fwlink/?LinkID=155770).

Contadores de aplicaciones de BizTalk

Object Instancia Contador Descripción
Mensajería de BizTalk RxHost Documentos recibidos/seg. Tasa de entrada
Mensajería de BizTalk TxHost Documentos procesados/seg. Tasa de salida
Orquestaciones XLANG/s PxHost Orquestaciones completadas/seg. Tasa de procesamiento
BizTalk : Cuadro de mensaje: Contadores generales MsgBoxName Tamaño de cola de impresión Tamaño acumulado de todas las colas de host
BizTalk : Cuadro de mensaje: Contadores generales MsgBoxName Tamaño de los datos de seguimiento Tamaño de la tabla TrackingData en el cuadro de mensajes
BizTalk:MessageBox:Host Counters PxHost:MsgBoxName Cola de host - Longitud Número de mensajes en la cola de host específica
BizTalk:MessageBox:Host Counters TxHost:MsgBoxName Cola de host - Longitud Número de mensajes en la cola de host específica
BizTalk:Agente de mensaje RxHost Tamaño de base de datos Tamaño de la cola de publicación (PxHost)
BizTalk:Agente de mensaje PxHost Tamaño de base de datos Tamaño de la cola de publicación (TxHost)
BizTalk:Agente de mensaje HostName Estado de limitación de entrega de mensajes Afecta a los transportes XLANG y de salida
BizTalk:Agente de mensaje HostName Estado de limitación de publicación de mensajes Afecta a los transportes XLANG y de entrada

¿Por dónde empiezo?

Supervisar el estado de limitación de entrega de mensajes y el estado de limitación de publicación de mensajes para cada instancia de host es un buen punto de partida. Si el valor de estos contadores no es cero, esto indica la limitación en el sistema de BizTalk y puede analizar aún más la causa del cuello de botella. Para obtener descripciones de los otros contadores de rendimiento, consulte Cuellos de botella en el nivel de base de datos.

Contadores de rendimiento del motor de orquestación

Se recomienda encarecidamente ajustar la configuración del entorno de ejecución de orquestación, ya que los puntos de rehidratación y persistencia de orquestación continua pueden tener un impacto grave en el rendimiento general. Debe usar los siguientes contadores al probar orquestaciones complejas que pueden contener varios puntos de persistencia y ámbitos transaccionales.

Contador Comentarios
Orquestaciones deshidratadas/seg. Número promedio deshidratado por segundo.
Orquestaciones rehidratadas/seg. Número promedio rehidratado por segundo.
Puntos de persistencia/seg. Número promedio de instancias de orquestación guardadas por segundo.
Orquestaciones residentes en memoria Número de instancias de orquestación alojadas actualmente por la instancia de host.
Orquestaciones completadas por segundo Número promedio completado por segundo.
Orquestaciones suspendidas/seg. Número promedio suspendido por segundo.
Ámbitos transaccionales asignados/seg. Número promedio asignado por segundo.
Ámbitos transaccionales anulados/seg. Número promedio anulado por segundo.
Ámbitos transaccionales compensados/seg. Número promedio compensado por segundo.

Compilación del trabajo pendiente

Para un escenario de implementación de 1 a 1, donde 1 mensaje recibido da como resultado 1 mensaje procesado y transmitido, si la tasa de salida no es igual a la tasa de entrada, hay un trabajo pendiente en el sistema. En esta situación, puede supervisar el tamaño de la cola. Al determinar la causa de cuellos de botella en la tasa de salida, ejecute un único escenario de caso de uso a la vez. Aísle orquestaciones, ubicaciones de recepción y ubicaciones de envío a hosts independientes.

Agregue los contadores de BizTalk:Message Box:Host al registro de Monitor de rendimiento para supervisar un host. El contador Cola de host: longitud: realiza un seguimiento del número total de mensajes en una cola de host determinada. Si uno o varios de estos contadores continúan creciendo con el tiempo, preste especial atención a los artefactos ejecutados por esos hosts.

Si el grupo de servidores está creciendo linealmente, determine qué cola de aplicaciones es responsable del crecimiento del grupo de servidores.

Si ninguna de las colas de aplicaciones crece y el grupo de servidores sigue creciendo, podría significar que los trabajos de purga no pueden mantenerse al día. Esto ocurre si el agente no se está ejecutando o hay otra contención de recursos del sistema en el SQL Server.

Si una de las colas de aplicaciones está creciendo, diagnostique la causa de este crecimiento. Supervise los recursos del sistema en el sistema que no pueden purgar la cola de aplicaciones específica (por ejemplo, El host de orquestación-Q está creciendo debido al colapso de la CPU en el servidor). Además, compruebe los valores del contador de limitación para la instancia de host específica.

Si el estado de limitación de entrega de mensajes del agente de mensajes de BizTalk:Message y los contadores de rendimiento del estado de publicación de mensajes no son cero, compruebe el valor para confirmar el motivo de la limitación (por ejemplo, umbral de memoria superado, recuento de mensajes en curso demasiado alto, etc.).

Stand-Alone Profiler

Puede usar contadores de rendimiento para detectar la ubicación del cuello de botella en un nivel alto. Sin embargo, una vez reducido, es posible que tenga que examinar el código más detenidamente para ayudar a aliviar el problema. El generador de perfiles de Stand-Alone que se incluye con Visual Studio 2010 puede ser una herramienta muy útil para ayudar a diagnosticar dónde el código está gastando la mayor parte de sus ciclos. Para obtener más información, vea

Caché L2/L3

Desde una perspectiva de hardware, puede obtener las mayores ventajas mediante la caché de CPU incorporada. Una caché de CPU superior ayuda a aumentar la tasa de aciertos de caché, lo que reduce la necesidad de que el sistema pagine los datos desde la memoria y hacia al disco.

Cuellos de botella de rendimiento de 64 bits

El rendimiento en los sistemas de 64 bits puede parecer inferior del que se puede obtener en los sistemas de 32 bits. Esto es posible por algunas razones, la más importante es la memoria.

Medir el rendimiento en un sistema de 32 bits con 2 GB de memoria y comparar los resultados con un sistema similar de 64 bits con 2 GB de memoria no está comparando lo mismo. El sistema de 64 bits parecerá estar enlazado a E/S de disco (bajo % de tiempo de inactividad del disco & longitud alta de la cola de disco) y enlazado a la CPU (cpu máxima y cambio de contexto alto). Sin embargo, esto no se debe a que realizar la E/S de archivos en un sistema de 64 bits es más caro.

El sistema de 64 bits consume más memoria (direccionamiento de 64 bits), lo que da como resultado que el sistema operativo consuma la mayor parte de la memoria disponible de 2 GB. Cuando esto sucede, la mayoría de las demás operaciones provocan la paginación en el disco, lo que hace hincapié en el subsistema de archivos. Por lo tanto, el sistema gasta ciclos de CPU paginando dentro y fuera de la memoria tanto los datos como el código y se ve afectado por el alto costo de latencia de disco. Esto se manifiesta en forma de una mayor contención de disco y consumo de CPU.

La manera de solucionar este problema es escalar verticalmente el servidor mediante la actualización de la memoria. El escalado vertical hasta 8 GB es idea, sin embargo, agregar más memoria no ayudará a mejorar el rendimiento a menos que el origen del problema sea el colapso de la CPU debido a condiciones de memoria bajas.

Uso de BAM para identificar cuellos de botella y problemas de alta latencia

Cuando la latencia baja es importante, puede usar BAM para medir el tiempo que tarda el sistema en completar cada fase del sistema BizTalk Server. Aunque puede usar HAT para depurar el estado de los mensajes y diagnosticar el origen de problemas de enrutamiento de mensajes, puede usar BAM para realizar un seguimiento de varios puntos a través del flujo de mensajes. Al crear un perfil de seguimiento de BAM que define una actividad con continuaciones, puede medir la latencia entre diferentes partes del sistema para ayudar a realizar un seguimiento de las fases más caras dentro del proceso de flujo de trabajo.

Puede usar el depurador de orquestación en HAT para consultar una instancia suspendida, reanudar la instancia en modo de depuración y agregar puntos de interrupción adecuados mediante la vista Detalles técnicos. De este modo, es posible realizar el seguimiento de actividades y depurar mensajes paso a paso.

Se pueden establecer puntos de interrupción para realizar el seguimiento de los eventos siguientes:

  • El inicio y la finalización de una orquestación.

  • El inicio y la finalización de una forma

  • El envío o la recepción de un mensaje

  • Excepciones

    En cada punto de interrupción, se puede examinar la información sobre variables locales, mensajes y sus propiedades, puertos y vínculos de función.

Consulte también

Búsqueda y eliminación de cuellos de botella