[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.

0 0

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



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.

0 0

[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.

1 0

[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.

0 0

[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:



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.

1 0

[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.

0 0