Host Esxi: supercomprometimento de memória aceitável

Question

Quanto posso sobrecarregar a memória física do meu host que atribui memória à minha máquina convidada?

Exemplo:

Memória física do host: 10 GB

É aceitável, por exemplo, atribuir 2 GB de memória virtual a 7 máquinas para um total de 14 GB? Quanto posso comprometer a memória garantindo o balooning e outra técnica de liberação de memória do host funciona bem?

    

Answer 1

Isso basicamente dependerá das máquinas virtuais e de seu uso de memória. O ESXi emprega várias técnicas que permitem a supercomprometimento de memória para convidados:

< h3 > > 1 Cache de compactação de memória

Páginas de memória que ficaram inativas por um tempo estão sendo compactadas e descompactadas e exibidas sob solicitação, em vez de serem trocadas para disco ou com balão. A compactação de página tem um limite superior configurável que é definido como 10% da memória atribuída do convidado por padrão e você pode estimar uma redução de 6% no desempenho ao usar o cache de compactação em cenários reais de acordo com este white paper da VMWare .

< h3 > > 2 Compartilhamento de páginas

Páginas de memória virtual de diferentes convidados que foram encontrados para transportar informações idênticas são referenciadas para a mesma página de memória física. Essa é uma operação assíncrona que libera páginas de memória duplicada regularmente.

< h3 > > 3 Balão de memória

Um driver no nível do kernel no guest fornecido com as ferramentas VMWare solicitará memória no pool de memória não-paginável do convidado e a marcará como "Livre" para o hipervisor. Dessa forma, a memória é efetivamente "roubada" temporariamente do convidado, induzindo a troca em nível de convidado, caso a memória seja realmente necessária para o convidado.

< h3 > > 4 Trocando

Se tudo mais falhar e for necessária mais memória, o ESXi alterna as páginas de memória do convidado para o disco. A localização do arquivo de troca é configurável e é colocada no mesmo diretório com os arquivos de configuração convidados por padrão.

Descobri que, para minhas cargas típicas, a compactação de página e o compartilhamento de página geram cerca de 10% de economia de memória em relação à sobrecarga de memória incorrida pelo ESXi, sem que ocorram degradações de desempenho notáveis. O balonismo sempre funcionará, desde que esteja configurado para (você pode efetivamente desativá-lo reservando toda a memória para o convidado), mas basicamente é apenas marginalmente melhor do que trocar (é onde seus convidados teriam dinamicamente reivindicado grandes quantidades de memória para armazenamento em cache, mas se os convidados já tiverem passado pela falta de memória, isso não pode fazer mágica e incorrerá em E / S de disco devido à sobrecarga, assim como a troca baseada em hypervisor teria feito).

Tudo resumido: se você pudesse configurar seus convidados com overcommitting em torno de 10% e eles continuassem a ser executados sem a troca de guest e as degradações de desempenho associadas, você provavelmente estaria bem com o comprometimento excessivo de 40%. Se não, você definitivamente não o faria.

A saída da página de memória de esxtop (apenas pressione m após iniciar esxtop do console SSH) informaria sobre as estatísticas de memória em tempo real em mais detalhes do que os gráficos você obteria com o cliente vSphere, então vale a pena procurar lá:

 1:54:52pm up 34 days  8:39, 214 worlds; MEM overcommit avg: 0.00, 0.00, 0.00
PMEM  /MB: 32766   total:  1031     vmk, 29568 other,   2166 free
VMKMEM/MB: 32103 managed:  1926 minfree, 13525 rsvd,  18577 ursvd,  high state
NUMA  /MB:  8123 (  767),  8157 ( 2425),  8157 (  186),  7835 (  128)
PSHARE/MB:  2162  shared,   139  common:  2023 saving
SWAP  /MB:     0    curr,     0 rclmtgt:                 0.00 r/s,   0.00 w/s
ZIP   /MB:    17  zipped,    10   saved
MEMCTL/MB:   295    curr,   292  target, 14289 max