Limpar cache da máquina virtual

Question

Eu já postei isso no StackOverflow, mas ele foi sinalizado como Off-Topic. Talvez vocês possam me ajudar.

Atualmente estou fazendo benchmarking de banco de dados em uma máquina virtual executando o Ubuntu 12.04. Percebi que na segunda vez que executo uma consulta, ela é executada de maneira significativamente mais rápida. Isso é provavelmente devido ao cache do sistema operacional que mantém todos os dados na memória principal. Para evitar que o cache estrague minhas medições, eu quero limpá-lo entre execuções subseqüentes.

Eu encontrei os seguintes comandos para conseguir isso no google:

sync;echo 3 > /proc/sys/vm/drop_caches

e

sysctl -w vm.drop_caches=3

que todos rendem em uma permissão negada erro mesmo quando estou logado como root. Parece que não é possível limpar o cache do sistema do sistema convidado. Eu acho que isso é porque ele usa o cache de hosts. Como não tenho acesso ao host, preciso encontrar uma solução alternativa. Atualmente tenho duas ideias.

A primeira ideia é reinicializar a máquina entre as execuções, pois isso limpa o cache. Como eu quero executar algumas dúzias de execuções, eu realmente preciso automatizar isso. Então, eu poderia colocar um programa em autostart, deixe-o realizar uma consulta e reiniciar e continuar com a próxima consulta na próxima inicialização. Parece escrever um vírus embora.

A segunda ideia é apenas inundar a memória com outros dados. Como minha máquina tem um pouco de RAM, eu poderia, por exemplo gerar algum arquivo grande de dados aleatórios e apenas lê-lo em / dev / null.

Então, finalmente, minha pergunta é: alguém tem uma ideia melhor para limpar o cache ou talvez evitar o uso do cache? Ou tem alguma sugestão de como implementar uma das minhas duas ideias com facilidade?

Muito obrigado antecipadamente, Antigo

    

Answer 1

Esta questão parece basear-se na premissa de que a velocidade aumenta na segunda vez é "devido ao cache do sistema operacional que mantém todos os dados na memória principal". Eu não teria tanta certeza que é a diferença somente entre a primeira e a subsequente execução. Se a diferença no desempenho fosse o armazenamento em cache do host VM RAM, a diferença de uma reinicialização da VM deveria ser insignificante e você precisaria reinicializar o host para ver qualquer diferença.

Para uma coisa que pode impactar o desempenho entre a primeira e a subsequente, compilação e análise de consultas, bem como determinar um plano de execução apropriado, também é um trabalho bastante difícil para o mecanismo de banco de dados, portanto os resultados são normalmente armazenados em cache. O impacto disso pode ser insignificante a substancial, dependendo do que mais o mecanismo de banco de dados precisa fazer para satisfazer a consulta.

Se você tiver RAM suficiente para fazê-lo, uma forma de contornar o armazenamento em cache seria simplesmente mover os arquivos do banco de dados para um grande disco RAM durante os testes. Ao monitorar as estatísticas de I / O, você pode estimar a quantidade de I / O incorrida pela consulta e, portanto, os efeitos no desempenho de várias técnicas de otimização, sem precisar se preocupar com os efeitos do cache de dados porque todos os dados já é na RAM.

Você não diz qual mecanismo de banco de dados está sendo executado, por isso é difícil dar sugestões específicas. No Microsoft SQL Server, você faria algo como SET STATISTICS IO,TIME ON e / ou SET STATISTICS PROFILE antes de executar sua consulta para obter dados sobre quão difícil o servidor de banco de dados precisa trabalhar para executar a consulta em questão; outros mecanismos de banco de dados quase certamente têm recursos semelhantes (é um pré-requisito básico para o ajuste de desempenho de consulta). Observe que essas estatísticas geralmente incluem o número de solicitações de E / S reais, e que as solicitações de E / S podem mas não necessariamente serão satisfeitas de qualquer cache no nível do SO Esses números podem ser um indicador útil da quantidade de dados envolvidos na execução de consultas. Grandes diferenças entre o plano de consulta e o resultado real, particularmente em quantidades de E / S ou número de linhas em vários contextos, terão implicações de desempenho, porque significa que o mecanismo de banco de dados está tomando decisões erradas sobre quais algoritmos usar. Grandes quantidades de E / S em qualquer lugar podem muito bem significar que você está atingindo o disco mais do que o necessário, o que terá um custo de desempenho.