analisa o desempenho do TCP ao interpretar “netstat -s”

Question

Eu executei netstat -s no meu servidor dedicado executando o debian. Eu gostaria de interpretar os resultados porque estou tendo problemas de conectividade com o TCP. Não sei ler esses resultados. Alguém pode ajudar por favor?

O contexto: É um servidor tcp público, com clientes de todo o mundo, a maioria deles usa redes 3G / UMTS. Os soquetes são abertos por 1 hora em média. Alguns links tcp param por 10 a 60 segundos, a cada 10 minutos. Estou executando um programa java personalizado que é o servidor tcp.

Aqui está a saída de netstat -s . Isso mostra algum problema óbvio de conectividade?

    Ip:
        33780786 total packets received
        0 forwarded
        0 incoming packets discarded
        33780059 incoming packets delivered
        33577363 requests sent out
        1 outgoing packets dropped
        1442 reassemblies required
        715 packets reassembled ok
    Icmp:
        4675 ICMP messages received
        98 input ICMP message failed.
        ICMP input histogram:
            destination unreachable: 2901
            timeout in transit: 152
            echo requests: 1334
            echo replies: 226
        2109 ICMP messages sent
        0 ICMP messages failed
        ICMP output histogram:
            destination unreachable: 550
            echo request: 225
            echo replies: 1334
    IcmpMsg:
            InType0: 226
            InType3: 2901
            InType8: 1334
            InType11: 152
            OutType0: 1334
            OutType3: 550
            OutType8: 225
    Tcp:
        8752 active connections openings
        287296 passive connection openings
        58164 failed connection attempts
        74065 connection resets received
        30 connections established
        32997886 segments received
        32357425 segments send out
        438184 segments retransmited
        587 bad segments received.
        75868 resets sent
    Udp:
        777245 packets received
        550 packets to unknown port received.
        0 packet receive errors
        779944 packets sent
    TcpExt:
        28674 invalid SYN cookies received
        56570 resets received for embryonic SYN_RECV sockets
        998 packets pruned from receive queue because of socket buffer overrun
        9 ICMP packets dropped because they were out-of-window
        27402 packets rejects in established connections because of timestamp
        1266543 delayed acks sent
        1399 delayed acks further delayed because of locked socket
        Quick ack mode was activated 143367 times
        1556 times the listen queue of a socket overflowed
        1556 SYNs to LISTEN sockets dropped
        25884635 packets directly queued to recvmsg prequeue.
        785180902 bytes directly in process context from backlog
        1800599695 bytes directly received in process context from prequeue
        2879633 packet headers predicted
        7627605 packets header predicted and directly queued to user
        3218508 acknowledgments not containing data payload received
        14774120 predicted acknowledgments
        52 times recovered from packet loss due to fast retransmit
        24519 times recovered from packet loss by selective acknowledgements
        4 bad SACK blocks received
        Detected reordering 146 times using FACK
        Detected reordering 77 times using SACK
        Detected reordering 2239 times using time stamp
        3548 congestion windows fully recovered without slow start
        15840 congestion windows partially recovered using Hoe heuristic
        8832 congestion windows recovered without slow start by DSACK
        127403 congestion windows recovered without slow start after partial ack
        12080 TCP data loss events
        TCPLostRetransmit: 3
        179 timeouts after reno fast retransmit
        21328 timeouts after SACK recovery
        1481 timeouts in loss state
        32373 fast retransmits
        5349 forward retransmits
        26402 retransmits in slow start
        230593 other TCP timeouts
        4 classic Reno fast retransmits failed
        2367 SACK retransmits failed
        563 times receiver scheduled too late for direct processing
        243774 packets collapsed in receive queue due to low socket buffer
        151068 DSACKs sent for old packets
        45306 DSACKs sent for out of order packets
        238987 DSACKs received
        14 DSACKs for out of order packets received
        27627 connections reset due to unexpected data
        4045 connections reset due to early user close
        4992 connections aborted due to timeout
    IpExt:

    

Answer 1

1 outgoing packets dropped

Quase não há perda de pacotes, o que é bom, mas não temos dados de latência. De relance, eu diria que você está usando as ferramentas erradas para o trabalho.

Existe um banco de dados envolvido? Há algum tipo de função cíclica que reduza a velocidade do sistema em torno da marca de 10 minutos? A máquina só opera este servidor tcp ou está servindo outros recursos?

O Netstat não é uma métrica adequada para o que você deseja fazer. Para ter certeza de que o seu aplicativo da web está funcionando conforme o esperado, você precisa de uma infraestrutura com os seguintes recursos

• Ganchos em seu aplicativo para garantir métricas adequadas. Você é o desenvolvedor, então você pode fazer isso e facilitar o seu trabalho massivamente. Por ganchos quero dizer facilidades para buscar dados de diagnóstico e desempenho, codificados diretamente em seu aplicativo.
• Uma infraestrutura de gráficos / monitoramento. Cactos e Nagios são um exemplo que eu conheço com, mas há mais.
• Um plano. O que você quer alcançar? Qual o nível de serviço que você deseja fornecer aos seus usuários? Implemente diagnósticos e métricas de desempenho à medida que você desenvolve seu aplicativo e, se perceber que isso pode se transformar em algo grande, torne-o escalável. * Realmente * escalável.

Answer 2

Algumas coisas para tentar ajudar você a entender o problema:

• Como o seu programa de recepção lida com conexões da rede? É multithreaded? Como ele lida com os clientes? Existe um tempo limite sendo atingido?
• Como você testou o código do servidor? Você o executou em sua máquina local e experimentou quantas conexões pode obter? Você já testou o efeito de sessões longas?
• Tente executar "netstat -p" ou "lsof -i TCP" e veja o que está acontecendo. Como é a fila de envio? Execute um "ps auxwww", qual é o estado do programa do servidor?