Servidor Ubuntu: latência estranha pula na lan

3

Substituímos o firewall antigo por este servidor , executando o Ubuntu 16.04.

Ele (quase) não é nada além de executar o iptables com cerca de 900 regras (filter & nat combinado).

O servidor antigo que ele substituiu funcionou bem e não houve problemas.

De vez em quando (pode ser uma vez por hora ou a cada 30 segundos), a latência entre o novo firewall e qualquer outro host na LAN aumenta de 0.1-0.2ms para 10, 40, 100 e até 3.000ms para um alguns segundos (às vezes até dura minutos). Eu notei isso com um atraso simples em uma conexão ssh para um host na DMZ (não deve haver nenhum atraso) e, em seguida, testei com testes de ping simples, contínuos e de alta taxa (-i 0.1) para vários hosts.

Eu testei isso na interface de 10gbps e em uma das interfaces de 1gbps. O servidor não está nem perto dos limites de rede (~ 10Kpps, 100-400mbps up & down combinados). A CPU está inativa em 99%

Em uma das "interrupções" mais longas que eu conectei ao firewall da internet para depurá-lo, notei que não há problemas com qualquer outra interface e todas estão bem, sem problemas de latência.

Para remover o switch da equação, movi a interface de 1 gbps para um switch diferente, fora de nossa pilha e adicionei outro servidor ao novo switch para testar. O problema ainda persiste, eu corro um ping constante para várias máquinas e todos eles vão até 2-3 segundos de vez em quando, incluindo o da chave "imediata".

dmesg não mostra nada, ifconfig não mostra nenhum erro, / proc / interrupts mostra que todos os núcleos participam no manuseio do nic (s) (embora eu tenha certeza que para um throughput tão baixo até um núcleo seria suficiente ...)

Qualquer sugestão ou ideia de como depurar esse cenário seria apreciada.

Obrigado!

EDIT: Adicionando a saída do ethtool:

Configurações para eno1:

Supported ports: [ TP ]
Supported link modes:   10baseT/Half 10baseT/Full
                        100baseT/Half 100baseT/Full
                        1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Advertised link modes:  10baseT/Half 10baseT/Full
                        100baseT/Half 100baseT/Full
                        1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: on (auto)
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
               drv probe link
Link detected: yes

EDIT 2: Talvez seja irrelevante, mas eu vi isso em uma das interrupções (realmente longas):

%Cpu(s):  0.1 us,  3.3 sy,  0.0 ni, 95.7 id,  0.0 wa,  0.0 hi,  1.0 si,  0.0 st
KiB Mem : 16326972 total, 14633008 free,   296636 used,  1397328 buff/cache
KiB Swap:        0 total,        0 free,        0 used. 15540780 avail Mem

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
29163 root      20   0       0      0      0 S   8.0  0.0  14:08.45 kworker/4:0
31722 root      20   0       0      0      0 S   7.3  0.0   9:39.76 kworker/6:0
11677 root      20   0       0      0      0 S   5.6  0.0   0:04.65 kworker/3:1
149 root      20   0       0      0      0 S   4.0  0.0  27:21.36 kworker/2:1
46 root      20   0       0      0      0 S   0.3  0.0   0:06.93 ksoftirqd/6

Uso excessivamente alto de CPU do kworker (normalmente é cerca de 1%). Alguma idéia?

    
por GibsonLP 13.01.2017 / 10:57

1 resposta

1

Eu tive uma situação semelhante e esse link nos ajudou a resolver nossa questões!

Essencialmente, você provavelmente precisará configurar o tamanho do buffer máximo do socket TCP para entre 2-4mb, talvez ainda menor se não afetar o seu serviço, já que você está tendo muitos picos grandes.

Para comparar os problemas:

  • Grande quantidade de tráfego saudável com picos de lentidão aparentemente aleatórios que podem durar por um longo período de tempo.
  • Você confirmou que o problema está no seu novo firewall.
  • Todos os seus dados do teste informam que não há problemas.
  • É um atraso muito ocasional, aparentemente aleatório, entre o pacote sendo recebido pelo SO e processado.

Espero que isso seja útil!

    
por 13.01.2017 / 13:56