Posso executar um servidor Oracle sem swap?

Question

Documentos oficiais do Oracle dizem que, para uma máquina com mais de 16GiB de RAM, precisamos alocar 16GiB de troca.

Nossos servidores são RHEL 7 e possuem 256GiB de RAM.

DBAs não querem ver a troca do sistema, então eles querem que nós monitoremos o 16GiB de swap de forma muito agressiva.

Eu sugeri que dobrássemos a RAM para 512GiB (a despesa é aprovada) e desativamos a troca. No entanto, isso é contra a recomendação da Oracle de ter 16GiB de RAM, apesar de dobrarmos a RAM.

Honestamente, eu não entendo como ter 3% de swap faz algum sentido, ou porque se eu estou adicionando mais RAM do que tínhamos swap, temos que manter o swap.

Então, existem argumentos bons que eu possa usar para justificar a execução do Oracle sem swap?

P.S. A única razão pela qual menciono a duplicação de RAM é demonstrar o ridículo do argumento que estou tendo dificuldade em argumentar. O que estou realmente procurando são argumentos para justificar a desativação do swap.

    

Answer 1

Desativar a troca é uma boa ideia se

• seu software pode lidar com as condições de falta de memória normalmente ou se limitar a evitar situações de OOM
• ter desempenho consistente é essencial (quando o sistema está trocando a latência aumentará, 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. Eu vejo mais com bancos de dados sem SQL, mas bancos de dados relacionais podem sofrer o mesmo desafio.

Não há nada no SO que exija que o swap esteja lá. O Linux lida com isso muito bem matando o último processo que pedia memória. Você não quer chegar a esse ponto, então certifique-se de ajustar o Oracle para usar apenas ~ 90% da memória, então sobra algum para os daemons do sistema e margem de erro. A memória "Free" também é usada para armazenar em buffer a E / S do disco, o que é um grande ganho de desempenho, então tentar consumir mais memória do próprio banco de dados 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 similar, eu não teria nenhum padrão de swap neste ponto.

Autoridades

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

Cassandra

Datastax explica para o Cassandra:

You must disable swap entirely. Failure to do so can severely lower performance. Because Cassandra has multiple replicas and transparent failover, it is preferable for a replica to be killed immediately when memory is low rather than go into swap. This allows traffic to be immediately redirected to a functioning replica instead of continuing to hit the replica that has high latency due to swapping. If your system has a lot of DRAM, swapping still lowers performance significantly because the OS swaps out executable code so that more DRAM is available for caching disks.

riak

Basho explica ao Riak que você deve:

Ideally, you should disable swap to ensure that Riak’s process pages are not swapped. Disabling swap will allow Riak to crash in situations where it runs out of memory. This will leave a crash dump file, named erl_crash.dump, in the /var/log/riak directory which can be used to determine the cause of the memory usage.

mysql

Percona está sentado em cima do muro e fornece advertências úteis para ambos os lados da questão. MariaDB não concorda com a desativação da troca:

While some disable swap altogether, and you certainly want to avoid any database processes from using it, it can be prudent to leave some swap space to at least allow the kernel to fall over gracefully should a spike occur. Having emergency swap available at least allows you some scope to kill any runaway processes.

ServerFault

Uma resposta bem recebida aqui inclui:

I personally find a swappy system worse than a crashed system. A crashed system would trigger a standby backup server to take over much sooner. And in an active-active (or load balanced setup) a crashed system would be taken out of rotation much sooner. A win for the no-swap system again.

Essa resposta tem 22 votos positivos hoje e tem 4 anos de idade. Você também pode ver algumas outras respostas que exaltam o valor do swap, mas não há indicação de que estejam executando bancos de dados. Eles também não têm tantas votações. :)

lula

Enquanto eles não recomendam explicitamente a desabilitação de swap, os caras do squid dizem :

