Conciliando o uso da ZRAM e SWAP em disco na sua máquina

Nesse artigo vou explicar o que é ZRAM e como habilitá-la no seu sistema e como conciliar o uso da ZRAM com a SWAP em disco.

[ Hits: 1.717 ]

Por: Sidnei Serra em 01/09/2025 | Blog: https://www.youtube.com/channel/UCRgokKtNlttdmg2RJEa2VYw


Criando arquivo de SWAP e limpando RAM e SWAP depois de uso intenso



Uma SWAP em arquivo é bem mais prática do que a de partição pois podemos apagar e criar à vontade de acordo com as necessidades. Para criar a SWAP em arquivo siga os comandos abaixo (SWAP em arquivo de 2GB):

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Para montar no boot da máquina, coloque no /etc/fstab (atenção à prioridade):

/swapfile none swap sw,pri=20 0 0

Assim você escolhe se quer apagar a SWAP em partição para usar a de arquivo, se quer desativar a ZRAM e só usar a SWAP em arquivo ou mesmo usar as duas formas de SWAP. Acredito que o uso das duas é o modo mais equilibrado para quem tem até 8GB de RAM e quase obrigatório para quem tem menos de 4GB.
Só mais uma coisa, a SWAP em disco NÃO É compactada, isso é característica da ZRAM.

Para limpar a ZRAM e a SWAP depois de um uso intenso, crie o script limpaswap.sh, coloque o conteúdo abaixo, salve o arquivo e dê o chmod +x para o arquivo. Para executar a limpeza, basta digitar no Terminal ./limpaswap.sh:
########################################################################
#!/bin/bash
#limpa_swap.sh - Esvazia a swap, a RAM e reativa o zramswap

echo "Desativando swap..."
sudo swapoff -a

echo "Reiniciando zramswap..."
sudo systemctl restart zramswap.service

echo "Reativando demais swaps (se houver)..."
sudo swapon -a

echo "Limpando caches de RAM..."
sync
echo 3 | sudo tee /proc/sys/vm/drop_caches > /dev/null

echo "Swaps reativadas e limpas, inclusive a RAM."
####################################################################

Página anterior    

Páginas do artigo
   1. O quê é SWAP em disco e configurando-a mais adequadamente
   2. O quê é ZRAM SWAP e configurando-a mais adequadamente
   3. Conciliando o uso da ZRAM e SWAP em disco na sua máquina
   4. Criando arquivo de SWAP e limpando RAM e SWAP depois de uso intenso
Outros artigos deste autor

Mitigação - O que é e quando é "seguro" desabilitar

Máquina perereca - até onde é possível o uso de Linux?

Comparação entre os escalonadores BFQ e MQ-Deadline (acesso a disco) no Arch e Debian

O que é o THP na configuração de RAM do Linux e quando desabilitá-lo

Leitura recomendada

AIXGL + Beryl no Kubuntu 6.10 com uma Intel i810

Servidor VPN PPTP com autenticação de usuários no Active Directory

Instalando MariaDB no Debian e Ubuntu

Como ativar o módulo de cancelamento de ruído no Pipewire

Eclipse integrado com Tomcat 5 no Ubuntu

  
Comentários
[1] Comentário enviado por morvan em 26/09/2025 - 23:39h

Muito bom artigo. No Fedora, não precisei manipular nenhum arquivo .conf, senão emitir o comando:

'dnf remove zram-generator zram-generator-defaults' e reiniciar.

Como meu Swap é totalmente sobre SSD, dupliquei o tamanho da partição a ele destinada, vez que o tempo de acesso, comparando com dispositivos de estado móvel, é bem mais vantajoso.
Ao desabilitar a ZRam, além do ganho geral, percebi uma melhora substancial no acesso ao cache (para terem uma ideia: tenho WhatsApp corporativo; centenas de hits diários; o WA conseguiu rever os caches visivelmente mais rápido).

Morvan, Usuário GNU-Linux #433640. Seja Legal; seja Livre. Use GNU-Linux.

