como descobrir o que está causando o uso do dentry_cache?

Question

Observe que inode_cache & As lajes do ext3_inode_cache são muito pequenas em comparação com o dentry_cache. O que acontece é que lenta e firmemente a dentry_cache cresce de 1M para ~ 5-6G Então eu preciso correr %código% Isso começou a acontecer um dia em todos os servidores que hospedam algum código da web - os desenvolvedores estão dizendo que eles não mudaram nada relacionado ao padrão de acesso ao sistema de arquivos na época em que o problema começou.

O sistema é centos5 com o kernel 2.6.18, então não tenho recursos de instrumentação disponíveis nos novos kernels. Alguma idéia de como posso depurar o problema? talvez com systemtap? Esta é uma instância do ec2 - portanto, não há certeza de que o systemtap funcionará lá.

Obrigado Alex

    

Answer 1

Mais tarde, mas talvez seja útil para outras pessoas que chegam a isso.

Se você estiver usando o AWS SDK nessa instância do EC2, é altamente provável que a curvatura esteja causando o inchaço dentário. Embora eu não tenha visto esse trigger OOM, sabe-se que ele afeta o desempenho do servidor, devido ao trabalho adicional exigido pelo SO para recuperar o SLAB.

Se você puder confirmar que o curl está sendo usado por seus desenvolvedores para atingir https (muitos AWS SDK fazem isso), a solução é atualizar a biblioteca nss-softokn para pelo menos a v3.16.0 e definir a variável de ambiente , NSS_SDB_USE_CACHE (YES e NO são valores válidos, você pode ter que fazer benchmark para ver qual executa solicitações de curl com mais eficiência) para o processo que está usando libcurl.

Recentemente, encontrei-me e escrevi uma entrada de blog ( link de entrada de blog antigo e relatório de erros no stream ) com alguns diagnósticos & informações mais detalhadas, caso isso ajude.

    

Answer 2

Você tem algumas opções. Se eu estivesse nessa situação, começaria a rastrear as estatísticas em:

# cat /proc/sys/fs/dentry-state 
87338   82056   45      0       0       0

Ao longo do tempo, para ver o quão rápido está crescendo. Se a taxa é um pouco regular, acho que você poderia identificar possíveis culpados de duas maneiras. Primeiro, observar a saída de lsof pode indicar que algum processo está saindo em torno de identificadores de arquivos excluídos. Segundo, você poderia usar o aplicativo principal usando aplicativos e procurar um número excessivo de chamadas relacionadas ao fs (como open (), stat (), etc).

Eu também estou curioso sobre o comentário do @David Schwartz. Eu não vi problemas onde o cache do dentry faz com que o oom mate coisas, mas talvez isso aconteça se todos eles ainda estiverem referenciados e ativos? Se for esse o caso, estou bastante confiante de que o lsof exporia o problema.

    

Answer 3

No nosso caso, fomos capazes de identificar o processo difícil, observando minflt/s

pidstat -l -r
pidstat -l -r | sort -k4nr    # Sort on 4th column. Numerically, reverse (descending). RHEL6.
pidstat -l -r | sort -k5nr    # On newer pidstat, minflt/s is the 5th column. RHEL 7.