nf_conntrack reclamações no dmesg

Question

Enquanto investiga reclamações sobre desempenho ruim do servidor HTTP, eu descobri essas linhas no dmesg do meu host Xen XCP que contém um sistema operacional convidado com o dito servidor:

[11458852.811070] net_ratelimit: 321 callbacks suppressed
[11458852.811075] nf_conntrack: table full, dropping packet.
[11458852.819957] nf_conntrack: table full, dropping packet.
[11458852.821083] nf_conntrack: table full, dropping packet.
[11458852.822195] nf_conntrack: table full, dropping packet.
[11458852.824987] nf_conntrack: table full, dropping packet.
[11458852.825298] nf_conntrack: table full, dropping packet.
[11458852.825891] nf_conntrack: table full, dropping packet.
[11458852.826225] nf_conntrack: table full, dropping packet.
[11458852.826234] nf_conntrack: table full, dropping packet.
[11458852.826814] nf_conntrack: table full, dropping packet.

As reclamações são repetidas a cada cinco segundos (o número de retornos de chamadas suprimidos é diferente a cada vez).

O que esses sintomas podem significar? Isso é ruim? Alguma dica?

(Observe que a questão é mais restrita do que "como resolver caso específico de desempenho ruim do servidor HTTP", portanto, não forneço mais detalhes sobre isso.)

Informação adicional:

$ uname -a
Linux MYHOST 3.2.0-24-generic #37-Ubuntu SMP Wed Apr 25 08:43:22 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 12.04 LTS
Release:    12.04
Codename:   precise

$ cat /proc/sys/net/netfilter/nf_conntrack_max 
1548576

O servidor está com cerca de 10 M acessos / carga do dia.

Atualização:

iptables no Dom0:

$ iptables -L -t nat -v
Chain PREROUTING (policy ACCEPT 23155 packets, 1390K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 9 packets, 720 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 27 packets, 1780 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 23173 packets, 1392K bytes)
 pkts bytes target     prot opt in     out     source               destination

$ iptables -L -v
Chain INPUT (policy ACCEPT 13976 packets, 1015K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 241K packets, 24M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 13946 packets, 1119K bytes)
 pkts bytes target     prot opt in     out     source               destination

iptables em um dos DomUs:

$ iptables -L -t nat -v
Chain PREROUTING (policy ACCEPT 53465 packets, 2825K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 53466 packets, 2825K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 51527 packets, 3091K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 51527 packets, 3091K bytes)
 pkts bytes target     prot opt in     out     source               destination

$ iptables -L -v
Chain INPUT (policy ACCEPT 539K packets, 108M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 459K packets, 116M bytes)
 pkts bytes target     prot opt in     out     source               destination

    

Answer 1

Eu estava um pouco curioso sobre este e encontrei uma boa explicação para seus sintomas. Eles são bem descritos em nf_conntrack: tabela cheia - como a ausência de regras pode levar a um comportamento inesperado .

TL; DR: Apenas a execução de iptables -t nat -vnL começa a carregar o módulo nf_conntrack , resultando em um firewall intencional não intencional. Ainda não o confirmei, você pode apostar que vou fazer isso amanhã mesmo no trabalho.

Solução: Se você não precisa do NAT porque está fazendo pontes de qualquer maneira, descarregue os módulos nf_conntrack_* e todos os outros módulos dependentes que dependem deles. Desabilitar o firewall por meio de chkconfig ip[6]tables off seria uma boa ideia também.

Desativar o firewall no Ubuntu pode ser feito por sudo ufw disable e seguindo estas instruções se você não quiser reiniciar.

    

Answer 2

O Xen deve estar conectado NAT ao seu servidor domU e o grande número de conexões está sobrecarregando a capacidade do kernel de rastreá-las. Embora você possa aumentar o espaço alocado para rastrear as conexões aumentando nf_conntrack_max , provavelmente seria melhor ter conexão em rede
a> em vez de NAT. Dessa forma, o servidor domU obtém sua própria placa Ethernet virtual, evitando o problema completamente.