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 .