Desativar a troca é uma boa ideia se

• seu software pode lidar com condições de falta de memória normalmente ou se limita para evitar situações de OOM
• ter um desempenho consistente é crítico (quando o sistema está trocando, a latência aumenta, o que pode ser ruim o suficiente para torná-lo efetivamente inútil para muitos aplicativos)

Esse tipo de coisa geralmente acontece com bancos de dados. Vejo isso mais com bancos de dados noSQL, mas bancos de dados relacionais podem sofrer o mesmo desafio.

Não há nada no sistema operacional que exija troca para estar lá. O Linux lida com isso com muita elegância, eliminando o último processo que solicitou memória. Você não quer chegar a esse ponto, portanto, certifique-se de ajustar o Oracle para usar apenas ~ 90% da memória, para que haja alguma sobra para os daemons do sistema e margem para erro. A memória "livre" também é usada para armazenar em buffer a E/S do disco, o que é uma grande vitória no desempenho, portanto, tentar consumir mais memória pelo próprio banco de dados acabará por diminuir o desempenho geral do sistema o suficiente para ser contraproducente.

Mesmo com sistemas que têm uma fração da memória da questão se o aplicativo é um banco de dados ou um cache ou sistema semelhante, eu padronizaria a não troca neste ponto.

autoridades

Para que você não confie apenas na minha palavra:

Cassandra

Datastax explica para Cassandra:

Você deve desabilitar totalmente a troca. Deixar de fazer isso pode reduzir significativamente o desempenho. Como o Cassandra tem várias réplicas e failover transparente, é preferível que uma réplica seja eliminada imediatamente quando a memória estiver baixa, em vez de entrar na troca. Isso permite que o tráfego seja redirecionado imediatamente para uma réplica em funcionamento, em vez de continuar atingindo a réplica que possui alta latência devido à troca. Se o seu sistema tiver muita DRAM, a troca ainda reduz significativamente o desempenho porque o sistema operacional troca o código executável para que mais DRAM esteja disponível para os discos de cache.

riak

Basho explica para Riak que você deve:

Idealmente, você deve desabilitar a troca para garantir que as páginas do processo de Riak não sejam trocadas. Desativar a troca permitirá que o Riak trave em situações em que fica sem memória. Isso deixará um arquivo de despejo de memória, denominado erl_crash.dump, no /var/log/riakdiretório que pode ser usado para determinar a causa do uso de memória.

mysql

Percona está em cima do muro e fornece advertências úteis para ambos os lados da questão. MariaDB discorda de desabilitar swap:

Embora alguns desabilitem completamente a troca e você certamente queira evitar que qualquer processo de banco de dados a use, pode ser prudente deixar algum espaço de troca para pelo menos permitir que o kernel caia normalmente caso ocorra um pico. Ter a troca de emergência disponível, pelo menos, permite algum escopo para eliminar qualquer processo descontrolado.

ServerFault

Uma resposta bem recebida aqui inclui:

Pessoalmente, acho um sistema swappy pior do que um sistema travado. Um sistema travado acionaria um servidor de backup em espera para assumir muito mais cedo. E em um ativo-ativo (ou configuração de balanceamento de carga), um sistema travado seria retirado de rotação muito mais cedo. Uma vitória para o sistema sem troca novamente.

Essa resposta tem 22 votos positivos hoje e tem 4 anos. Você também pode ver algumas outras respostas exaltando o valor da troca, mas não há indicação de que estejam executando bancos de dados. Eles também não têm tantos votos positivos.:)

lula

Embora eles não recomendem abertamente desativar a troca, os caras do squid dizem :

Squid tende a ser um pouco devorador de memória. Ele usa a memória para muitas coisas diferentes, algumas das quais são mais fáceis de controlar do que outras. O uso da memória é importante porque se o tamanho do processo do Squid exceder a capacidade de RAM do seu sistema, algumas partes do processo devem ser trocadas temporariamente para o disco. A troca também pode acontecer se você tiver outros aplicativos que consomem muita memória em execução no mesmo sistema. A troca faz com que o desempenho do Squid diminua muito rapidamente.

Isso é o que você não quer que aconteça com seu banco de dados.

redis

Embora o redis recomende oficialmente a troca , os usuários não o compram :

Primeiro desative a troca - Redis e troca não se misturam facilmente e isso certamente pode causar lentidão.

hadoop

Como visto nesta resposta com mais votos na comunidade hortonworks :

Para hosts escravos/trabalhador/dados que apenas têm serviços distribuídos, você provavelmente pode desabilitar a troca. Com serviços distribuídos, é preferível deixar o processo/host ser eliminado em vez de trocar. A eliminação desse processo ou host não deve afetar a disponibilidade do cluster. Dito de outra forma: você quer "falhar rápido" para não "degradar lentamente".

