Devo ficar preocupado com o fato de o swap estar sendo usado em um host com quase 40 GB de memória livre?


39

Eu tenho um host de produção, abaixo:

htop

O sistema está usando 1 GB de swap, mantendo quase 40 GB de espaço livre e não utilizado na memória. Devo me preocupar com isso, ou é principalmente normal?


23
Na verdade, você deve se preocupar com um host de produção com carga real gastando quase 40 GB de memória. Certamente poderia encontrar algum uso para colocar essa memória - os aplicativos estão acessando os discos, não poderia usar essa memória para armazenar em cache alguns desses dados, reduzir as E / Ss e melhorar seu desempenho? Por que 40 GB de memória estão sendo desperdiçados em uma máquina que está funcionando? É com isso que você deve se preocupar. Isso não é normal.
David Schwartz

25
Seria realmente mais útil se você nos mostrasse a saída de free -m. Os gráficos são difíceis de ler.
user9517 suporta GoFundMonica

@DavidSchwartz - Eu tenho uma pergunta relacionada que ainda está ativa nisso. serverfault.com/questions/825909/…
MrDuk

Respostas:


68

Isso não é um problema e provavelmente é normal. Muito código (e possivelmente dados) é usado muito raramente, portanto o sistema irá trocá-lo para liberar memória.

A troca é principalmente apenas um problema se a memória estiver sendo trocada ou desativada continuamente. É esse tipo de atividade que diminui o desempenho e sugere um problema em outras partes do sistema.

Se você deseja monitorar sua atividade de swap, é possível com vários utilitários, mas vmstatgeralmente é bastante útil, por exemplo

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 348256  73540 274600    0    0     1     9    9    6  2  0 98  0  0
 0  0      0 348240  73544 274620    0    0     0    16   28   26  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   29   33  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   21   23  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   24   26  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   23   23  0  0 100  0  0

Ignore a primeira linha, pois é uma atividade desde que o sistema foi iniciado. Observe as colunas sie soabaixo ---swap--; eles geralmente devem ser números relativamente pequenos, se não 0 na maioria das vezes.

Também vale a pena mencionar que essa troca preventiva pode ser controlada com uma configuração do kernel. O arquivo em /proc/sys/vm/swappinesscontém um número entre 0 e 100 que informa ao kernel como agressivamente trocar a memória. Cat o arquivo para ver o que está definido. Por padrão, a maioria das distribuições Linux o padrão é 60, mas se você não deseja trocar nenhuma troca antes que a memória se esgote, faça o eco de um 0 no arquivo da seguinte maneira:

echo 0 >/proc/sys/vm/swappiness

Isso pode ser permanente, adicionando

vm.swappiness = 0

para /etc/sysctl.conf.


14
Também vale a pena mencionar que essa troca preventiva pode ser controlada com uma configuração do kernel. O arquivo em / proc / sys / vm / swappiness contém um número entre 0 e 100 que informa ao kernel com que intensidade a troca de memória é agressiva. Cat o arquivo para ver o que está definido. Por padrão, a maioria das distribuições Linux padrão esta a 60, mas se você não quer ver qualquer troca antes memória está esgotado, ecoar um 0 para o arquivo como este: echo 0 >/proc/sys/vm/swappiness. Isso pode ser permanente, adicionando vm.swappiness = 0ao /etc/sysctl.conf.
virtex

@virtex: Eu gosto de usar swappiness = 1, ou apenas algo abaixo de 10, na minha área de trabalho. Isso pode se dar bem em servidores na maioria das vezes também. Desencoraje fortemente a troca para liberar RAM para mais pagecache, sem proibi-la totalmente.
Peter Cordes

11
@PeterCordes Cuide dos servidores, especialmente aqueles que acessam bancos de dados ou veiculam arquivos. Isso pode se beneficiar muito com a disponibilidade da memória para caches de arquivos.
Jonas Schäfer