[2] Comentário enviado por coelhoposa em 29/09/2025 - 17:07h


Essa configuração diz "mais ou menos" ao sistema que quando a memória RAM estiver 80% usada é para começar a usar a SWAP - no caso, em disco.


Isso está incorreto. O que o "vm.swappness" faz é definir o quão agressivo será o uso da Swap: Quanto mais baixo o valor, mais o sistema irá evitar de usar a Swap e quanto mais alto o valor, mais o sistema irá usar a Swap. É basicamente sobre isso, não tem nada a ver com o "uso de memória RAM". Tem mais sobre isso, aqui:
- https://www.techtarget.com/searchdatacenter/definition/Linux-swappiness
- https://www.howtogeek.com/449691/what-is-swapiness-on-linux-and-how-to-change-it/
- https://github.com/torvalds/linux/blob/v6.2/mm/vmscan.c#L3000-L3014

E além disso, esse parâmetro pode ser ajustado com valores que vão de 0 a 200, e isso é desde o Kernel 5.8, lançado em Agosto de 2020. Ou seja, não dá nem pra confundir que o parâmetro equivale a RAM usada, já faz cinco anos.

[3] Comentário enviado por Zoiudo em 29/09/2025 - 17:26h

Por isso que eu coloquei "diz mais ou menos ao sistema" como forma de explicar bem por alto como funciona o parâmetro, eu sei que o swappness controla a questão do sistema usar mais agressivamente a troca de páginas na swap e não tem nada a ver com uso de memória RAM. Já o lance de valores maiores que 100 obrigado pela informação, confundi com a a prioridade de uso da ZRAM e/ou da SWAP em disco e que também não é de 0 a 100 mas convencionou-se "mais ou menos" por esse valor nos scripts. Aliás os desenvolvedores deveriam parametrar as variáveis de certas configurações para algo mais "medível" como 0 a 100 pois já é costume da gente saber que 50 é a metade, por exemplo. Imagine o kernel aceitar valores entre –1 a 32767 para configurar uma coisa, é phodz, hehehe...

Em todo caso, a prioridade da ZRAM/swap, por exemplo, é mais para ordenar as prioridades de uso das mesmas.


[2] Comentário enviado por coelhoposa em 29/09/2025 - 17:07h


Essa configuração diz "mais ou menos" ao sistema que quando a memória RAM estiver 80% usada é para começar a usar a SWAP - no caso, em disco.


Isso está incorreto. O que o "vm.swappness" faz é definir o quão agressivo será o uso da Swap: Quanto mais baixo o valor, mais o sistema irá evitar de usar a Swap e quanto mais alto o valor, mais o sistema irá usar a Swap. É basicamente sobre isso, não tem nada a ver com o "uso de memória RAM". Tem mais sobre isso, aqui:
- https://www.techtarget.com/searchdatacenter/definition/Linux-swappiness
- https://www.howtogeek.com/449691/what-is-swapiness-on-linux-and-how-to-change-it/
- https://github.com/torvalds/linux/blob/v6.2/mm/vmscan.c#L3000-L3014

E além disso, esse parâmetro pode ser ajustado com valores que vão de 0 a 200, e isso é desde o Kernel 5.8, lançado em Agosto de 2020. Ou seja, não dá nem pra confundir que o parâmetro equivale a RAM usada, já faz cinco anos.



[4] Comentário enviado por coelhoposa em 29/09/2025 - 19:24h

O vm.swappness já foi de 0 a 100 e, em 2020, isso mudou. O Hardware que usamos mudou. Os computadores não vem mais com aqueles HDDs lentos, onde um "vm.swappness" de 60 seria o ideal, mais sim com SSDs muito mais rápidos, onde um "vm.swappness" mais alto pode ser mais benéfico.

E colocar isso como "mais ou menos ao sistema", com uma porcentagem de RAM que, desde 2020, não corresponde na realidade é tornar a explicação incorreta. Só quis apontar essa questão do "vm.swappness", pois eu vejo muita gente errando nisso e passando informação errada, colocando esse parâmetro como se fosse "Ah, o sistema só vai usar a Swap quando ele chegar em tal porcentagem da RAM usada", quando ele não é isso.

