Despejo de cache de passagem de diretório apesar de ter muita memória?

Question

Eu tenho um enorme repositório do Mercurial (adivinhe quantos diretórios ele tem - vai ser mais do que você imaginou). O tempo gasto para fazer operações básicas de repositório é altamente dependente de o cache de buffer do sistema estar quente ou frio, como demonstra o exemplo a seguir (um comando é executado logo após o outro):

bash> time hg status

real    0m41.809s
user    0m0.815s
sys     0m0.217s

bash> time hg status

real    0m0.858s
user    0m0.679s
sys     0m0.175s

Depois que eu não uso a máquina por alguns dias (sem reinicializar), acho que o cache ficou frio e demora muito tempo para executar hg status . Isso ocorre apesar de nenhum ou alguns dos diretórios terem sido alterados (verificados por meio da verificação de mtimes) e terem uma quantidade gigantesca de RAM (o que, mesmo contando o cache de páginas, não é todo usado; verificado com free ).

Então, dado que não há pressão de memória, por que as coisas estão sendo despejadas dos caches dentais ou inode? Eles têm algum tamanho máximo em algum lugar? Curiosamente, nunca vi a coluna "buffers" em free ficar muito acima de 4 GB. Não tenho certeza se o sistema está se recusando a deixar o cache de buffer crescer mais do que isso.

    

Answer 1

O cache que mais importa para a passagem de diretórios é o cache de inode. Isso não está incluído na figura "cache" que exibe free . Faz parte dos dados do kernel (o “ slab ”). Você pode ver quanta memória os vários pools slab ocupam em /proc/slabinfo (isso requer acesso root). Você pode usar slabtop para vê-los variar em tempo real ou esse snippet para obter um relatório com o tamanho de cada pool em bytes:

</proc/slabinfo awk '{print $1, $3*$4}' |sort -k2n

Em uma máquina típica, a pressão no cache de inodes vem do trabalho noturno de updatedb . Se você encontrar como evitar isso, me avise .

O tamanho do pool de cache de inode não é fixo, é determinado por uma proporção de cache de metadados por cache de dados: o vm.vfs_cache_pressure parameter . Você pode querer experimentar com isso - um valor baixo (o padrão é 100) para manter mais entradas no cache, para que as de hg não sejam deslocadas ou um valor alto para que as entradas de tarefas noturnas do cron não fique para poluir a RAM.

Finalmente, há sempre o truque de executar hg status em um trabalho cron matutino.