4
@JonasWielicki: Mesmo com swappiness=7algo assim, as páginas não utilizadas de longo prazo são trocadas. Há uma grande diferença entre swappiness=0e qualquer outro valor, mesmo valores baixos. O padrão do kernel swappiness=60geralmente é bom para servidores e é apenas para uso interativo na área de trabalho, onde uma baixa troca é boa. Mas configurá-lo para 7 ou algo assim não deve doer muito. (Mas não verifiquei, não sou um administrador de sistemas do servidor).
Peter Cordes

2
@ PeterCordes Até você colocar pressão na memória, tudo swappinessfunciona bem. Com a pressão, você verá que swappiness=7deixa o cache de arquivos com fome quase completamente por um longo período de tempo, enquanto swappiness=60liquida muito cache, mas também começa a trocar em segundos. Ainda é o cache que leva a surra, mas de uma maneira muito mais equilibrada.
kubanczyk

25

O Linux escreverá preventivamente as páginas no disco se não tiver nada melhor para fazer. No entanto, isso não significa que as páginas serão removidas da memória. É só que no caso deve expulsar essas páginas em algum momento no futuro, não precisa esperar por eles para ser gravado no disco, porque eles já estão lá.

Afinal, a razão pela qual você está ficando sem memória é provavelmente porque sua máquina já está trabalhando duro, você não deseja sobrecarregá-la adicionalmente com a troca. Melhor fazer a troca quando a máquina não estiver fazendo nada.

Por um motivo semelhante, sua memória deve estar sempre cheia. Páginas de memória, cache do sistema de arquivos tmpfs, há muitas coisas que podem ser armazenadas na memória. Realmente, você deve se preocupar se sua memória estiver vazia; afinal, você pagou muito dinheiro por ele (pelo menos em comparação com a mesma quantidade de espaço em disco), portanto é melhor usá-lo!


Jorg, as páginas que o kernel preemptivamente grava em discos não são páginas de troca, são páginas de cache de disco sujas. O vm.dirty_background _... tunnables controla isso. A atividade de troca inicia de acordo com a capacidade de troca ajustável e não espera por tempos de inatividade.
Lucas

11

A troca usada não é ruim, mas muita atividade de troca é

  vmstat 1
  procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
  6  0 521040 114564   6688 377308    8   13   639   173    0 1100  5  4 90  0
  1  0 521040 114964   6688 377448    0    0   256     0    0 1826  3  4 94  0
  0  0 521040 115956   6688 377448    0    0     0     0    0 1182  7  3 90  0
  0  0 521036 115992   6688 377448    4    0    16     0    0 1154 10  2 88  0
  3  0 521036 114628   6696 377640    0    0   928   224    0 1503 15 17 67  1

A coluna swapd não é problema. Valores diferentes de zero nas colunas si e, portanto, são mortais para o desempenho do servidor. Especialmente aqueles com muita memória RAM.

É melhor desativar a permuta em máquinas com vários GB de RAM:

sysctl -w vm.swappiness=0

Isso não desativará a troca. Apenas instruirá o Linux a usar a troca como medida de último recurso. Isso vai desperdiçar alguns MB de programas que não precisam estar na RAM ... Mas é preferível trocar inchaço nas filas de acesso ao disco.

Edit 1: por que o valor padrão de swappiness não é ideal

Temos que lembrar duas décadas atrás, um grande 486 tinha apenas 32Mb de RAM. Os algoritmos de swap foram desenvolvidos quando toda a RAM podia ser movida para o disco em uma pequena fração de segundo. Mesmo com os discos mais lentos da época. É por isso que as políticas de troca padrão são tão agressivas. A RAM era o gargalo daqueles dias. Desde então, o tamanho da RAM aumentou mais de 10.000 vezes e a velocidade do disco menos de 10 vezes. Isso mudou o gargalo para a largura de banda do disco.

Edit 2: por que si tão atividade é mortal para servidores?

