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

A troca é principalmente um problema apenas se a memória estiver sendo trocada continuamente. É esse tipo de atividade que mata o desempenho e sugere um problema em outra parte do sistema.

Se você quiser monitorar sua atividade de troca, você pode usar 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 em ; eles geralmente devem ser números bem pequenos, se não 0 na maior parte do tempo.so---swap--

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

echo 0 >/proc/sys/vm/swappiness

Isso pode se tornar permanente adicionando

vm.swappiness = 0

para /etc/sysctl.conf.

O Linux gravará preventivamente as páginas no disco se não tiver nada melhor para fazer. Isso não significa que ele removerá essas páginas da memória. Só que, caso precise remover essas páginas em algum momento no futuro, não precisa esperar que elas sejam gravadas no disco, porque elas 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 quer sobrecarregá-la adicionalmente com trocas. Melhor fazer a troca quando a máquina não está 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á tantas coisas que podem ser mantidas 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), então é melhor usá-lo!

Swap usado não é ruim, mas muita atividade de swap é

  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 algum. Valores diferentes de zero nas colunas si e , portanto, são fatais para o desempenho do servidor. Especialmente aqueles com muita RAM.

É melhor desativar o swapinness em máquinas com vários GB de RAM:

sysctl -w vm.swappiness=0

Isso não desativará a troca. Ele 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 o que encharca as filas de acesso ao disco.

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

Temos que lembrar que, duas décadas atrás, um grande 486 tinha apenas 32Mb de RAM. Os algoritmos de troca foram desenvolvidos quando toda a RAM pode 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 swap padrão são tão agressivas. RAM era o gargalo naqueles 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.

Editar 2: por que a atividade é mortal para os servidores?

Si e assim a atividade em máquinas com toneladas de RAM é mortal porque significa que o sistema está lutando consigo mesmo pela 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 de disco do kernel sobre os dados do aplicativo e é a fonte mais comum de luta pela RAM. Como o sistema operacional terá que liberar o cache de disco a cada si , o tempo de vida do cache extra que o swap fornece é muito baixo para ser útil de qualquer maneira. O resultado é que você está usando a largura de banda do disco para armazenar o cache que provavelmente não será usado e pausando seus 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 si e atividade ocasional. 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 que "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 contornar isso o kernel coloca as páginas no swap mais ou menos aleatoriamente e as páginas que não são necessárias ficam lá. O problema desse algoritmo é que as páginas precisam ir para a troca para saber se são necessárias para os aplicativos. E isso significa que muitas páginas "quentes" irão para a troca. O problema com isso é que os discos são muito lentos em comparação com a RAM.

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

Vou um pouco mais longe sobre isso: entendo que swap não é para processamento. As trocas são apenas para emergências. Aqueles momentos em que muitos aplicativos estão sendo executados ao mesmo tempo e você obtém um pico de memória. Sem swap, 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 eu penso. É claro que meus aplicativos têm excelente gerenciamento de memória por conta própria.

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

Se você gostaria de saber quais processos especificamente estão usando quanto swap, 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 também acrescentar que o tmpfs também será trocado. Isso é mais comum em sistemas linux modernos usando systemd que criam sobreposições /tmp de espaço de usuário usando tmpfs.

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

No mundo do DBA, o consenso parece ser que "É senso comum que quando você está executando o MySQL (ou realmente qualquer outro DBMS) você não deseja ver nenhuma E/S em seu espaço de troca. Dimensionando 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? Isso é exatamente o que me propus a investigar. "

Espero que os leitores encontrem os seguintes links apropriados.

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/