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-300 MB usados pelo sistema operacional e serviços com o restante para cache de arquivo e buffers. Em um caso de uso específico, espero uma sobrecarga fácil de 500 MB.
P: Por que essa configuração precisaria de espaço de troca?
A resposta padrão de "Para evitar o esgotamento da 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 aumento significativo inesperado ou repentino. 2: A troca apenas atrasa a situação OOM em qualquer caso. A mesma coisa pode ser realizada atribuindo mais memória à VM em primeiro lugar, especialmente porque ela é provisionada de forma leve e ninguém a perderá, desde que não seja usada.
A outra resposta comum para oferecer suporte à hibernação não se aplica a um servidor em uma VM.
Não vejo razão para trocar em tal servidor; estou esquecendo de algo?
Você não deve pensar em “ter swap” ou não, você deve considerar sua estratégia geral de alocação de memória e determinar se o swap é necessário ou não. Há dois aspectos principais nisso.
O principal objetivo da troca hoje em dia não é estender a memória física, é fornecer um armazenamento de apoio para páginas não recuperáveis ( por exemplo , alocações de memória e s anônimos
mmap). Se você executar sem swap, forçará o kernel a manter a memória anônima na memória física, o que reduz sua capacidade de lidar com necessidades variáveis de memória. Obviamente, se você sabe que sua carga de trabalho sempre cabe na memória física disponível, isso não deve ser um problema.O segundo aspecto a considerar é a estratégia de overcommit do kernel. Por padrão, as alocações de memória geralmente são bem-sucedidas, independentemente da carga de memória. No entanto, se você estiver tentando controlar sua carga de trabalho, geralmente é útil executar no modo de verificação (
/proc/sys/vm/overcommit_memorydefinido como 2); então os commits são limitados à soma de swap e a memória física não alocada para páginas enormes ajustadas pela taxa de overcommit (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 overcommit. (Isso geralmente atrapalha as pessoas ao tentar executar JVMs grandes em configurações típicas de servidor.)Eu mencionei que existem dois aspectos principais, descritos acima, mas me ocorre que pode haver outro ponto a ser considerado em alguns casos (é realmente uma variante do primeiro ponto):
tmpfsos sistemas de arquivos podem facilmente causar problemas ao seu sistema se não tem troca...Para saber mais sobre tudo isso, recomendo ler as seções da página de
proc(5)manual sobre overcommit e a recente postagem no blog de Chris Down em defesa do swap .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 inicia nunca mais serão tocadas. É indiscutivelmente melhor deixá-los no disco do que na memória RAM, embora qualquer ganho de desempenho seja provavelmente minúsculo.
Em uma observação relacionada, algumas cargas de trabalho, como jvm, alocam bastante memória que pode nunca ser usada. Você pode estar jogando o bebê fora junto com a água do banho se sua carga de trabalho habitualmente for exagerada. Limitar o kernel à memória física pode significar que você a) aloca mais RAM do que a VM precisa, desperdiçando recursos do servidor que poderiam ir para outras VMs ou b) faz com que o kernel reduza a quantidade de buffers para reter os não utilizados (ou raramente usado) páginas alocadas com o aumento resultante na atividade do disco diminuindo o desempenho geral.
Sem a troca ativada, você pode descobrir que sua sobrecarga desaparece misteriosamente se precisar fazer login no sistema para depuração. Na verdade, leva apenas uma vez para fazer login em um sistema que combina restrições de memória iniciais rígidas 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 surra ainda é uma melhoria em relação ao assassino OOM disparando constantemente.
Finalmente, não é incomum em sistemas Unix que dumps de kernel sejam colocados em swap. Um bom número de administradores ainda alocará swap suficiente para permitir a depuração de um kernel panic. (Embora aparentemente o Linux ofereça uma solução alternativa para isso agora.)