Si e, portanto, a atividade em máquinas com toneladas de RAM é mortal porque significa que o sistema está lutando consigo mesmo por RAM. O que acontece é que os discos, mesmo os grandes armazenamentos, são muito lentos quando comparados às RAMs. A troca agressiva favorece o cache do disco do kernel sobre os dados do aplicativo e é a fonte mais comum de luta pela RAM. Como o sistema operacional precisará liberar o cache do disco a cada si , o tempo de vida do cache extra fornecido pela troca é muito baixo para ser útil. O resultado é que você está usando a largura de banda do disco para armazenar o cache que provavelmente não será usado e pausando os programas aguardando as páginas si . Isso significa que consome muitos recursos críticos com pouco ou nenhum benefício para os aplicativos.

Observe o título da resposta "muita atividade de troca em servidores com muita RAM". Isso não se aplica a máquinas com atividades ocasionais e assim por diante. Isso pode não se aplicar no futuro se algoritmos de troca mais inteligentes forem desenvolvidos nos sistemas operacionais.

Editar 3: páginas "frias"

As pessoas romantizam o algoritmo de troca. Alguns dizem "são necessárias páginas menos usadas da RAM", mas não é isso que o kernel faz. O que é difícil de entender sobre swap é que o kernel não sabe o que é uma "página fria". O kernel não possui uma boa métrica para determinar se a página é usada ou provavelmente será usada em um futuro próximo. Para burlar que o kernel coloque as páginas na troca mais ou menos aleatoriamente e as páginas que não são necessárias permanecem lá. O problema desse algoritmo é que as páginas precisam ir para a troca para saber se são necessárias pelos aplicativos. E isso significa que muitas páginas "quentes" serão trocadas. O problema é que os discos são muito lentos se comparados à RAM.

Criei meu próprio benchmark, que é um cenário realista muito comum a muitos aplicativos com um volume decente. Nos meus testes, não vi benefícios na taxa de transferência ou na latência quando os swaps estão em uso. Longe disso. Quando a troca é iniciada, diminui a taxa de transferência e a latência em pelo menos uma ordem de magnitude.

Eu vou um pouco mais longe: entendo que swap não é para processamento. Os swaps são apenas para emergências. Aqueles momentos em que muitos aplicativos estão sendo executados ao mesmo tempo e você recebe um pico de memória. Sem troca, isso causaria erros de falta de memória. Considero o uso de swap uma falha das equipes de desenvolvimento e produção. Esta é apenas uma opinião que vai muito além do que discutimos aqui, mas é o que penso. É claro que meus aplicativos têm excelente gerenciamento de memória por si mesmos.


9
"Melhor desativar a permuta" Melhor, por quê? (Melhor, para qual finalidade?) O padrão pode não ser adequado para todos os usos, mas eu ainda precisaria de um motivo para alterá-lo.
jpaugh

3
Como é simais mortal para o seu servidor bi? Ambos significam que algum programa está aguardando a leitura de 4096 bytes do disco para a memória. O bié de qualquer arquivo e side uma categoria estreita específica de arquivos (mas seus bytes se movem com a mesma rapidez pelo mesmo caminho).
precisa saber é o seguinte

2
Um 486 com 128 MB de RAM era muito raro e seria considerado um mainframe ou supercomputador - portanto, a CPU provavelmente seria 486. Meu antigo 486 tinha 4 MB de RAM e eu tinha inveja da máquina do meu amigo com 16 MB de RAM (servidores grandes 16 a 32 MB de RAM). Avanço rápido para Pentiums e começamos a ver 8 a 16 MB como o normal. Quando o Pentium3 apareceu pela primeira vez (quando as CPUs começaram a exceder normalmente 1 GHz), 32 MB eram normais e os servidores da Web geralmente tinham de 64 a 128 MB.
slebetman

