Como desativar completamente a troca?

Estou usando o Debian sid, disco rígido formatado com ext4, rodando no linux 3.1

Lembro-me de versões anteriores do Linux (talvez antes da 3.0), se eu ficar sem memória e a troca não estiver ativada, os programas geralmente travam. Isso é perfeito para o meu ambiente: navegação na web simples, sem operações críticas. Ou seja, se eu acidentalmente encontrar um site ruim que consome muita memória, ele simplesmente trava sem tornar meu terminal inutilizável.

Mas, na minha configuração atual, o computador trava com uma violenta taxa de transferência de E / S em segundo plano. O iotop revela que o kswapd0 é o culpado, o que significa que é devido à troca. Depois de usar swapon -spara determinar quaisquer trocas ativadas, eu costumava swapoff -adesativar todas as trocas e swapon -snovamente para confirmar que todas as trocas foram desativadas.

Depois tentei maximizar meu uso de memória novamente. Infelizmente, o comportamento que eu esperava não aconteceu. Em vez disso, o kswapd0 tenta repetidamente trocar a RAM e falha porque não há espaço de troca. Como ele nunca desiste, meu computador está bloqueado pelo congelamento eterno de E / S, prejudicial à saúde do meu disco.

Estou fazendo algo errado ao tentar swapoff -a? Por que o comportamento é diferente do que costumava ser (provavelmente antes da versão 3.0)?

Desabilitar a troca não fará o que você deseja. Você ainda terá uma taxa de transferência de E / S violenta, mas será de páginas limpas, e não de páginas sujas.

Sem troca, o sistema compactará o cache de páginas limpas (não modificadas) para quase zero, porque essas são as únicas páginas que podem ser removidas da memória física. Ele só pode despejar páginas sujas (modificadas) da memória gravando-as para troca, sem troca, não tem como despejar páginas sujas.

Conforme você fica com pouca memória física, cada processo precisará carregar suas páginas de código do disco, pois despeja as páginas de código anteriores do processo. O resultado será uma violenta debulha e trabalho excessivo realizado pelo subsistema de permuta.

Este é um caso especial de um princípio muito importante: para um sistema bem projetado, você não pode fazê-lo funcionar melhor reduzindo suas opções. Linux é um sistema bem projetado. Remover a troca apenas oferece menos opções, portanto, não é de surpreender que se comporte pior.

Uma solução melhor do que desativar a troca, que na melhor das hipóteses causa a morte de processos aleatórios quando a memória está baixa, é definir o limite por segmento de dados por processo para processos que retiram coisas da rede. Dessa forma, um navegador descontrolado atinge o limite e morre, em vez de fazer com que todo o sistema se torne inutilizável. Exemplo, a partir do shell

(ulimit -d 400000; firefox) &

O número após -d está em kilobytes. Você deve experimentar isso no seu sistema para escolher o melhor valor para seus hábitos de navegação. Os parênteses fazem com que um subshell seja criado; o comando ulimit afeta apenas esse shell e seus filhos, isolando seus efeitos do shell pai.

Para garantir que a troca não seja usada, é melhor evitar que qualquer troca seja adicionada na inicialização. Isso pode ser feito, dependendo do sistema, desativando o swapserviço de inicialização ou apenas comentando a entrada de troca /etc/fstab.

No que diz respeito ao seu hangup, a stop()função in /etc/init.d/swappode fornecer uma pista:

stop()
{
       ebegin "Deactivating swap devices"

       # Try to unmount all tmpfs filesystems not in use, else a deadlock may
       # occure. As $RC_SVCDIR may also be tmpfs we cd to it to lock it
       cd "$RC_SVCDIR"
       umount -a -t tmpfs 2>/dev/null

       case "$RC_UNAME" in
               NetBSD|OpenBSD) swapctl -U -t noblk >/dev/null;;
               *)              swapoff -a >/dev/null;;
       esac
       eend 0
}

Observe a parte sobre impasse . Você pode tentar fazer isso umount -a -t tmpfssozinho antes de desativar a troca.

Editar:

Provavelmente, você também pode atingir seu objetivo modificando as sysctlconfigurações (consulte esta pergunta ).

É melhor comentar a entrada da partição swap do /etc/fstabque executar swapoff -aapós cada inicialização.

Eu tenho o mesmo problema com o kswapd0 no meu hardware.

O vm.swappinessparâmetro do sistema de ajuste não ajuda para mim.

sysctl -w vm.swappiness=0

Pesquisei no Google e li muitas postagens, listas de discussão e agora acho que isso é bug do kernel.

Quando não há partição de troca ativa e a memória livre fica menor que um limite (cerca de 300 MB no meu caso), o sistema não responde devido à loucura do kswapd0.

Provavelmente é reproduzido com configurações e condições especiais.

Para alguém, isso é resolvido com a reinstalação do sistema com o particionamento de outros, criando o kernel personalizado com kswapd0desativado.

No meu sistema (debian sid 15/11/2016), fiz o seguinte:

1. desative a troca agora:

   swapoff -a
   

2. comente a linha com a partição swap no / etc / fstab

   #### #UUID=c6ddbc95-3bb5-49e1-ab25-b1c505e5360c none            swap    sw              0       0
   

3. desative a montagem do swap no systemd:

   systemctl --type swap
   systemctl stop dev-sda6.swap
   systemctl mask dev-sda6.swap
   

Seria suficiente. Há referência da troca no /etc/initramfs-tools/conf.d/resumearquivo. Não sei qual é o propósito disso. Talvez esse arquivo seja um problema na próxima reinicialização (ainda não tento reiniciá-lo, meu tempo de atividade é precioso;)).

o computador trava com uma violenta taxa de transferência de E / S em segundo plano. iotop revela que o kswapd0 é o culpado

Eu encontrei uma maneira (até agora) de evitar isso. Se você quiser testá-lo e ver como ele faz em seu sistema, consulte o patch do kernel dentro esta questão . Basicamente, ele não despeja Active(file)páginas (pelo menos) quando está sob pressão da memória, portanto, o thrashing do disco (leitura constante) é reduzido a quase nada e o OOM-killer pode ser acionado em 1 segundo, em vez de congelar o sistema operacional pelo que parece como permanentemente (ou pelo menos por muitos minutos). Espero que programadores reais (dos quais não sou) melhorem o patch e o transformem em uma solução real, agora que eles vêem que o que ele faz está funcionando para essas situações.