Pergunta interessante!
Como referência, esta página do autor do subsistema da VM fornecerá uma boa ideia do que provavelmente acontecerá.
Note que isto é realmente muito difícil de responder em sua forma atual (se você está falando sobre caches suportados por arquivos) porque depende de quão quente o cache é, por quanto tempo você armazena os itens e o 'aquecimento' de cada objeto no cache.
Assumindo o seguinte: -
- O cache é apoiado por um arquivo 10G e foi completamente preenchido.
- 3% dos objetos no cache perfazem 90% de todos os hits.
- Você tem uma simultaneidade de cerca de 80 conexões gerenciadas a qualquer momento.
- Você não alterou sua política de VM do padrão.
- Antes do comando, o pagecache é quase que quase totalmente preenchido com páginas do seu cache de verniz.
- 500 M de dados são alocados exclusivamente para páginas anônimas de outras coisas em execução no sistema.
Como o tamanho do seu cache de verniz é 10G, ele nunca se ajustará completamente na memória, portanto a seguinte fórmula é relativamente representativa
- Existem 3500M de cache de páginas.
- O mais quente 1750Mb de cache de verniz está na lista "ativa" e protegido do despejo de pagecache.
- O cooler de 1.750 MB de cache de verniz está na lista "inativo" e não é protegido contra despejo.
- O mais frio 6500Mb de cache de verniz não reside na memória e vive no disco em algum lugar.
Então, o seguinte é provavelmente o resultado de todos os comandos que você executa ..
- Este arquivo é colocado na memória e armazenado em cache, mas todos os novos objetos no cache são enviados para a lista 'inativa' por padrão.
- Isso despeja 1750 MB de sua memória 'mais fria / inativa' do cache de verniz e a substitui pelo arquivo catalogado.
- O kernel agora é forçado a gravar 1750M desses dados no disco (no pior cenário possível).
- IO Espera e a utilização do dispositivo é afetada porque você está lendo em um arquivo 2G e gravando um arquivo 1750M.
- 97% das solicitações de entrada não são afetadas por isso, porque querem os 1750Mb mais quentes de dados de verniz que estão na parte ativa do cache de páginas!
- 3% dos clientes desafortunados querem dados no cache do cooler. Esses caras vêem um atraso agora porque a utilização do disco já está bem alta e eles estão enfileirados para recuperar as páginas de volta no cache de páginas novamente! Como o arquivo catalogado nunca é relido rapidamente, o cache da página libera essas páginas em favor dos 3% de clientes que desejam alguns dados mais frios.
Este é o pior cenário possível. Então, de um modo geral - qual é o impacto?
Não há impacto negligenciável em 97% das solicitações atendidas.
Dos 3% que são afetados, espere um atraso maior nos que estão sendo atendidos - provavelmente 500 milissegundos.
MAS desses 3% de pedidos de azar em torno de 2% deles de qualquer maneira teriam sido lentos porque eles queriam algo fora do cache de 6500Mb que nunca estava no pagecache de qualquer maneira! No entanto, eles sofrem com a alta utilização de disco agora.
Então, em resumo, com meu exemplo artificial e assumido, você verá em termos gerais uma perda de eficiência de 3%. (100% de eficiência seria todos os objetos para cada solicitação serem atendidos sem memória).
Na execução 'normal' neste exemplo artificial, o desempenho seria cerca de 98% eficiente.
Nada mal para um cache que não cabe na memória!