![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
Configuración del gestor de flujo de solicitudes autónomo
Puede ajustar con precisión el gestor de flujos de solicitudes autónomo (ARFM) cambiando los valores predeterminados de la consola administrativa. Puede habilitar ARFM basado en nodos estableciendo una propiedad personalizada.
Antes de empezar
Para cambiar los valores del gestor de flujo de solicitudes autónomo, debe tener privilegios administrativos de operador, configurador o administrador. Los operadores sólo pueden ver la información en la pestaña de configuración, pero pueden cambiar los valores en la pestaña de tiempo de ejecución. El configurador puede cambiar los valores en la pestaña de configuración, pero no puede cambiar los valores en la pestaña de tiempo de ejecución. Los administradores tienen todos los privilegios.
Cuando está habilitada la seguridad, algunos campos no son editables sin la autorización de seguridad adecuada.
Acerca de esta tarea
- Un controlador por célula de destino, por ejemplo, una célula a la que una pasarela ARFM envía trabajo directamente. Se trata de un proceso HAManagedItem que se ejecuta en cualquier agente de nodo o gestor de despliegue.
- Una pasarela por combinación utilizada de familia de protocolo, proceso de proxy y destino de despliegue. Una pasarela se ejecuta en su proceso de proxy. Para HTTP y SIP (Session Initiation Protocol), los procesos de proxy son los direccionadores On Demand; para Java™ Message Service (JMS) e IIOP (Inter-ORB Protocol), los procesos de proxy son los servidores de aplicaciones WebSphere Application Server.
- Un estimador de factor de trabajo por célula de destino, que es un proceso HAManagedItem que puede ejecutarse en cualquier agente de nodo, ODR o gestor de despliegue.
La función de colocación dinámica con el planificador de trabajos no está soportada en los servidores z/OS.
Procedimiento
Cómo habilitar ARFM basado en nodos
Campo | Finalidad | Sugerencias para su definición |
---|---|---|
Periodo de adición | Cada pasarela del ARFM divulga periódicamente estadísticas globales y este parámetro especifica el periodo. Estadísticas notificadas por el soporte de pasarelas: diagramas de tiempo de ejecución en la consola administrativa, funcionamiento de los controladores del ARFM, funcionamiento del controlador de ubicación de aplicaciones y funcionamiento de los perfiles de trabajo. | Cuando establezca el periodo de adición, asegúrese de que el valor sea lo suficientemente alto como para permitir la recopilación de un número suficiente de muestras de rendimiento. Las pasarelas recopilan las muestras de cada solicitud. Para producir medidas estadísticas adecuadas se necesitan unos cuantos cientos de muestras. Por ejemplo, las solicitudes asociadas a una clase de servicio se ejecutan en 250 milisegundos y como media se ejecutan 10 solicitudes de forma simultánea. El valor de concurrencia se calcula de forma automática, basándose en el tamaño del clúster y en los recursos del entorno. El valor de concurrencia puede verse en los paneles de visualización, bajo la categoría Operaciones de tiempo de ejecución de la consola. Como resultado, la clase de servicio maneja unas 40 solicitudes por segundo. Por lo tanto, si se establece el valor del periodo de adición en 15 segundos se recopilarán 600 muestras por cada periodo de adición. Las métricas proporcionadas por un sondeo de 600 muestras son útiles y fiables. Si se establece un periodo de adición demasiado bajo las métricas de rendimiento no serán fiables. Las métricas de rendimiento derivadas de un número bajo de muestras tienen mucho más ruido y son menos fiables que las de un tamaño de muestra mayor. Como el controlador del ARFM se activa cuando se producen nuevas estadísticas, si se establece un valor del periodo de adición demasiado largo los valores de control se volverán a calcular con menor frecuencia. Por lo tanto, Intelligent Management será menos sensible a los cambios repentinos en las intensidades y los patrones del tráfico. |
Longitud mínima del ciclo de control | Este parámetro define la frecuencia con que se activa el controlador del ARFM. La activación del controlador es el proceso de evaluar las entradas y producir nuevos valores de control como resultado de la entrada recibida. El proceso de activación de un controlador del ARFM se inicia cuando se reciben nuevas estadísticas de una sus pasarelas y el tiempo transcurrido desde la activación anterior es mayor o igual que la longitud mínima del ciclo de control, o el controlador nunca se ha activado anteriormente. | Este valor determina la longitud del ciclo de control con un límite inferior. Por ejemplo, si sólo dispone de un ODR y establece el periodo de adición en 30 segundos y la longitud mínima del ciclo de control en 60 segundos, es posible que se encuentre con que a las 12:00:00.0 se produce una activación y 90,1 segundos más tarde la siguiente, a las 12:01:30.1, porque la hora de llegada de las estadísticas anteriores era a las 12:00:59.9. Para garantizar un ciclo de control fiable de unos 60 segundos, defina la longitud mínima del ciclo de control en 58 o 59 segundos. |
Ventana de suavizado | Este valor define la sensibilidad de reacción del controlador del ARFM ante las estadísticas de entrada de la pasarela, permitiendo la concatenación de estadísticas de la pasarela. En cada pasarela, su controlador del ARFM utiliza una media móvil de algunos de los últimos informes de estadísticas de esa pasarela. La ventana de suavizado controla el número de informes que se combinan. | Un valor bajo de ventana de suavizado hace que el controlador sea más sensible y reaccione más rápidamente. Sin embargo, un parámetro bajo también crea una reacción más sensible al ruido, o anomalías, en los datos. El producto de la ventana de suavizado y el periodo de adición debe ser aproximadamente el mismo que la longitud del ciclo de control real, que es a veces ligeramente superior que la longitud mínima del ciclo de control configurada. |
Longitud máxima de cola | Este parámetro se utiliza para enlazar la longitud de cada cola ARFM con un número máximo de solicitudes que se pueden mantener en la cola. ARFM divide todo el tráfico de entrada en flujos y tiene una cola diferente para cada flujo. Los flujos particulares incluyen solicitudes que tienen una clase de servicio determinada, se les proporciona servicio en un destino de despliegue determinado o pasan por un ODR determinado. Cuando llega una solicitud y la cola está llena, se rechaza la solicitud. |
Un parámetro inferior en este campo aumenta la posibilidad de que se rechace una solicitud debido a aumentos de tráfico de corta duración, mientras que un parámetro mayor en este campo puede permitir que las solicitudes permaneciesen más tiempo en las colas. Las solicitudes en cola consumen memoria. El valor predeterminado es 1000, pero puede experimentar con este valor para encontrar el valor que se adapte mejor al entorno. |
Utilización máxima de CPU | El ARFM proporciona protección contra sobrecarga, además de sus capacidades de establecer prioridades. Un ARFM pondrá en cola las solicitudes en sus pasarelas para evitar sobrecargar los servidores de aplicaciones. Para este release, la carga se determina en términos de uso de procesador en el primer nivel de servidores de aplicaciones. El parámetro de utilización máxima de CPU indica al ARFM la cantidad de carga que debe permitir en los servidores. Durante condiciones de grandes picos, este límite de uso se podría exceder por poco. |
Con los valores más altos se obtienen una utilización mejor de los recursos y los valores más bajos presentan un funcionamiento más potente. La carga real es variable y ruidosa. Las técnicas de gestión de rendimiento en Intelligent Management reaccionan ante los cambios de la carga, pero con algún tiempo de retraso. Durante el tiempo de reacción, el sistema podría funcionar fuera de su región configurada; esto incluye haber configurado un uso de procesador superior. Se ha observado que el funcionamiento con un servidor de aplicaciones cuyo uso del procesador es del 100% durante varios minutos interrumpe algunos mecanismos de las comunicaciones internas, resultando en un detrimento de muchas funciones. La gestión del rendimiento en este release de Intelligent Management no funciona correctamente, si el primer nivel de las máquinas del servidor de aplicaciones se carga con otro trabajo junto con las solicitudes de WebSphere que llegan a través de HTTP mediante los ODR. Este valor afecta a la ubicación de aplicaciones. Si la demanda total prevista supera el límite Máxima utilización de CPU, el controlador de ubicación reduce de forma uniforme la demanda de todos los clústeres dinámicos antes de calcular la mejor ubicación. Defina la propiedad personalizada arfmManageCpu en false para inhabilitar la protección de sobrecarga de procesador y el orden de prioridades de solicitud. arfmManageCpu es una propiedad personalizada de célula que debe crear. Puede determinar la utilización de la CPU haciendo lo siguiente:
|
Control de admisión para la protección contra sobrecargas de CPU | El objetivo del control de admisión para la protección contra sobrecargas de procesador es no aceptar deliberadamente diálogos basándose en juicios relacionados con cuánto puede aceptarse sin sobrecargar el sistema en los nodos que se están gestionando y comprometer el tiempo de respuesta de los mensajes aceptados. El valor Control de admisión para la protección de sobrecarga de la CPU sólo se aplica a HTTP y Session Initiation Protocol (SIP); no se aplica a IIOP y JMS. Habilítelo cuando la cola para la protección de sobrecarga de procesador no sea suficiente; cuando es importante realizar rechazos deliberados de parte de la carga ofrecida. |
Está inhabilitado de forma predeterminada. Para configurarlo:
El control de admisión para la protección contra sobrecargas de procesador está funcionando si, en un sistema con una carga elevada, la utilización del procesador es aproximadamente igual al valor de protección contra sobrecargas de procesador. |
Consulte el tema acerca de la protección de sobrecarga de memoria. | Especifica el porcentaje máximo de tamaño de almacenamiento dinámico que se debe utilizar para cada servidor de aplicaciones. |
El porcentaje máximo del tamaño de almacenamiento intermedio de WebSphere Application Server para utilizar. Establezca el valor en un valor menor que 100. |
Política de rechazo de solicitud | Especifica el comportamiento de las solicitudes HTTP, SIP y SOAP que se asocian a un objetivo de rendimiento cuando se detecta una condición de sobrecarga. |
Elija una de las opciones para determinar cuándo se deben rechazar mensajes para evitar la sobrecarga de la CPU. Puede no rechazar ningún mensaje, o especificar un valor de umbral de rechazo que determine cuándo se deben rechazar los mensajes. El valor predeterminado es no rechazar ningún mensaje. El trabajo discrecional se supone que tiene un umbral de tiempo de respuesta de 60 segundos. |
Para habilitar ARFM basado en nodos, debe establecer la propiedad personalizada arfmQueueMode en node. Para utilizar un predictor basado en CPU para APC, cuando utiliza clústeres dinámicos en modalidad automática, debe establecer la propiedad personalizada APC.predictor en CPU.
Qué hacer a continuación
Utilice los documentos mustGather para la resolución de problemas del gestor de flujo de solicitudes autónomo y la ubicación de aplicaciones.