Início / server / Perguntas / 968727
Accepted
A. Nilsson
Asked: 2019-05-25 06:50:14 +0800 CST

Linux /proc/sys/vm/drop_caches em VMs convidadas

  • 772

Pergunta: Seria uma boa ideia desabilitar o cache de página dentro de VMs convidadas e, em vez disso, confiar no ZFS ARC (e L2ARC baseado em SSD) do host?

Contexto: Estou perguntando porque estou executando um cluster Proxmox que está sempre mostrando cerca de 90% de uso de RAM para todas as VMs, independentemente de quanto ele realmente precisa. Isso é esperado devido ao uso do cache de página pelo kernel convidado. Como tenho ouvido muitas coisas boas sobre o ARC do ZFS, isso me fez pensar que talvez eu pudesse aumentar a dependência deles e reduzir a dependência do cache de página dos convidados. Em essência, o ARC seria uma espécie de cache de página compartilhada para todas as VMs.

Ao fazer isso, eu obteria o benefício adicional de estatísticas e gráficos proxmox mais precisos, fornecendo assim uma imagem melhor de quanta memória cada VM realmente precisa. Isso, por sua vez, me daria as informações necessárias para ajustar melhor os tamanhos da RAM de cada VM e permitir que eu aumentasse o tamanho do ARC do host na mesma quantidade.

Eu realmente não tentei nada disso, eu pensei em executá-lo por vocês primeiro. Então, eu sou estúpido por pensar assim?

Pergunta de acompanhamento : COMO eu faria para desabilitar (ou limitar) o cache de página em uma VM Linux? UM método seria usar um cronjob e escrever regularmente "3" em /proc/sys/vm/drop_caches, como uma vez a cada minuto ou algo assim. Mas parece meio hacky, não há uma maneira melhor?

PS Sim, percebo que estou falando apenas de cache de leitura, não de cache de gravação, que é afetado pela quantidade de páginas sujas . Portanto, eu provavelmente ainda precisaria de alguma quantidade de espaço livre de RAM para permitir isso (mas isso deve ser visível nas estatísticas de uso de RAM da VM no Proxmox, portanto, tudo acima ainda deve ser aplicado).

linux

1 respostas

  1. Best Answer

    Muitas vezes (mas nem sempre, veja abaixo) otimizo meus hipervisores de maneira semelhante ao que você sugere: permitir que as VMs transmitam fortemente o cache de disco do host compartilhado.

    No entanto, usar a drop_cachesabordagem parece muito pesado para mim, pois pode remover muita memória cache do convidado. Ao mesmo tempo, não conheço nenhum método para limitar o cache de página (a não ser configurar seu aplicativo para usar E/S direta). Portanto, a chave é dimensionar corretamente os recursos de RAM da VM: tente atribuir apenas a memória que um convidado realmente precisa, mais 1 ou 2 GB para ter algum "espaço para respirar".

    Gerenciar a memória dessa maneira tem algumas vantagens importantes:

    • sendo gerenciada pelo host, a memória cache pode ser alocada dinamicamente aos convidados com base em seus requisitos de E/S;
    • em virtude de ser gerenciado dinamicamente, tratando sua memória como um verdadeiro pool de recursos, você reduz o desperdício de recursos e aumenta a eficiência;
    • se estiver usando o ZFS em seu host, você acessa o ARC/L2ARC muito avançado e seu comportamento resistente a lixo

    Mas também existem algumas desvantagens:

    • sendo um recurso compartilhado, a memória cache do host pode ser destruída por uma VM não autorizada (afetando outras VMs mais importantes);
    • estando localizados alguns interruptores de contexto e vmexit/vmenterafastados, a velocidade de pico e sustentada de qualquer cache baseado em host será menor do que o cache do lado do convidado corrispetitivo (e esta é a razão pela qual sugiro que você evite repetidos drop_cachesno convidado);
    • embora mais avançado e com taxa de acertos muito mais alta, o ARC é mais lento que o cache de página do Linux quando a carga de trabalho cabe inteiramente no cache. Portanto, para obter a velocidade máxima do convidado em convidados com desempenho crítico, você provavelmente deseja fornecer à VM memória suficiente para o cache de página.
    • 3

relate perguntas