Contexto:
Recentemente fui encarregado de encontrar a raiz e / ou corrigir um vazamento de memória com uma instalação ISC DHCPD (4.2.5-P1) em um servidor Unix Debian (Lenny).
Eu venho pesquisando o problema há mais de uma semana e recuperei muitas informações sobre o fato de que o sistema está realmente vazando, mas eu não encontrei uma resposta real a respeito de porque é ou como pará-lo .
Eu tenho atualmente:
CFLAGS=-DDEBUG_MEMORY_LEAKAGE_ON_EXIT (parece parar vazamentos de memória) dhcpd -6 -d -cf /etc/dhcpd6.conf
Script:
#!/bin/bash
#probably could have used watch
while [[ 0 -eq 0 ]]; do
ps -eo vsz,rss,command | grep "dhcpd6.conf" | grep -v grep >> memory-usage.txt
sleep 600
done
Eu fiz um pouco de pesquisa sobre VSZ e RSS. Se o tamanho do RSS permanecer o mesmo, mas o tamanho do VSZ aumentar, parece que há um vazamento de memória nítido. No entanto, na minha situação, o VSZ e o RSS estão aumentando. [Tamanho inicial dia 1: VZS = 8560 RSS = 6292 = > Tamanho final 3: VZS = 67168 RSS = 64860]
Também olhei para /proc/PID/maps para ver se conseguia alguma informação, mas não consegui encontrar nada de útil.
/ proc / PID / mapeia informações:
08048000-081e3000 r-xp 00000000 08:05 119382 /usr/sbin/dhcpd
081e3000-081e8000 rw-p 0019b000 08:05 119382 /usr/sbin/dhcpd
081e8000-08222000 rw-p 081e8000 00:00 0
09fea000-0a11c000 rw-p 09fea000 00:00 0 [heap]
b72b7000-b72c1000 r-xp 00000000 08:01 6184 /lib/i686/cmov/libnss_files-2.7.so
b72c1000-b72c3000 rw-p 00009000 08:01 6184 /lib/i686/cmov/libnss_files-2.7.so
b72c3000-b7673000 rw-p b72c3000 00:00 0
b7673000-b77c8000 r-xp 00000000 08:01 6192 /lib/i686/cmov/libc-2.7.so
b77c8000-b77c9000 r--p 00155000 08:01 6192 /lib/i686/cmov/libc-2.7.so
b77c9000-b77cb000 rw-p 00156000 08:01 6192 /lib/i686/cmov/libc-2.7.so
b77cb000-b77ce000 rw-p b77cb000 00:00 0
b77cf000-b77d0000 rw-p b77cf000 00:00 0
b77d1000-b77d4000 rw-p b77d1000 00:00 0
b77d4000-b77d5000 r-xp b77d4000 00:00 0 [vdso]
b77d5000-b77ef000 r-xp 00000000 08:01 2022 /lib/ld-2.7.so
b77ef000-b77f1000 rw-p 0001a000 08:01 2022 /lib/ld-2.7.so
bfe0d000-bfe30000 rw-p bffdc000 00:00 0 [stack]
Pergunta (s):
1. Como devo proceder para depurar um vazamento de memória como este?
2. A ISC diz que a solução está reiniciando o servidor de tempos em tempos e que isso não é um bug. Se meu cliente não quiser redefinir seu servidor, existe algum meio termo? (Eles querem provas concretas de que precisam seguir com uma solução).
3. Alguém já teve experiência com um vazamento relacionado ao dhcpd desde janeiro de 2013?
4. Existe uma solução ou solução alternativa disponível para este problema?
Link (s) relacionado (s):
1. link (Relatório do ISC)
2. link (Este relatório de bug corresponde ao ponto inicial do meu vazamento de memória [OMAPI FUNCTIONALITY])
Se você precisar de informações adicionais que possam ajudar a resolver esse problema, estou pronto para fornecer o que posso.
Nesse meio tempo, vou ver se consigo compilar o binário e desativar a funcionalidade OMAPI.
O DHCP 4.3.0a1 acabou de ser lançado, então vou ver se isso muda alguma coisa (não havia informações no log de alterações sobre uma correção de vazamento de bug, mas não faz mal tentar).
Obrigado pelo seu tempo.
Como solução alternativa, considere executar o dhcpd com limites de memória em um supervisor de processos, como runit .
Espero que o dhcpd seja abortado se falhar na alocação de memória, quando o supervisor de processo irá reiniciá-lo.
Ou você pode apenas reiniciá-lo periodicamente no cron - ainda é menos invasivo do que reinicializar todo o servidor.
Tags networking debug unix dhcp-server