![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
Configurando o Autonomic Request Flow Manager
É possível fazer ajustes finos no ARFM (Autonomic Request Flow Manager) alterando as configurações padrão no console administrativo. É possível ativar ARFM baseado em nó, configurando uma propriedade customizada.
Antes de Iniciar
Para alterar as configurações no Autonomic Request Flow Manager, você deverá ter os privilégios administrativos de operador, configurador ou administrador. Os operadores podem apenas visualizar as informações na guia de configuração, mas podem alterar as configurações na guia de tempo de execução. O configurador pode alterar as configurações na guia de configuração, mas não pode alterar as configurações na guia de tempo de execução. Os administradores têm todos os privilégios.
Quando a segurança estiver ativada, alguns campos não podem ser editados sem autorização de segurança apropriada.
Sobre Esta Tarefa
- Uma célula do controlador por destino, como uma célula para a qual um gateway ARFM envia trabalho diretamente. Esse é um processo HAManagedItem executado em qualquer agente do nó ou gerenciador de implementação.
- Um gateway por combinação de família de protocolos, de processo proxy e de destino de implementação utilizada. Um gateway é executado em seu processo proxy. Para HTTP e SIP (Session Initiation Protocol), os processos proxy são os ODRs (On Demand Routers); para Sistema de Mensagens Java (JMS - Java™ Message Service) e Internet Inter-ORB Protocol (IIOP), os processos proxy são os servidores de aplicativos do WebSphere Application Server.
- Um estimador de fator de trabalho por célula de destino, que seja um processo HAManagedItem que possa executar em qualquer agente do nó, ODR ou gerenciador de implementação.
A
função de posicionamento dinâmico com planejador de tarefas não é suportada em
servidores z/OS.
Procedimento
Como ativar o ARFM baseado em nó
Campo | Propósito | Dicas para configuração |
---|---|---|
Período de Agregação | Cada gateway ARFM difunde estatísticas agregadas periodicamente e esse parâmetro especifica o período. As estatísticas reportadas pelo suporte de gateways: a representação gráfica do tempo de execução no console administrativo, a operação dos controladores ARFM, a operação do controlador de posicionamento de aplicativos e a operação de criadores de perfil de trabalho. | Ao configurar o período de agregação, assegure que o valor seja alto o suficiente para permitir a coleta de um número suficiente de amostras de desempenho. As amostras são coletadas pelos gateways para cada pedido. Algumas centenas de amostras são necessárias para produzir uma boa medida estatística. Utilizando um exemplo - os pedidos associados a uma classe de serviço são executados em 250 milissegundos e em média 10 pedidos são executados simultaneamente. O valor da simultaneidade é calculado automaticamente, baseado no tamanho do cluster e nos recursos do ambiente. O valor de simultaneidade pode ser visto nos painéis de visualização, na categoria Operações de Tempo de Execução no console. Como resultado, a classe de serviço manipula quase 40 pedidos por segundo. Assim, a definição do valor do período de agregação como 15 segundos resulta na coleta de 600 amostras para cada período de agregação. As métricas fornecidas por uma pesquisa de amostra de 600 são úteis e confiáveis. Definir um valor de período de agregação muito baixo resulta em métricas de desempenho não confiáveis. As métricas de desempenho derivadas de poucas amostras têm mais interferências e são menos confiáveis do que um tamanho de amostra maior. Como o controlador do ARFM é ativado quando novas estatísticas são produzidas, definir um valor de período de agregação muito longo resulta em um recálculo menos freqüente das configurações de controle. Portanto, o Intelligent Management se torna menos responsivo a mudanças repentinas nas intensidades e padrões do tráfego. |
Duração Mínima do Ciclo de Controle | Esse parâmetro define com que frequência o controlador do ARFM é ativado. A ativação do controlador é o processo de avaliar entradas e produzir novas configurações de controle da entrada recebida. O processo de ativação de um controlador de ARFM é iniciado quando novas estatísticas são recebidas de um de seus gateways e o tempo decorrido desde a última ativação é maior ou igual à duração mínima do ciclo de controle ou o controlador nunca foi ativado antes. | Essa definição determina a duração do ciclo de controle, fornecendo-lhe uma ligação mais baixa. Por exemplo, se você tiver somente um ODR e definir o período de agregação para 30 segundos e a duração mínima do ciclo de controle para 60 segundos, é possível descobrir que uma ativação ocorrerá às 12:00:00,0 e a próxima ocorrerá 90,1 segundos depois, às 12:01:30,1, pois a hora de chegada da estatística anterior era 12:00:59,9. Para assegurar um ciclo de controle confiável de cerca de 60 segundos, configure o comprimento mínimo do ciclo de controle para 58 ou 59 segundos. |
Janela de Suavização | Essa configuração define a sensibilidade da reação do controlador do ARFM em relação às estatísticas que chegam do gateway, permitindo uma concatenação das estatísticas do gateway. Para qualquer gateway, o controlador do ARFM utiliza uma média de execução dos últimos relatórios de estatísticas desse gateway. A janela de suavização controla o número de relatórios que são combinados. | Uma definição de janela de suavização baixa torna o controlador mais sensível e permite uma reação mais rápida. Entretanto, um parâmetro baixo também cria uma reação de sensibilidade a interferência, ou anomalias, nos dados. O produto da janela de suavização e o período de agregação devem ser praticamente iguais à duração real do ciclo de controle, que, às vezes, pode ser ligeiramente maior que a duração mínima configurada do ciclo de controle. |
Comprimento Máximo da Fila | Este parâmetro é usado para limitar o comprimento de cada fila ARFM para uma quantidade máxima de pedidos que podem ser mantidos na fila. O ARFM divide todo o tráfego que chega em fluxos e tem uma fila separada para cada fluxo. As características do fluxo incluem pedidos que tenham uma determinada classe de serviço, são atendidos em um determinado destino de implementação ou passam por um determinado ODR. Quando um pedido chega e sua fila está cheia, o pedido é rejeitado. |
Um parâmetro inferior neste campo aumenta a possibilidade de que um pedido será rejeitado devido aos bursts de tráfego de curta duração, enquanto um parâmetro superior neste campo pode permitir que os pedidos permaneçam por mais tempo nas filas. Pedidos enfileirados consomem memória. A definição padrão é 1000, mas é possível experimentar com esta configuração para descobrir aquela que seja mais adequada ao seu ambiente. |
Uso Máximo da CPU | O ARFM fornece proteção contra sobrecarga, além de seus recursos de priorização. Um ARFM colocará pedidos em fila em seus gateways para evitar sobrecarregar os servidores de aplicativos. Para este release, a carga é determinada em termos de utilização do processador na primeira camada de servidores de aplicativos. O parâmetro de utilização máxima de CPU indica ao ARFM até que ponto carregar os servidores. Durante as condições severas de pico, este limite de utilização por ser brevemente excedido. |
Valores mais altos fornecem melhor utilização de recursos; valores mais baixos fornecem uma operação mais robusta. A carga real é variável e contém interferência. As técnicas de gerenciamento de desempenho no Intelligent Management reagem às mudanças no carregamento, mas com algum atraso. Durante esse tempo de reação, o sistema pode operar fora de sua região configurada; isto inclui ter uma utilização mais alta do processador do que o configurado. A operação com um servidor de aplicativos com 100 por cento de utilização do processador por vários minutos demonstrou interromper alguns mecanismos de comunicação interna, em detrimento de muitos recursos. O gerenciamento do desempenho neste release do Intelligent Management não funciona bem se a primeira camada de máquinas de servidores de aplicativos estiverem carregadas com outro trabalho além dos pedidos do WebSphere que chegam através de HTTP pelos ODRs. Essa configuração afeta a posição dos aplicativos. Se a demanda prevista total suceder o limite de Utilização máxima da CPU, o controlador de posicionamento reduzirá uniformemente a demanda de todos os clusters dinâmicos antes de calcular o melhor posicionamento. Configure a propriedade customizada arfmManageCpu como false para desativar a proteção de sobrecarga do processador e a priorização de pedidos. A arfmManageCpu é uma propriedade customizada da célula que você precisa criar. É possível
determinar a utilização da CPU executando o seguinte:
|
Controle de admissão da proteção contra sobrecarga da CPU | O propósito do controle de admissão para a proteção de sobrecarga do processador é deliberadamente não aceitar diálogos baseados nos julgamentos preocupados com o quanto pode ser aceito sem sobrecarga da capacidade computacional nos sós que estão sendo gerenciados e comprometer o tempo de resposta das mensagens aceitas. O valor de Controle de admissão para proteção de sobrecarga da CPU aplica-se somente ao HTTP e SIP (Session Initiation Protocol); ele não se aplica ao IIOP e JMS. Ative-o quando o enfileiramento para a proteção de sobrecarga do processador não for suficiente; quando for importante realizar recusas deliberadas de algumas cargas oferecidas. |
Desativado, por padrão. Para configurar:
O controle de admissão para a proteção de sobrecarga do processador está funcionando se, em um sistema muito carregado, a utilização do processador é quase a mesma que a definição para proteção de sobrecarga do processador. |
Leia sobre proteção de sobrecarga de memória | Especifica a porcentagem máxima do tamanho de heap a ser utilizada para cada servidor de aplicativos. |
Porcentagem máxima do tamanho de heap do WebSphere Application Server a ser utilizada. Configure o valor como menor que 100. |
Política de Rejeição do Pedido | Especifica o comportamento para solicitações HTTP, SIP e SOAP associado com um objetivo de desempenho quando uma condição de sobrecarga é detectada. |
Escolha entre as opções para determinar quando rejeitar mensagens para evitar que a CPU seja sobrecarregada. É possível não rejeitar mensagens ou especificar um valor do limite de rejeição que determine quando elas devem ser rejeitadas. O padrão é não rejeitar mensagens. Considera-se que o trabalho opcional tenha um limite de tempo de resposta de 60 segundos. |
Para ativar o ARFM baseado em nó, você deve configurar a propriedade customizada arfmQueueMode como node. Para usar um predito baseado emCPU para o APC quando você estiver usando clusters dinâmicos no modo automático, deve-se configurar a propriedade APC.predictor para CPU .
O que Fazer Depois
Use os documentos mustGather para solucionar problemas de gerenciador autônomo de fluxo de solicitações e posicionamento de aplicativo.