Como posso melhorar a taxa de acertos do cache do nscd?

3

Minha meta: Deixe o nscd manter um cache DNS bastante grande em excesso de memória desde que eu o tenha disponível.

Descrição:

Eu tenho um servidor da Web que tem uma base de usuários amplamente dispersa, mas de alta repetição. Ele tem muita memória, então eu pensei em melhorar o tempo de resposta armazenando em cache as pesquisas, mas de acordo com nscd -g , estou com uma taxa de acerto de cache de 6% (significando que nscd está provavelmente introduzindo mais latência no cache ou olhando pelo cache para uma entrada que nunca encontrará, do que impedindo indo para a rede):

hosts cache:

            yes  cache is enabled
            yes  cache is persistent
            yes  cache is shared
            211  suggested size
         216064  total data pool size
           2328  used data pool size
          36000  seconds time to live for positive entries
             20  seconds time to live for negative entries
           4455  cache hits on positive entries
              0  cache hits on negative entries
          17357  cache misses on positive entries
          42348  cache misses on negative entries
              6% cache hit rate
             17  current number of cached values
             40  maximum number of cached values
              3  maximum chain length searched
              0  number of delays on rdlock
              0  number of delays on wrlock
              0  memory allocations failed
            yes  check /etc/hosts for changes

Provavelmente, um grande contribuidor para a taxa de acerto de 6% é o fato de que, aparentemente, só há 17 entradas em cache. Fazendo um strings /var/db/nscd/hosts mostra que as entradas de cache do host que ele criou são principalmente para máquinas em nossa rede interna. É bom tê-los em cache, pois a publicação diária do site provavelmente está acelerada, mas meu objetivo é acelerar a experiência do usuário final sem fazer nenhuma alteração real na configuração.

Este é o segmento relevante de nscd.conf :

    threads                 10
    server-user             nscd
    debug-level             0
    paranoia                no
    [.....snip......]
    enable-cache            hosts           yes
    positive-time-to-live   hosts           36000
    negative-time-to-live   hosts           20
    suggested-size          hosts           10657
    check-files             hosts           yes
    persistent              hosts           yes
    shared                  hosts           yes
    max-db-size             hosts           33554432
Basicamente, eu preciso de ajuda para entender como meu cache de host pode ser tão pequeno, mesmo que eu tenha definido os TTLs positivos no cache do host como incrivelmente altos. Tenho certeza de que é o pequeno número de entradas em cache reais que está causando uma baixa taxa de acertos.

Suponho que a taxa de acerto seja 6%, mas meu TTL positivo é bastante grande, o que significa que minha carga de trabalho atual está realizando pesquisas de host DNS, mas eles não estão salvando. Não tenho ideia de por que isso não está sendo salvo nem o que verificar em seguida. O que eu esperava seria um cache DNS bastante grande agora.

Mesmo que a taxa de acertos permanecesse pequena (ou seja, os clientes não estivessem repetindo com tanta frequência quanto eu pensava), ainda esperaria que as essas pesquisas de DNS fossem armazenadas em cache, mas observando o "número atual de valores em cache "que também não parecem estar acontecendo.

    
por Bratchley 24.10.2013 / 18:20

4 respostas

3

Qual parte do seu servidor está fazendo pesquisas de DNS? A maioria das configurações do servidor Web desabilita explicitamente a pesquisa inversa de DNS de cada usuário, em termos de velocidade (porque o DNS é lento em geral).

Como Patrick observa, o nscd está fazendo a coisa certa e respeitando os valores positivos de TTL. Sim, você poderia substituí-lo ( unbound permitiria que você fizesse isso facilmente, apenas modifique server.cache-min-ttl , tem avisos sobre o aumento além de 1 hora pelos mesmos motivos). No entanto, suas consultas provavelmente são em sua maioria rDNS, que tendem a ter mais TTLs em geral.

Além disso, como seu maximum number of cached values é muito baixo, eu gostaria de observar que você não está recebendo tráfego.

Se você se preocupa com o local onde os usuários repetem com frequência, sugiro fazer logout dele fora do nscd e não se preocupar mais com isso.

Editar (2013/12 // 09): nscd -g hospeda estatísticas de dev.gentoo.org (sem bloqueios nos comentários):

nscd configuration:
 4h  8m 43s  server runtime
hosts cache:
        yes  cache is enabled
         no  cache is persistent
         no  cache is shared
        422  suggested size
    1108744  total data pool size
     966632  used data pool size
        600  seconds time to live for positive entries
         20  seconds time to live for negative entries
      67878  cache hits on positive entries
       2479  cache hits on negative entries
       9464  cache misses on positive entries
       4276  cache misses on negative entries
         83% cache hit rate
       6951  current number of cached values
       7641  maximum number of cached values
         33  maximum chain length searched
          1  number of delays on rdlock
          0  number of delays on wrlock
          0  memory allocations failed
        yes  check /etc/hosts for changes
    
por 08.12.2013 / 02:38
2

Pode ser um pouco fora do tópico, mas em vez de usar nscd , você pode alternar para sssd (que considero seu sucessor).

Estou usando no SUSE Linux Enterprise Server 11.3 (totalmente suportado) e estou feliz por ter feito a troca. Ele tem muito mais opções de configuração do que nscd e também tem recursos que vão muito além do que o nscd pode alcançar.

Pelo menos eu acho que vale a pena dar uma olhada: link

    
por 10.12.2013 / 15:35
2

Este parâmetro:
sim cache é compartilhado

permite que os aplicativos se fixem no cache do nscd, e tal atividade não é registrada. Esse é o comportamento esperado e mais eficiente.

Defina isso como NÃO e você verá sua taxa de acerto subir drasticamente, mas é um pouco mais lenta.

Veja: link

    
por 04.01.2014 / 23:35
1

O nscd está respeitando os valores TTL upstream.

Se o servidor DNS de google.com disser que o TTL do registro A de google.com é de 10 segundos e você tem um positive-time-to-live de 36000, o registro ainda expirará em 10 segundos.

    
por 06.12.2013 / 16:56