Por que o Linux precisa de espaço de troca em uma VM?

2

VM Linux executando nginx (ou qualquer outro daemon leve com uso estável de recursos). A VM recebe 2 GB de memória com 200 a 300 MB usados pelo SO e serviços, com o restante para cache de arquivos e buffers. Em um caso de uso específico, espero uma sobrecarga fácil de 500 MB.

P: Por que essa configuração precisa de espaço de troca?

A resposta padrão de "Prevenir o esgotamento de memória" não faz sentido para mim aqui por 2 motivos: 1: a demanda por memória está bem estabelecida e não precisa suportar um inesperado ou aumento súbito e significativo. 2: Trocar só atrasa a situação da OOM em qualquer caso. A mesma coisa pode ser obtida atribuindo mais memória à VM, principalmente porque ela é thin provisioned e ninguém deixará de usá-la, desde que não seja usada.

A outra resposta comum para suportar a hibernação não se aplica a um servidor em uma VM.

Não vejo razão para troca em tal servidor; estou faltando alguma coisa?

    
por mjb2kmn 17.01.2018 / 22:27

2 respostas

3

Você não deve pensar em "ter swap" ou não, deve considerar sua estratégia geral de alocação de memória e determinar se a troca é ou não necessária. Existem dois aspectos principais para isso.

O principal objetivo do swap hoje em dia não é estender a memória física, mas sim fornecer um armazenamento de apoio para páginas que não seriam recuperáveis (por exemplo, alocações de memória e anônimo mmap s). Se você executar sem swap, você força o kernel a manter a memória anônima na memória física, o que reduz sua capacidade de lidar com as diversas necessidades de memória. Obviamente, se você sabe que sua carga de trabalho sempre se encaixa na memória física disponível, isso não deve ser um problema.

O segundo aspecto a considerar é a estratégia de supercomprometimento do kernel. Por padrão, as alocações de memória são bem-sucedidas, independentemente da carga da memória. No entanto, se você está tentando controlar sua carga de trabalho, geralmente é útil executar no modo de verificação ( /proc/sys/vm/overcommit_memory definido como 2); então as confirmações são limitadas à soma da troca e à memória física não alocada para páginas grandes ajustadas pela taxa de supercomprometimento (que é 50% por padrão). Se você executar sem swap, nada poderá alocar mais da metade da memória física por padrão; adicionando aumentos de swap que limitam linearmente, com menos risco do que aumentar a taxa de supercomprometimento. (Isso geralmente aciona as pessoas ao tentar executar JVMs grandes em configurações típicas do servidor.)

Eu mencionei que existem dois aspectos principais, que são descritos acima, mas me ocorre que pode haver outro ponto a considerar em alguns casos (é realmente uma variante do primeiro ponto): tmpfs file systems pode facilmente coloque seu sistema em apuros se não houver troca ...

Para saber mais sobre isso, recomendo que você leia a proc(5) manpage ' s seções sobre supercomprometimento e post recente do blog de Chris Down em defesa do swap .

    
por 17.01.2018 / 23:27
3

Você não precisa do espaço de troca, mas há alguns pontos que você não mencionou que valem a pena ter em mente. Algumas páginas que são carregadas quando o sistema é iniciado nunca mais serão tocadas. É indiscutivelmente melhor deixá-los no disco do que no RAM, embora qualquer ganho de desempenho seja provavelmente pequeno.

Em uma nota relacionada, algumas cargas de trabalho, como o jvm, alocam um pouco de memória que talvez nunca seja usada. Você pode estar jogando o bebê para fora com a água do banho se sua carga de trabalho for excessiva. Limitar o kernel à memória física pode significar que você a) aloca mais memória RAM do que a VM precisa, desperdiçando recursos do servidor que poderiam ir para outras VMs ou b) fazendo com que o kernel reduzisse a quantidade de buffers para não ser usado (ou raramente usado) páginas alocadas com o aumento resultante na atividade do disco diminuindo o desempenho geral.

Sem a troca ativada, você poderá descobrir que sua sobrecarga desaparecerá misteriosamente se precisar fazer login no sistema para depuração. Realmente, é necessário apenas um registro de tempo em um sistema que combina restrições rígidas de memória inicial e um vazamento de memória para incentivar políticas de espaço de troca mais liberais. Levar uma hora para fazer qualquer coisa em uma máquina de thrashing ainda é uma melhoria em relação ao assassino da OOM que constantemente atira.

Finalmente, não é incomum nos sistemas Unix que os dumps de kernel sejam colocados em swap. Um bom número de administradores ainda irá alocar swap suficiente para permitir a depuração de um kernel panic. (Embora aparentemente o Linux ofereça um trabalho para isso agora.)

    
por 17.01.2018 / 23:43

Tags