swappiness=0parece totalmente inadequado para servidores. Você pode considerá-lo como um sistema de desktop interativo (mas, mesmo assim, swappiness=1é uma opção melhor para trocar páginas realmente frias). Veja comentários em outra resposta . swappiness=7ou algo reduzirá drasticamente a atividade de troca sem fixar páginas frias na RAM até o OOM, e vale a pena considerar se você acha que 60é swappy demais para um servidor específico.
Peter Cordes

11
@kubanczyk: Eu acho que sié pior do que bi. A maioria dos softwares de servidor é projetada com base na suposição de que a E / S do disco pode ser lenta e usa threads, E / S assíncrona ou alguma outra técnica para permanecer responsiva em geral enquanto aguarda a E / S. Uma falha de página pode ocorrer em qualquer lugar. Na pior das hipóteses, uma falha de página lenta pode ocorrer após um bloqueio, impedindo que todos os outros threads entrem nessa seção crítica por ~ 10ms (com troca no armazenamento rotacional lento). Isso pode ser plausível se uma seção crítica copiar dados de uma estrutura de dados compartilhada para uma página potencialmente fria.
Peter Cordes

8

Esta não é uma resposta para sua pergunta; mas sim, apenas informações extras para ajudá-lo a tomar uma decisão informada.

Se você gostaria de saber quais processos especificamente estão usando quanta troca, aqui está um pequeno script de shell:

#!/bin/bash

set -o posix
set -u

OVERALL=0
for DIR in `find /proc/ -maxdepth 1 -type d -regex "^/proc/[0-9]+"` ; do
  PID=`echo $DIR | cut -d / -f 3`
  PROGNAME=`ps -p $PID -o comm --no-headers`

  SUM=0
  for SWAP in `grep Swap $DIR/smaps 2>/dev/null| awk '{ print $2 }'` ; do
    let SUM=$SUM+$SWAP
  done
  echo "PID=$PID - Swap used: $SUM - ($PROGNAME )"

  let OVERALL=$OVERALL+$SUM
done
echo "Overall swap used: $OVERALL"

Devo acrescentar também que os tmpfs também serão trocados. Isso é mais comum em sistemas Linux modernos que usam systemd que criam sobreposições de espaço de usuário / tmp usando tmpfs.


Bom roteiro. Dê uma olhada no smem também.
user9517 suporta GoFundMonica

Eu acho que você poderia escrever com muito mais eficiência ( muito menos processos bifurcados) awk '/Swap/ {sw += $2} FNR==1 { /*first line of a new file */ find the command somehow, maybe still fork/exec ps;} END { print totals }' /proc/[0-9]*/smaps. Isso executa cut e ps para todos os processos, e grep + awk várias vezes para todos os processos no sistema.
Peter Cordes

0

Notei que a replicação do MySQL Cluster diminui ou falha quando os agentes estão trocando bastante. Talvez alguns aplicativos não se importem ou talvez se beneficiem de algumas trocas, mas os bancos de dados realmente parecem sofrer com isso. No entanto, muitas discussões que vi nos fóruns discutem a troca descontextualizada da discussão específica sobre carga de trabalho.

No mundo do DBA, o consenso parece ser "É senso comum que, quando você estiver executando o MySQL (ou realmente qualquer outro DBMS), não queira ver nenhuma E / S em seu espaço de troca. Escalando o tamanho do cache (usando innodb_buffer_pool_size no caso do MySQL) é uma prática padrão para garantir que haja memória livre suficiente para que a troca não seja necessária.

Mas e se você cometer algum erro ou erro de cálculo e a troca acontecer? Quanto isso realmente afeta o desempenho? É exatamente isso que me propus a investigar. "

Espero que os leitores encontrem os links a seguir.

https://www.percona.com/blog/2017/01/13/impact-of-swapping-on-mysql-performance/

https://www.percona.com/blog/2010/01/18/why-swapping-is-bad-for-mysql-performance/


11
Bem-vindo à falha do servidor! Embora isso possa teoricamente responder à pergunta, seria preferível incluir aqui as partes essenciais da resposta e fornecer o link para referência.
Frederik Nielsen
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.