Correção “Chain de hash da rota muito longa” sem reiniciar

5

No cache de roteamento do nosso servidor de produção (Ubuntu 12.04, 3.2.0-63 kernel) atingiu sua capacidade. Modificar rhash_entries está fora de questão, já que é um parâmetro de inicialização do kernel e não podemos reiniciar o servidor.

Quais são nossas opções?

A máquina tem 8GB se for RAM (eu sei, muito pouco, mas é uma antiga ...).

A saída de grep . /proc/sys/net/ipv4/route/* é assim:

/proc/sys/net/ipv4/route/error_burst:1250
/proc/sys/net/ipv4/route/error_cost:250
/proc/sys/net/ipv4/route/gc_elasticity:1
/proc/sys/net/ipv4/route/gc_interval:60
/proc/sys/net/ipv4/route/gc_min_interval:0
/proc/sys/net/ipv4/route/gc_min_interval_ms:0
/proc/sys/net/ipv4/route/gc_thresh:262144
/proc/sys/net/ipv4/route/gc_timeout:300
/proc/sys/net/ipv4/route/max_size:4194304
/proc/sys/net/ipv4/route/min_adv_mss:256
/proc/sys/net/ipv4/route/min_pmtu:552
/proc/sys/net/ipv4/route/mtu_expires:600
/proc/sys/net/ipv4/route/redirect_load:5
/proc/sys/net/ipv4/route/redirect_number:9
/proc/sys/net/ipv4/route/redirect_silence:5120
    
por er453r 18.08.2014 / 13:29

1 resposta

1

Depois de muita pesquisa e lendo este ótimo artigo , descobri soluções: diminuindo net.ipv4.route.gc_timeout para que as entradas do cache sejam removidas mais rapidamente e diminuindo net.ipv4.route.gc_interval para que o coletor de lixo seja executado com mais frequência.

Mas tudo isso é temporário, já que em nossa máquina ele só resolveu o problema por algumas horas e uma coleta de lixo mais intensa exigia muito da CPU. Cuidado com a modificação desses valores - eles podem matar sua máquina.

Aumentar rhash_entries parece ser o único caminho.

    
por 21.08.2014 / 11:59