Muitas conexões TCP causam desconexões

Question

Eu tenho um servidor de jogo que é executado com conexões TCP. O servidor desconecta os usuários aleatoriamente. Eu acho que isso está relacionado com as configurações TCP do servidor.

No código de ambiente de desenvolvimento local, o código escrito pode manipular 8000 usuários simultâneos sem qualquer desconexão ou erro (no host local).

Mas no servidor Centos 5 64bit real implementado, servidor criando estas desconexões independentes da quantidade de conexão tcp simultânea.

O servidor parece não conseguir processar a taxa de transferência.

netstat -s -t
IcmpMsg:
    InType0: 31
    InType3: 87717
    InType4: 699
    InType5: 2
    InType8: 1023781
    InType11: 7211
    OutType0: 1023781
    OutType3: 603
Tcp:
    8612766 active connections openings
    14255236 passive connection openings
    12174 failed connection attempts
    319225 connection resets received
    723 connections established
    6351090913 segments received
    6180297746 segments send out
    45791634 segments retransmited
    0 bad segments received.
    1664280 resets sent
TcpExt:
    46244 invalid SYN cookies received
    3745 resets received for embryonic SYN_RECV sockets
    327 ICMP packets dropped because they were out-of-window
    1 ICMP packets dropped because socket was locked
    11475281 TCP sockets finished time wait in fast timer
    140 time wait sockets recycled by time stamp
    1569 packets rejects in established connections because of timestamp
    103783714 delayed acks sent
    6929 delayed acks further delayed because of locked socket
    Quick ack mode was activated 6210096 times
    1806 times the listen queue of a socket overflowed
    1806 SYNs to LISTEN sockets ignored
    1080380601 packets directly queued to recvmsg prequeue.
    31441059 packets directly received from backlog
    5272599307 packets directly received from prequeue
    324498008 packets header predicted
    1143146 packets header predicted and directly queued to user
    3217838883 acknowledgments not containing data received
    1027969883 predicted acknowledgments
    395 times recovered from packet loss due to fast retransmit
    257420 times recovered from packet loss due to SACK data
    5843 bad SACKs received
    Detected reordering 29 times using FACK
    Detected reordering 12 times using SACK
    Detected reordering 1 times using reno fast retransmit
    Detected reordering 809 times using time stamp
    1602 congestion windows fully recovered
    1917 congestion windows partially recovered using Hoe heuristic
    TCPDSACKUndo: 8196226
    7850525 congestion windows recovered after partial ack
    139681 TCP data loss events
    TCPLostRetransmit: 26
    10139 timeouts after reno fast retransmit
    2802678 timeouts after SACK recovery
    86212 timeouts in loss state
    273698 fast retransmits
    19494 forward retransmits
    2637236 retransmits in slow start
    33381883 other TCP timeouts
    TCPRenoRecoveryFail: 92
    19488 sack retransmits failed
    7 times receiver scheduled too late for direct processing
    6354641 DSACKs sent for old packets
    333 DSACKs sent for out of order packets
    20615579 DSACKs received
    2724 DSACKs for out of order packets received
    123034 connections reset due to unexpected data
    91876 connections reset due to early user close
    169244 connections aborted due to timeout
    28736 times unabled to send RST due to no memory
IpExt:
    InMcastPkts: 2

O que me faz pensar é que isso parece ser muito problemático.

123034 connections reset due to unexpected data
91876 connections reset due to early user close
28736 times unabled to send RST due to no memory

Como posso corrigir esses erros? Preciso fazer o ajuste de TCP?

edit: algumas informações do sysctl:

sysctl -A | grep net | grep mem
net.ipv4.udp_wmem_min = 4096
net.ipv4.udp_rmem_min = 4096
net.ipv4.udp_mem = 772704       1030272 1545408
net.ipv4.tcp_rmem = 4096        87380   4194304
net.ipv4.tcp_wmem = 4096        16384   4194304
net.ipv4.tcp_mem = 196608       262144  393216
net.ipv4.igmp_max_memberships = 20
net.core.optmem_max = 20480
net.core.rmem_default = 129024
net.core.wmem_default = 129024
net.core.rmem_max = 131071
net.core.wmem_max = 131071

editar: informações sobre ethtool para 2 placas ethernet detectadas:

Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Link detected: yes

Settings for eth1:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised auto-negotiation: Yes
        Speed: Unknown!
        Duplex: Half
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Link detected: no

    

Answer 1

Você aumenta o limite de FD? Você pode obter algumas informações aqui link

    

Answer 2

Por "O servidor desconecta os usuários aleatoriamente" se você quisesse que os clientes se desconectassem sem a comunicação FIN, ACK, RST esperada, resolveria a interface half-duplex primeiro, especialmente se seu ambiente de desenvolvimento tiver as duas NICs em full-duplex. A interface eth1 sendo em Half Duplex enquanto em Auto-negociação = on é geralmente causada por:

1. A negociação automática entre o comutador e o servidor falhou.
2. O switch com a negociação automática desativada, definindo explicitamente a velocidade & duplex para a porta.

Eu vejo isso com mais freqüência na situação # 2, mas provavelmente é porque já faz mais de uma década desde que eu conscientemente encontrei uma falha de negociação automática para examinar. O comportamento de negociação automática de Ethernet quando um lado é automático e o outro é codificado (ou não responde) é para o lado automático cair para o modo Half Duplex.

Em termos simples, o fato de o Eth1 estar no half duplex faz com que o servidor envie ou receba dados somente através da interface, em vez de enviar e receber. O lado codificado permaneça no modo Full Duplex e tentará enviar dados ao servidor enquanto recebe dados do servidor. No entanto, o servidor considerará isso uma colisão, uma vez que pressupõe um domínio de colisão, em que o full duplex elimina os domínios de colisão. O servidor usará um algoritmo de backoff para agendar uma retransmissão. O servidor continuará aumentando o tempo de espera para retransmitir os dados, se continuar a experimentar o que pensa ser uma colisão.

Portanto, ter um parceiro half duplex com full duplex pode causar facilmente desconexões de clientes, problemas de rendimento ou desempenho, picos de latência e vários outros problemas.