Alta redefinição de TCP e contagem de descartes de pacotes no CentOS Linux

2

Eu tenho um pequeno farm de servidores web (HP Proliant e IBM x, com placas de rede Broadcom Corporation NetXtreme II BCM5) rodando o Apache 2.2.15 no CentOS 6, atrás de um balanceador de carga Cisco ACE, servindo um portal web baseado em PHP / JS . Este farm recebe muitas solicitações diárias (ele atende um pequeno país inteiro) tentando acessar uma página inicial (para ir, de lá, para a página de índice)

Eu tenho lutado com o seguinte problema:

  • Eu notei que às vezes os pedidos para a web atrasam um tempo "longo" para serem respondidos (do ponto de vista do cliente) e às vezes nem sequer são respondidos (tempo limite no lado do web client). Neste último, eu nem vi o pedido nos logs do Apache.

  • Também notei que o netstat reporta uma quantidade crescente de redefinições TCP sendo enviadas ( netstat -st | grep 'resets sent' )

  • Além disso, dropwatch -l kas mostra que muitos pacotes estão sendo descartados:

Initalizing kallsyms db dropwatch> start Enabling monitoring... Kernel monitoring activated. Issue Ctrl-C to stop monitoring 53 drops at tcp_v4_md5_hash_skb+248 (0xffffffff8149fa08) 26 drops at tcp_rcv_established+926 (0xffffffff814981b6) 3 drops at tcp_v4_reqsk_destructor+fa (0xffffffff814a104a) 1 drops at netlink_unicast+251 (0xffffffff81471b11) 56 drops at tcp_v4_md5_hash_skb+248 (0xffffffff8149fa08) 29 drops at tcp_rcv_established+926 (0xffffffff814981b6) 4 drops at tcp_v4_reqsk_destructor+fa (0xffffffff814a104a) 51 drops at tcp_v4_md5_hash_skb+248 (0xffffffff8149fa08) 32 drops at tcp_rcv_established+926 (0xffffffff814981b6) 2 drops at tcp_v4_reqsk_destructor+fa (0xffffffff814a104a) 1 drops at ip_rcv_finish+199 (0xffffffff8147ea49) 1 drops at tcp_v4_destroy_sock+115 (0xffffffff814a0cf5) 1 drops at tcp_v4_reqsk_destructor+fa (0xffffffff814a104a) 22 drops at tcp_rcv_established+926 (0xffffffff814981b6) 36 drops at tcp_v4_md5_hash_skb+248 (0xffffffff8149fa08) 2 drops at tcp_v4_reqsk_destructor+fa (0xffffffff814a104a) 49 drops at tcp_v4_md5_hash_skb+248 (0xffffffff8149fa08) 29 drops at tcp_rcv_established+926 (0xffffffff814981b6) 26 drops at tcp_rcv_established+926 (0xffffffff814981b6)

Tenho seguido as recomendações da RH ( Afinação de desempenho de rede do Red Hat Enterprise Linux Guia ), embora eu não tenha visto alguns dos sintomas descritos em meus servidores. Resumindo:

  • Eu aumentei os buffers de anel do NIC para o máximo.
  • Eu tratei (aumentei ou alterei) vários parâmetros do kernel (tcp_syncookies, netdev_budget, tcp_timestamps, tcp_window_scaling, tcp_rmem, dev_weight, tcp_tw_reuse ...)
  • Eu modifiquei a configuração do Apache de acordo com vários "Apache guias de otimização "extraídos da web (mesmo que houvesse, e ainda são, funcionários ociosos nas estatísticas do Apache)
  • Eu parei / desativei qualquer serviço do sistema / daemon não necessário (basicamente tudo o que resta é sshd, httpd e snmpd)

Todos os itens acima sem sorte.

Todas as placas de rede com velocidade de trabalho de 1000Mb / s, uso de CPU e disco são baixas e nem netstat nem ethtool mostram erros.

Alguma idéia do que mais pode ser feito?

    
por Dõùĝ Díäz 22.10.2016 / 06:35

1 resposta

3

Uma redefinição de TCP é um fechamento imediato de uma conexão TCP. Isso permite que os recursos alocados para a conexão anterior sejam liberados e disponibilizados para o sistema.

causas da geração de RST

Confirmação, Reset

  1. enviado em resposta a um Syn. Uma Confirmação de confirmação enviada em resposta a um quadro Syn é enviada para confirmar o recebimento do quadro, mas depois para permitir que o cliente saiba que o servidor não pode permitir a conexão nessa porta. Entre as razões para o Ack, Reset são:

    a. O nó que está sendo conectado não está escutando na porta na qual o nó cliente está tentando se conectar.

    b. Existe algum motivo para o nó do servidor não conseguir concluir a conexão nessa porta. Por exemplo, o servidor está sem recursos e, portanto, não pode alocar os recursos necessários para permitir a conexão.

RST

  1. Se a conexão estiver em um estado não sincronizado (LISTEN, SYN-SENT, SYN-RECEIVED) e o segmento de entrada confirmar algo ainda não enviado (o segmento transporta um ACK inaceitável), uma redefinição é enviada .

  2. A próxima reinicialização é uma redefinição de TCP que ocorre quando um quadro de rede é enviado seis vezes (esse seria o quadro original mais cinco retransmissões do quadro) sem uma resposta. Como resultado, o nó de envio redefine a conexão.

Como você e tentou usar vários parâmetros de ajuste kernal, tente usar a opção de cookies tcp do kernel

Ativar proteção de cookie TCP SYN

Edit the file /etc/sysctl.conf, run:
# vi /etc/sysctl.conf

Append the following entry:

net.ipv4.tcp_syncookies = 1

Save and close the file. To reload the change, type:
# sysctl -p 
A solução

pode ser dada apenas pela análise de seus logs, o IPtables também pode ajudar

    
por 22.10.2016 / 07:56