Excessivamente alto uso de memória relatado (3 GB) após a reinicialização

Question

Descrição breve do problema: Um Gentoo de 64 bits no Intel Core-2 Q6600 reporta cerca de 3 GB usados a partir de 8 GB de memória total após a reinicialização. Esta memória não é reivindicada por nenhum processo, nem é usada por buffers / cache.

Contexto: Eu observei esse comportamento pela primeira vez depois que o OOM eliminou o processo emerge ao tentar criar oitava a partir do código-fonte. Quando o sistema tornou-se responsivo novamente, ainda restavam cerca de 3 GB de memória usada que não era usada por nenhum processo. (Por favor, note que eu não posso dizer com certeza que isso foi realmente no começo - talvez eu simplesmente não tenha percebido antes.)

Eu tentei reiniciar, já que não estou familiarizado com os possíveis problemas do OOM, mas a memória foi supostamente usada novamente.

Então eu tentei Memcheck86 +, que relatou um erro "endereço com falha" em 3246.3MB (teste repetido 5x). Baixei a frequência da RAM e o erro desapareceu (teste repetido 3x).

No entanto, no meu Gentoo, 3GB é persistentemente relatado como usado sem explicação aparente (consulte os relatórios de diagnóstico abaixo).

Eu também tentei uma distro ao vivo (Parted Magic), que aparentemente se comporta normalmente (cerca de várias centenas de memória usada após a inicialização).

Alguma sugestão sobre a possível causa ou mesmo solução?

Editar: Agora sou capaz de superar o problema, mas ainda não consegui explicar. Eu descrevo o que eu tenho acompanhado até agora:

• Os 3 GB de memória não são usados quando iniciados em um modo de usuário único.

• A partir de iptables resulta na utilização de 3 GB, enquanto o dmesg reporta:

  nf_conntrack: voltando ao vmalloc

• paragens subsequentes iptables não reverte o processo, a memória continua a ser utilizada.

Depois mudei a configuração do meu kernel para que o nf_conntrack não seja mais interno, mas sim como módulo. Após a reinicialização, iptables começa sem a mensagem falling back to vmalloc e também sem consumir os 3GB.

Eu não tenho ideia de como isso pode ser explicado. Talvez algum desenvolvedor do kernel possa ajudar a explicar o que exatamente poderia ter causado esse comportamento?

Relatórios relevantes:

    

Answer 1

Esse problema pode ser causado por um dimensionamento incorreto do tamanho máximo da tabela de controle de conexão e da tabela de hash. O kernel do Linux tenta alocar páginas contíguas para rastrear as tabelas de conexão para o módulo nf_conntrack do iptables. Como você não tem memória física suficiente, o conntrack falha de volta para o vmalloc.

Esta tabela não é criada dinamicamente com base em conexões estabelecidas, mas sim totalmente alocada com base em alguns parâmetros do kernel.

Alguns sintomas adicionais podem estar encontrando um grande número de mensagens nf_conntrack: voltando para o vmalloc. em / var / log / messages (ou /var/log/kern.log, ou em ambos ).

Isso é facilmente solucionável apenas ajustando a tabela de controle de conexões e dimensionando-a. O dimensionamento adequado deve ser feito com base no uso do sistema. A tabela de rastreamento de conexão precisa ser alta se você estiver executando um firewall de rede dedicado neste sistema, mas pode ser muito menor se você estiver usando apenas o iptables para protegê-lo de intrusões de rede.

Para mais informações sobre o ajuste do acompanhamento de conexões, consulte o link

Para ajustar os valores do seu sistema, você pode avaliar primeiro o número de conexões que seu sistema mantém aberto executando conntrack -L (ou %código%). Melhor ainda, mantenha uma estatística das conexões rastreadas ao longo do tempo ( munin faz isso muito bem) e use o número máximo de conexões rastreadas como uma linha de base. Com base nessas informações, você pode configurar o /etc/sysctl.conf de acordo.

Quando fizer um ajuste fino, verifique também quanto tempo você mantém as conexões na tabela de rastreamento. Às vezes, as tabelas conntrack contêm conexões de dados espúrias devido a erros de configuração ou de configuração da rede. Por exemplo, quando o servidor recebe conexões SYN que nunca são fechadas ou quando o cliente se desconecta abruptamente e deixa os soquetes abertos por um longo tempo.

Em segundo lugar, verifique se as entradas do conntrack fazem sentido. Às vezes, as tabelas do conntrack estão cheias de lixo por causa de alguma configuração incorreta da rede ou do firewall. Geralmente, essas são entradas para conexões que nunca foram totalmente estabelecidas. Isso pode acontecer, e. quando o servidor recebe pacotes SYN de conexão de entrada, mas as respostas do servidor são sempre perdidas em algum lugar da rede.

Ao ajustar esses valores em execução, use /sbin/sysctl net.netfilter.nf_conntrack_count para fornecer algumas dicas. Os valores padrão são bastante conservadores: 600 (10 minutos) para tempos limite genéricos e 432000 (5 dias) para uma conexão TCP estabelecida. Dependendo da finalidade do sistema e do comportamento da rede, esses podem precisar de ajuste fino para reduzir o número de conexões ativas na tabela conntrack. O que ajudará a definir um valor menor para ele.

Certifique-se, no entanto, de não dimensionar muito a tabela conntrack, pois você pode ter o efeito oposto: conexões sendo descartadas pelo iptables porque elas não podem ser rastreadas e você começará a ter mensagens como essa em seus arquivos de log : 'kernel: ip_conntrack: tabela cheia, perdendo o pacote.'

Para confirmar se esse é o problema, forneça a saída do seguinte:

cat /proc/sys/net/ipv4/ip_conntrack_max
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_buckets