E os parâmetros devem ser usados como eles deveriam ser usados, e essas "convenções" que vem de anos e anos, podem estar incorretas, desatualizadas ou não usando aquele parâmetro da melhor forma.

Por exemplo, a zRAM pode ser melhor aproveitada com um "vm.swappness" com valores acima de 100, pois a RAM é muito mais rápida, e isso é conforme a documentação do Kernel (https://docs.kernel.org/admin-guide/sysctl/vm.html); na documentação do Kernel, o "vm.swappness" é colocado como um "custo" de IO para se usar a Swap; com algumas pessoas usando em 180, para aproveitar que a RAM é ordens de magnitude mais rápida do que qualquer armazenamento.


[3] Comentário enviado por Zoiudo em 29/09/2025 - 17:26h

Por isso que eu coloquei "diz mais ou menos ao sistema" como forma de explicar bem por alto como funciona o parâmetro, eu sei que o swappness controla a questão do sistema usar mais agressivamente a troca de páginas na swap e não tem nada a ver com uso de memória RAM. Já o lance de valores maiores que 100 obrigado pela informação, confundi com a a prioridade de uso da ZRAM e/ou da SWAP em disco e que também não é de 0 a 100 mas convencionou-se "mais ou menos" por esse valor nos scripts. Aliás os desenvolvedores deveriam parametrar as variáveis de certas configurações para algo mais "medível" como 0 a 100 pois já é costume da gente saber que 50 é a metade, por exemplo. Imagine o kernel aceitar valores entre –1 a 32767 para configurar uma coisa, é phodz, hehehe...

Em todo caso, a prioridade da ZRAM/swap, por exemplo, é mais para ordenar as prioridades de uso das mesmas.



[5] Comentário enviado por Zoiudo em 30/09/2025 - 08:52h

Realmente admito que suas observações são bastante válidas e vou ver junto aos moderadores se consigo editar as partes "nebulosas" com informações mais adequadas para o perfeito entendimento do artigo; agora vamos às minhas ponderações:

1- O fato da tecnologia ter avançado para o que temos hoje não garante que o usuário vai ter acesso às últimas tecnologias e, na maioria das vezes, as máquinas que possuem Linux instalado são basicamente aquelas "que não rodam Windows direito". Nessa situação então temos configurações que ainda rodam em discos rígidos, pouca memória RAM, processadores antigos mono ou dual core sem HT, placas-mãe sem AHCI e outros detalhes técnicos relevantes. Falo isso pois estou nesse meio, minha máquina é um Core2Duo E7400 com 2GB de RAM DDR3 em uma placa-mãe Asrock G41-VS3 (sem AHCI) e disco de 500GB de 5400 rpm e 8MB de cache e as máquinas dos telecentros que administro estão nessa base também;

2- A ZRAM compete diretamente por espaço com a memória RAM e os valores de configuração devem evitar o "empurra-empurra" de dados que eventualmente pode acontecer entre os dois recursos (RAM e ZRAM) e em máquinas muito modestas pode ocorrer isso aqui:


-- Estatísticas do ZRAM (/sys/block/zram0/mm_stat) --
Bytes originais (descomprimidos): 288 MB
Bytes comprimidos (armazenados): 51 MB
Taxa de compressão: 5.62 x
Páginas usadas: 56598528
Operações de compressão: 124723200
Operações de descompressão: 1053
Falhas de compressão: 16137
Falhas de descompressão: 121


Essas falhas na compressão/descompressão podem ser erros por dados já estarem comprimidos, problemas de memória ou o processador não consegue dar conta do trabalho necessário. Nesses casos as "recomendações dos manuais" devem ser revistas e esse artigo foi feito em cima de telecentros comunitários com máquinas montadas com sucata e que se comportam de "modo diferente" em relação às máquinas mais novas. Tem máquinas que estão usando disco IDE em vez de Sata, processadores Celeron e DDR2; as "melhores" por conta do processador tem 2GB de RAM e as mais modestas tem 4GB e nas experiências de uso valores de swappness de 60/40 com 50% da memória RAM do sistema de ZRAM, LZ4 como algoritmo e até uma prioridade baixa (20) para um eventual swapfile no disco se mostraram a melhor combinação;

3- Máquinas mais potentes com SSD/NVMe e/ou +16GB de RAM não sentem tanto o uso da ZRAM e valores como os que você citou podem funcionar muito mais do que os que eu coloquei no artigo: SSD/NVMe possuem baixa latência - muito menor do que discos mecânicos - e a RAM menos ainda, daí concordo com você em deixar a RAM "folgada" para lidar com as requisições do sistema e jogar "o que não vai precisar no momento" para a swap - no caso a ZRAM ou mesmo SWAP em disco. O que eu postei é de experiência de uso, não é de "orelhada", fruto de muita literatura técnica como essas que você citou (e que vou ler também) mas a teoria é diferente da prática.

Veja que não estou contrariado com as suas observações, muito pelo contrário: o debate serve justamente para isso - principalmente corrigir eventuais erros ou "desacertos" - e é bom ver que ainda há pessoas com esse espírito de debate e que expõem suas ideias com argumentos sem serem má-educadas, coisa rara nesse nosso mundo de TI. Vou implementar suas observações no meu dia a dia e volto com os resultados.

Mais uma vez obrigado por ser didático sem ser desrespeitoso.


[4] Comentário enviado por coelhoposa em 29/09/2025 - 19:24h

O vm.swappness já foi de 0 a 100 e, em 2020, isso mudou. O Hardware que usamos mudou. Os computadores não vem mais com aqueles HDDs lentos, onde um "vm.swappness" de 60 seria o ideal, mais sim com SSDs muito mais rápidos, onde um "vm.swappness" mais alto pode ser mais benéfico.

E colocar isso como "mais ou menos ao sistema", com uma porcentagem de RAM que, desde 2020, não corresponde na realidade é tornar a explicação incorreta. Só quis apontar essa questão do "vm.swappness", pois eu vejo muita gente errando nisso e passando informação errada, colocando esse parâmetro como se fosse "Ah, o sistema só vai usar a Swap quando ele chegar em tal porcentagem da RAM usada", quando ele não é isso.

E os parâmetros devem ser usados como eles deveriam ser usados, e essas "convenções" que vem de anos e anos, podem estar incorretas, desatualizadas ou não usando aquele parâmetro da melhor forma.

Por exemplo, a zRAM pode ser melhor aproveitada com um "vm.swappness" com valores acima de 100, pois a RAM é muito mais rápida, e isso é conforme a documentação do Kernel (https://docs.kernel.org/admin-guide/sysctl/vm.html); na documentação do Kernel, o "vm.swappness" é colocado como um "custo" de IO para se usar a Swap; com algumas pessoas usando em 180, para aproveitar que a RAM é ordens de magnitude mais rápida do que qualquer armazenamento.

[6] Comentário enviado por coelhoposa em 30/09/2025 - 19:04h

Agradeço por esclarecer melhor, e fico feliz por ter te ajudado.

E realmente, tudo é questão de caso a caso mesmo. Tem casos em que a zRAM é uma excelente ideia e que pode ser usada a vontade, e outros em que ela vai atrapalhar mais do que realmente ajudar. E tem casos em que usar um vm.swappness mais alto pode ser benéfico e outros caso que não.

E concordo com as suas ponderações. Talvez, eu não tenha levado em conta os cenários com máquinas mais fracas nos meus comentários. Não é um cenário em que eu usaria algo como uma zRAM, mas se funcionou nos seus testes e trouxe um desempenho melhor para os computadores que você cuida, pode ser uma boa ideia.

E espero os seus testes e observações. E eu que agradeço pelo bom debate.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts