Ajustando Tamanhos de Buffer de TCP/IP

WebSphere® Application Server usa o mecanismo de comunicação de sockets TCP/IP extensivamente. Para uma conexão de soquetes de TCP/IP, os tamanhos de buffer de envio e de recebimento definem a janela de recebimento. A janela de recebimento especifica a quantidade de dados que pode ser enviada e não recebida, antes do envio ser interrompido. Se muitos dados são enviados, eles ultrapassam o buffer e interrompem a transferência. O mecanismo que controla as interrupções da transferência de dados é mencionado como controle de fluxo. Se o tamanho da janela de recebimento para buffers de TCP/IP for muito pequeno, o buffer da janela de recebimento é ultrapassado com freqüência e o mecanismo de controle de fluxo pára a transferência de dados até que o buffer de recebimento esteja vazio.

Sobre esta Tarefa

O controle de fluxo pode consumir uma quantidade significativa de tempo de CPU e resultar em tempo de espera adicional de rede como um resultado de interrupções da transferência de dados. É recomendado aumentar os tamanhos de buffer para evitar o controle de fluxo em condições normais de operação. Um tamanho de buffer maior reduz o potencial para ocorrências de controle de fluxo e resultará na utilização de CPU aprimorada. No entanto, um tamanho de buffer grande pode ter um efeito negativo no desempenho em alguns casos. Se os buffers de TCP/IP são muitos grandes e os aplicativos não estão processando dados com a rapidez necessária, a paginação pode aumentar. O objetivo é especificar um valor suficientemente grande para evitar o controle de fluxo, mas não tão grande que o buffer acumule mais dados do que o sistema possa processar.

O tamanho de buffer padrão é 8 KB. O tamanho máximo é 8 MB (8096 KB). O tamanho de buffer mais eficiente depende de vários fatores do ambiente de rede, incluindo tipos de comutadores e sistemas, sincronização de aceitação, taxas de erro e topologia de rede, tamanho da memória e tamanho de transferência de dados. Quando o tamanho da transferência de dados for extremamente grande, você pode desejar configurar os tamanhos de buffer até o valor máximo para aprimorar o rendimento do processamento, reduzir a ocorrência de controle de fluxo e reduzir o custo de CPU.

Tamanhos de buffer para as conexões de socket entre o servidor web e o WebSphere Application Server são configurados em 64KB. Na maioria dos casos, esse valor é adequado.

O controle de fluxo pode ser um problema quando um aplicativo usa o driver IBM® Developer Kit for Java(TM) JDBC ou o driver IBM Toolbox for Java™ JDBC para acessar um banco de dados remoto. Se as transferências de dados são grandes, o controle de fluxo pode consumir uma grande quantidade de tempo de CPU. Se você usar o driver IBM Toolbox for Java JDBC , poderá usar propriedades customizadas para configurar os tamanhos de buffer para cada origem de dados. É recomendado que você especifique tamanhos de buffer grandes, por exemplo,1 MB.

Algumas configurações de sistema inteiro podem substituir o tamanho de buffer padrão de 8 KB para soquetes. Com alguns aplicativos, por exemplo, o WebSphere Commerce Suite, um tamanho de buffer de 180 KB reduz o controle de fluxo e geralmente não afeta negativamente a paginação. O valor mais favorável é dependente de características de sistema específicas. Você pode precisar tentar diversos valores antes de determinar o tamanho de buffer ideal para o seu sistema.

Para obter mais informações, consulte Configurações de rede TCP/IP em Running IBM WebSphere Application Server no System p e AIX: Otimização e Melhores Práticas . Além disso, consulte tuning de carga de trabalho de streaming TCP.

Para mais informações, consulte Linux Tuning.

Para obter informações sobre o ajuste de tamanhos de buffer TCP/IP, consulte o documento Windows 2000 e Windows Server 2003 TCP Features . É recomendável configurar o valor TcpWindowSize como 8388608 ou 16777216.

O TCP/IP pode ser a origem de alguns atrasos significativos de método remoto.

Para mudar o valor do sistema inteiro, execute as etapas a seguir:

• Tune os tamanhos de buffer TCP/IP.
  1. Mude a configuração de TCP/IP.
     1. Execute o comando Alterar Atributo TCP/IP, CHGTCPA.
     2. Visualize e altere os tamanhos de buffer pressionando F4 na janela Alterar Atributos de TCP/IP. Os tamanhos de buffer são exibidos como os tamanhos de buffer de recebimento e de envio de TCP. Digite novos valores e salve as mudanças.
  2. Recicle TCP/IP e, então, monitore as taxas de CPU e de paginação, para determinar se elas estão dentro das instruções de sistema recomendadas.
• Tune os tamanhos de buffer TCP/IP.
  1. Primeiro, certifique-se de que tenha definido soquetes suficientes para seu sistema e que o tempo limite do soquete padrão de 180 segundos não seja muito alto. Para permitir soquetes suficientes, atualize o membro BPXPRMxx parmlib:
     1. Defina MAXSOCKETS para o sistema de arquivos AF_INET com um valor alto o suficiente.
     2. Defina MAXFILEPROC com um valor alto o suficiente.

     Melhor prática: Você deve configurar MAXSOCKETS e MAXFILEPROC para pelo menos 5000 para ambientes de transação de baixo rendimento, 10000 para médio rendimento e 35000 para alto rendimento WebSphere . A definição de valores altos para esses parâmetros não deve causar uso excessivo de recursos a menos que os soquetes ou arquivos estejam realmente alocados.

     O exemplo a seguir mostra as configurações dos parâmetros MAXSOCKETS e MAXFILEPROC:

     
     /* Open/MVS Parmlib Member                                           */
     /* CHANGE HISTORY:                                                   */
     /*   01/31/02 AEK Increased MAXSOCKETS on AF_UNIX from 10000 to 50000*/
     /*                per request from My Developer                      */
     /*   10/02/01 JAB Set up shared HFS                                  */
     
     /* KERNEL RESOURCES              DEFAULT             MIN MAX         */
     /* ========================      =================== === =========== */
        .
        .
        MAXFILEPROC(65535)            /* 64               3   65535       */
     
        .
        .
         NETWORK DOMAINNAME(AF_INET) DOMAINNUMBER(2) MAXSOCKETS(30000)
        .
     

  2. Próxima confira a especificação da porta em dataset do perfil TCPIP para garantir que NODELAYACKS seja especificado da seguinte forma:

     PORT 8082 TCP NODELAYACKS

     Em suas execuções, a mudança disso aprimorará o rendimento em 50% (isso é particularmente útil ao lidar com cargas de trabalho triviais). Essa definição é importante para um bom desempenho ao executar o SSL.

  3. Você deve se assegurar de que a configuração do DNS seja otimizada para que pesquisas de servidores e clientes utilizados com freqüência estejam sendo armazenadas em cache.

     O armazenamento em cache está, às vezes, relacionado ao valor TTL (Time To Live) do servidor de nomes. De um lado, a definição do TTL para um valor alto assegurará bons números de ocorrência no cache. No entanto, a definição dele para um valor alto também significa que, se o Daemon ficar inativo, demorará um pouco para que todos na rede fiquem cientes disso.

     Uma boa maneira de verificar se a configuração do DNS está otimizada é emitir os comandos oping e onslookup do USS. Certifique-se de que eles respondam em um período de tempo razoável. Freqüentemente um nome de DNS ou um servidor DNS configurado incorretamente causará atrasos de 10 segundos ou mais.

  4. Aumente o tamanho de buffers de envio e recepção TCPIP do padrão de 16 K para, pelo menos, 64 K. Esse é o tamanho de buffers incluindo as informações de controle além do que está presente nos dados que você está enviando em seu aplicativo. Para fazer isso, especifique o seguinte:

     TCPCONFIG TCPSENDBFRSIZE 65535
               TCPRCVBUFRSIZE 65535

     Evitar problemas: Não é razoável, em alguns casos, especificar 256 KB buffers.
  5. Aumente o acúmulo de atendimento padrão.
     A lista não processada de escuta padrão é usada para aumentos de buffer em novas conexões que vêm com um protocolo como HTTP. O acúmulo de atendimento padrão é de 10 pedidos. É necessário a propriedade customizada listenBacklog de uso do canal de transporte TCP para aumentar esse valor para algo maior. Por exemplo:

     listenBacklog=100

     Nota: O valor usado para listenBacklog pode ser limitado pela especificação da instrução SOMAXCONN no perfil TCP/IP. Se você usar um valor ListenBacklog maior do que o valor SOMAXCONN, o valor ListenBacklog não deve ser utilizado; o valor para SOMAXCONN é usado.

     IMPORTANTE: Se listenBacklog não for configurado para tipos de canais HTTP, HTTP SSL, IIOP e IIOP SSL, o listenBacklog é configurado a partir dos valores de ambiente descontinuados: protocol_http_backlog, protocol_https_backlog, protocol_iiop_backlog e protocol_iiop_backlog_ssl. Se o valor do ambiente descontinuado associado não for especificado, um padrão de 10 será usado.

     Para tipos de canais que não são HTTP, HTTP SSL, IIOP e IIOP SSL, o padrão para listenBacklog é 511.

  6. Reduza o tempo finwait2.

     Na maioria dos padrões de desempenho requeridos você poderá achar que a definição de soquetes e descritores de arquivos de 65 K não fornece soquetes 'livres' o suficiente para executar em 100%. Quando um soquete é fechado de forma anormal (por exemplo, não é mais necessário) ele não fica disponível imediatamente. Em vez disso, ele é colocado em um estado chamado finwait2 (isso é o que aparece no comando netstat -s). E permanece nesse estado por um período de tempo antes de ficar disponível no conjunto livre. O padrão para isso é 600 segundos.

     Evitar problemas: A menos que você tenha problemas para usar soquetes, você deve deixar este conjunto para o valor padrão.

     Se você estiver usando o z/OS® Versão 1.2 ou mais recente, será possível controlar a quantidade de tempo que o soquete permanece no estado finwait2 , especificando o seguinte no arquivo de configuração:

     FINWAIT2TIME 60

Resultados

Repita esse processo até determinar o tamanho de buffer ideal.

O Que Fazer Depois

Os tamanhos de buffer de TCP/IP são mudados. Repita esse processo até determinar o tamanho de buffer ideal.