[....]

Para mestres , a troca também é frequentemente desativada, embora não seja uma regra definida da Hortonworks e presumo que haverá alguma discussão/discordância. Os mestres podem ser tratados da mesma forma que você trataria os mestres em outros ambientes não Hadoop.

O medo de desabilitar a troca em mestres é que um evento OOM (falta de memória) pode afetar a disponibilidade do cluster. Mas isso ainda acontecerá mesmo com a troca configurada, só levará um pouco mais de tempo. Boas práticas de administrador/operador seriam monitorar a disponibilidade de RAM e, em seguida, corrigir quaisquer problemas antes de ficar sem memória. Mantendo assim a disponibilidade sem afetar o desempenho. Nenhuma troca é necessária então.

Eu gosto disso porque está falando sobre um aplicativo Java, mas chega a muitas das mesmas conclusões mencionadas acima sobre bancos de dados. Além disso, menciona o monitoramento , que é muito útil para ajustar aplicativos de alto desempenho. Se você não tem números para comparar tudo é baseado em sentimentos que são mais difíceis de comparar. Faça gráficos para cada métrica mensurável - latência no nível do aplicativo e taxa de transferência para CPU, disco, memória e gráficos de rede. Esses fornecem a maior parte dos dados reais sobre os quais você precisa tomar decisões.

Alex no Linux tem uma leitura interessante sobre este assunto: "Swap vs. no swap" http://www.alexonlinux.com/swap-vs-no-swap

O ponto principal é que, sem swap:

• Seu sistema será menos estável.
• A velocidade de acesso ao disco em seu sistema será mais lenta em comparação com um sistema que possui partição swap. Além disso, a velocidade de acesso ao disco diminuirá com o passar do tempo.

Por que não manter uma quantidade razoável de swap para páginas não utilizadas e modificar a pressão do cache vfs para modificar o swapiness para trocar apenas no caso de condição OOM. Além disso, você pode fixar os processos oracle na memória principal para garantir que eles nunca toquem no disco. Isso garante que o banco de dados não seja afetado por atingir sistemas IO lentos e também permite que você libere lixo da memória principal para ser usado pelo banco de dados, buffers e cache. É o melhor dos dois mundos.

Este tópico aparece com frequência. Swap é apenas uma extensão da RAM, então vamos comprar mais RAM, certo? Errado. A configuração com swap de 16 GiB e 512 GiB de RAM faz todo o sentido econômico. Deixe-me explicar.

Se você conhece bem o software principal, sabe quanta memória "estúpida" é necessária com bastante precisão. Que memória "estúpida"? Vários códigos e dados que inicialmente aparecem na RAM, mas nunca mais serão necessários de forma crítica. Ou seja, o desempenho visto pelo usuário nunca será prejudicado porque esse material não está prontamente disponível na memória.

Em vez de consertar o software, você pode apenas dar a ele essa quantidade de troca, mas não mais do que essa quantidade . Sim, deixe-o usar 100% do swap. Essa é a questão. Não aumente a troca, ou corre o risco de que alguma coisa crítica acabe acidentalmente lá. Documente, para que as pessoas não surtem ao ver 100% de uso de swap. No caso do Oracle, esse valor é de 16 GiB e posso dizer pela minha experiência que será usado, mesmo em uma caixa de 700 GiB, e você não experimentará o impacto do swpin no desempenho .

Na verdade, você obtém 16 GiB de RAM para fazer um trabalho real e beneficiar seus usuários. A partir de 2017, reduz o custo da sua organização em aproximadamente $ 50. Se o seu servidor tiver 256 GiB de RAM, configure a troca e economize US$ 50. Se o seu servidor tiver 10 TiB de RAM, configure a troca e economize... $50. Ver? Ainda o mesmo.

Atualmente, é sempre seguro ter swap zero. Simplesmente custa a você aqueles $ 50, só isso.

Se sua organização não for capaz de lidar com swap 100% usado (por exemplo, uma equipe de monitoramento separada, etc.), não o faça. Se você fizer alguém pensar sobre esse assunto, você já desperdiçou $ 50 do tempo deles.

Alguns fornecedores realmente não desperdiçam memória. E alguns fornecedores não se sentem confiantes o suficiente para estimar a quantidade de alocações "estúpidas", então eles dizem "swap zero" para evitar problemas desconhecidos apenas para economizar um monte de dinheiro. Tudo bem também! Eu apenas confiaria no fornecedor nisso, eles dão suporte às instalações, eles sabem o que fazem.