BIND 9.10 morto constantemente no FreeBSD 10.0 sem espaço de troca

Question

Em um de nossos servidores DNS escravos, o BIND, versão bind910-9.10.0P2_3, é constantemente morto com a seguinte mensagem em /var/log/messages :

Jul 30 01:00:10 cinnabar kernel: pid 602 (named), uid 53, was killed: out of swap space

Este serviço é executado em uma VM FreeBSD 10.0 no XenServer 6.2, possui 512 MB de memória do sistema.

Neste momento, pstat -m -s retorna isso:

Device          1M-blocks     Used    Avail Capacity
/dev/ada0p3           512        9      502     2%

Eu não acho que seja um problema de troca, parece ser um vazamento de memória, mas não tenho certeza.

EDIT: Acesse a informação.

Este é um dos dois servidores DNS escravos, eles apenas armazenam as zonas do servidor autoritativo e agem como um servidor recursivo para os usuários internos do mundo externo. O número de clientes é algo entre 700-1500 usuários simultâneos. Como temos um espaço interno / 21 e / 23 de espaço IPv4 público e não há consultas do mundo externo, a porta 53 está até bloqueada no firewall dessas máquinas.

    

Answer 1

Se você tiver algum tipo de monitoramento neste servidor, seria bom verificar se há algum pico no uso da memória ao longo do tempo em que os processos são mortos. Então você poderia tentar encontrar uma correlação com o número de solicitações, etc.

Dito isso, pode significar que não há memória no sistema, mas Bind está solicitando uma área contígua de memória, a fragmentação está atrapalhando e o FreeBSD está tentando trocar alguns processos para liberar espaço. por isso. Provavelmente não pode trocar muitas páginas, falhar em alocar e disparar o killer de memória.

Se você tiver espaço em disco, a solução mais fácil é adicionar mais troca por meio de um arquivo de troca (não é necessário para uma partição). Idealmente, você deve limitar o tamanho do cache (o Bind assume como padrão ilimitado ), como sugerido por Håkan, mas isso pode ter um impacto no desempenho. Sem mais estatísticas é realmente difícil dizer. Mesmo roteadores domésticos têm 512MB de RAM hoje em dia, então você deve aumentar (e limitar o cache) para um servidor de produção que atende 700-1500 usuários simultâneos (o que poderia traduzir em muito mais req / s novamente, sem mais informações é difícil dizer ).

Você também pode tentar alterar a implementação do malloc por meio do botão MALLOC_PRODUCTION , mas acho que isso é muito radical em face da facilidade soluções disponíveis.