Squid tends to be a bit of a memory hog. It uses memory for many different things, some of which are easier to control than others. Memory usage is important because if the Squid process size exceeds your system's RAM capacity, some chunks of the process must be temporarily swapped to disk. Swapping can also happen if you have other memory-hungry applications running on the same system. Swapping causes Squid's performance to degrade very quickly.

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

redis

Enquanto o redis recomenda oficialmente a troca dos usuários não compre :

First disable swap - Redis and swap don't mix easily and this can certainly cause slowness.

hadoop

Como pode ser visto em esta resposta com mais votos na comunidade hortonworks :

For slave/worker/data hosts which only have distributed services you can likely disable swap. With distributed services it's preferred to let the process/host be killed rather than swap. The killing of that process or host shouldn't affect cluster availability. Said another way: you want to "fail fast" not to "slowly degrade.

[....]

For masters, swap is also often disabled though it's not a set rule from Hortonworks and I assume there will be some discussion/disagreement. Masters can be treated somewhat like you'd treat masters in other, non-Hadoop, environments.

The fear with disabling swap on masters is that an OOM (out of memory) event could affect cluster availability. But that will still happen even with swap configured, it just will take slightly longer. Good administrator/operator practices would be to monitor RAM availability, then fix any issues before running out of memory. Thus maintaining availability without affecting performance. No swap is needed then.

Eu gosto disso porque está falando sobre um aplicativo Java, mas ele alcança muitas das mesmas conclusões mencionadas acima sobre bancos de dados. Além disso, menciona o monitoramento , que é muito útil no ajuste de 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. Crie gráficos para cada medida mensurável - latência em nível de aplicativo e taxa de transferência para gráficos de CPU, disco, memória e rede. Eles fornecem a maior parte dos dados reais que você precisa tomar decisões.

    

Answer 2

Alex no Linux tem uma leitura interessante sobre este assunto: "Trocar vs. não trocar" link

A conclusão é que, sem swap:

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

Answer 3

Este tópico aparece com freqüência. O swap é apenas uma extensão da RAM, então vamos comprar mais RAM, certo? Errado. O programa de instalação com 16 GiB swap e 512 GiB RAM torna o sentido econômico perfeito . Deixe-me explicar.

Se você conhece bem o software principal, sabe o quanto de memória "estúpida" é preciso. Que memória "estúpida"? Vários códigos e dados que inicialmente aparecem na RAM, mas nunca serão criticamente necessários novamente. Ou seja, o desempenho visto pelo usuário nunca sofrerá porque esse material não está prontamente disponível na memória.

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

Com efeito, você ganha 16 GiB de RAM para fazer o trabalho real e beneficiar seus usuários. A partir de 2017, reduz o custo da sua organização em aproximadamente US $ 50. Se o seu servidor tiver 256 GiB de RAM, configure o swap e economize US $ 50. Se o seu servidor tiver 10 TiB de RAM, configure o swap e salve ... $ 50. Vejo? Ainda é o mesmo.

Atualmente, é sempre seguro ter troca zero. Simplesmente custa-lhe apenas $ 50, isso é tudo.

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

Alguns fornecedores realmente têm memória perdida zero. E alguns fornecedores não se sentem confiantes o suficiente para estimar a quantidade de alocações "estúpidas", então eles dizem "troca zero" para evitar problemas desconhecidos apenas para economizar um monte de seus dólares. Tudo bem também! Eu confiaria apenas no fornecedor, eles suportam as instalações, eles sabem suas coisas.

    

Answer 4

Por que não manter uma quantidade razoável de troca por páginas não utilizadas e modificar a pressão de cache do vfs para modificar a permutabilidade para apenas trocar no caso de condição de OOM. Além disso, você pode fixar os processos Oracle na memória principal para garantir que eles nunca toquem no disco. Isso satisfaz que o banco de dados não sofra impacto ao acessar sistemas lentos de E / S e também permite liberar lixo da memória principal para ser usado pelo banco de dados, buffers e cache. É o melhor dos dois mundos.