Olá a todos!
Hoje vou falar-vos de algo que pode literalmente salvar a vossa carteira de uma factura de memória RAM que mais parece um assalto à mão armada. E sim, estou a falar dos preços completamente ridículos que a RAM atingiu nos últimos meses. Se achavam que as criptomoedas eram más para os preços de hardware, esperem até notarem o que a IA está a fazer ao mercado de memória.
Mas antes de começar a chorar sobre os preços (que já lá vamos), deixem-me apresentar-vos o KSM – Kernel Same-page Merging. É uma funcionalidade do kernel Linux que pode reduzir drasticamente o consumo de RAM em ambientes de virtualização. E não, não é voodoo, embora os resultados quase pareçam.
A Realidade Brutal: RAM Está Mais Cara Que Ouro (Literalmente)
Vamos começar pela realidade dolorosa. Os preços de RAM aumentaram 171,8% ano-a-ano no terceiro trimestre de 2025. Deixem isto assentar por um momento. Estamos a falar de aumentos que ultrapassam a subida do preço do ouro. Um kit de DDR5 de 32GB que custava 95€ em maio de 2025 agora custa facilmente 300€ ou mais. Vi relatos de kits de 64GB DDR5 a custarem mais que uma PlayStation 5.
A causa? A corrida da IA. Empresas como Microsoft, NVIDIA, Meta e Amazon estão a absorver capacidade de produção de DRAM como se não houvesse amanhã. A produção de HBM (High Bandwidth Memory) para aceleradores de IA está a sugar recursos de fabrico que antes iam para DDR5 convencional. E os fabricantes – Samsung, SK Hynix, Micron – não têm incentivo nenhum para baixar preços quando estão a lucrar como nunca. A Micron chegou ao ponto de fechar divisões de vendas ao consumidor precisamente porque deixaram de ter necessidade dela para absorver produção.
Segundo especialistas da indústria, esta situação vai durar pelo menos até finais de 2027. Sim, leram bem. Dois anos ou mais desta “##!”!$#”%$!”#. Para quem gere homelabs ou pequenas empresas com virtualização, isto é catastrófico.
Enter KSM: A Solução Que Já Está no Vosso Kernel
Aqui entra o KSM. Esta funcionalidade foi originalmente desenvolvida pela Red Hat para uso com KVM (daí o nome inicial “Kernel Shared Memory”), e foi integrada no kernel Linux desde a versão 2.6.32 lá em 2009. Portanto, não é tecnologia nova – é tecnologia testada e comprovada que simplesmente muita gente não usa.
O conceito é elegante: o KSM faz scan a memória física à procura de páginas com conteúdo idêntico. Quando encontra páginas duplicadas, redireciona todas as referências para uma única cópia física e liberta as restantes. O processo ocorre através do mecanismo “copy-on-write” do kernel – se algum processo tentar escrever numa página partilhada, o kernel automaticamente cria uma cópia privada para esse processo.
Pensem nisto: se têm 5 VMs a correr RockyLinux, Ubuntu, etc, todas elas têm carregadas em memória as mesmas bibliotecas do sistema, os mesmos binários, potencialmente até os mesmos dados de aplicações. Sem KSM, estão a manter 5 cópias idênticas de tudo isto. Com KSM, mantêm uma única cópia partilhada.
Os Números Não Mentem: Casos Reais de Uso
A Red Hat publicou testes onde conseguiram correr 52 máquinas virtuais Windows 10 com 4GB de RAM cada numa máquina física com apenas 32GB de RAM. Sim, 44GB de RAM alocada a correr em 32GB físicos. Isto é um rácio de overcommit bastante apreciavel. Sim eu sei que estamos a falar de Windows 10. O mesmo consegue-se com Windows 11 ou com o nosso amado Linux.
No meu próprio homelab, estou a correr atualmente cerca de 17 VMs (mix de RockyLinux, openSUSE, e algumas Alpine Linux para containers específicos). Antes de ativar o KSM, o consumo de RAM estava nos 78GB. Depois de ativar e deixar o KSM fazer o seu trabalho durante uns dias, estabilizou nos 37GB. Poupei 41GB de RAM – quase 48% de redução.
Para PMEs, os ganhos podem ser ainda maiores. Se têm 20-30 VMs a correr aplicações similares (digamos, várias instâncias de servidores web com NGINX, bases de dados PostgreSQL, etc.), as poupanças podem facilmente atingir os 50-60% do consumo total de RAM.
Como Ativar KSM: O Guia Prático
Vamos ao que interessa. Primeiro, verificar se o vosso kernel suporta KSM:
ls -la /sys/kernel/mm/ksm/
Se virem um diretório com vários ficheiros (run, pages_to_scan, sleep_millisecs, etc.), estão prontos. Se não, o vosso kernel não foi compilado com suporte para KSM – algo bastante raro em distribuições modernas.
Ativar o KSM:
echo 1 | sudo tee /sys/kernel/mm/ksm/run
E é simples assim. O KSM está agora ativo. Mas atenção – com as configurações default, o KSM é bastante conservador e pode não dar os melhores resultados.
Otimizar as configurações:
# Aumentar número de páginas escaneadas por ciclo
echo 1000 | sudo tee /sys/kernel/mm/ksm/pages_to_scan
# Reduzir tempo entre scans (em milissegundos)
echo 100 | sudo tee /sys/kernel/mm/ksm/sleep_millisecs
Estas configurações fazem o KSM trabalhar mais agressivamente. O pages_to_scan controla quantas páginas são examinadas em cada passagem, e o sleep_millisecs define o tempo de espera entre passagens. Valores mais baixos significam scans mais frequentes e maior uso de CPU, mas também maior eficiência na dedupliacação.
Tornar as mudanças persistentes:
Editem /etc/rc.local (ou criem um systemd service caso o vosso sistema não traga um systemd file de origem) e adicionem:
#!/bin/bash
echo 1 > /sys/kernel/mm/ksm/run
echo 1000 > /sys/kernel/mm/ksm/pages_to_scan
echo 100 > /sys/kernel/mm/ksm/sleep_millisecs
Para utilizadores de Proxmox VE:
Boa notícia – o KSM vem ativado por default no Proxmox. Mas podem otimizar per-VM se necessário:
# Desativar KSM para uma VM específica
qm set <vmid> --memory-merge 0
Isto é útil para VMs com cargas de trabalho sensíveis a latência ou onde não querem partilha de memória por razões de segurança.
Monitorizar o KSM: Saber Se Está a Funcionar
De nada vale ativar o KSM se não conseguimos medir o seu impacto. Felizmente, o kernel expõe métricas úteis:
# Ver estatísticas do KSM
grep -H '' /sys/kernel/mm/ksm/* 2>/dev/null
Os valores mais importantes:
- pages_shared: Número de páginas únicas partilhadas
- pages_sharing: Número total de páginas que apontam para páginas partilhadas
- pages_unshared: Páginas que foram escaneadas mas são únicas
- full_scans: Número de scans completos realizados
A métrica mágica é: (pages_sharing - pages_shared) * 4KB = memória poupada.
Se pages_sharing é muito maior que pages_shared, estão a poupar RAM. Se ambos são zero ou muito baixos, algo está errado – possivelmente as VMs não estão a marcar a memória como “mergeable”.
Script útil para monitoring contínuo:
#!/bin/bash
while true; do
shared=$(cat /sys/kernel/mm/ksm/pages_shared)
sharing=$(cat /sys/kernel/mm/ksm/pages_sharing)
saved=$((($sharing - $shared) * 4 / 1024))
echo "$(date): Saved ${saved}MB"
sleep 60
done
Os Tradeoffs: Não Estavam á Espera Que Não Houvessem Pois Não?
Como tudo na vida, o KSM tem custos. O principal é carga no CPU. O daemon ksmd está constantemente a fazer scans memória, a calcular hashes, a comparar páginas. Em sistemas com muita RAM, isto pode consumir 5-10% de um core de CPU continuamente.
Outro aspeto é latência. Quando uma página partilhada precisa de ser copiada (copy-on-write), há uma penalização de performance. Para aplicações extremamente latency-sensitive (trading de alta frequência, sistemas de controlo em tempo real), isto pode eventualmente ser problemático.
E há considerações de segurança. KSM pode ser explorado para side-channel attacks. Se estão a fornecer hosting para terceiros ou a correr workloads de diferentes níveis de sensibilidade no mesmo host, podem querer desativar o KSM ou pelo menos evitar merging entre NUMA nodes diferentes.
O kernel desde a versão 7 do RHEL é NUMA-aware, o que ajuda. Podem evitar cross-node merging com:
echo 0 | sudo tee /sys/kernel/mm/ksm/merge_across_nodes
Casos de Uso Ideais Para KSM
Desde que comecei a fazer a pesquisa para este post, tenho notado que o KSM brilha em cenários específicos:
- Homelabs com múltiplas VMs similares Se correm 5-10 VMs todas baseadas na mesma distribuição Linux, KSM é ouro. Todas partilham libc, systemd, kernel modules, etc.
- Ambientes de desenvolvimento/teste Equipas que sobem e destroem VMs constantemente beneficiam imenso. Cada nova VM partilha imediatamente páginas com as existentes.
- Hosting de aplicações web idênticas Se têm 20 instâncias de WordPress ou Django a correr em VMs separadas, o KSM vai ter the best day ever com toda a duplicação.
- PMEs com orçamento apertado Quando não podem dar-se ao luxo de comprar 128GB de RAM a preços de ouro, o KSM permite fazer mais com menos.
Onde NÃO usar KSM:
- Workloads latency-critical
- Ambientes multi-tenant com requisitos de segurança elevados
- Sistemas com abundância de RAM livre (não vale o overhead de CPU)
- VMs com dados únicos que mudam constantemente
A Realidade Prática: A minha realidade:
Em cada um dos meu servidores de homelab (sistemas AMD EPYC Genoa com >196GB de RAM), corro:
- 9x Rocky Linux 9 (distribuídos entre web servers com NGINX + PHP-FPM, aplicações web especializadas, reverse proxies, WAF’s e diversas stacks aplicacionais)
- 2x BSD (OPNsense para firewall, IDS/IPS com Suricata, CrowdSec, e gestão de rede)
- 6x openSUSE Leap (servidores de automatismos com Ansible/automation stacks, aplicações containerizadas com Docker, , e workloads diversos)
Com KSM otimizado (pages_to_scan=5000, sleep_millisecs=40), estou a poupar consistentemente 41GB de RAM. Isto permitiu-me adicionar mais recursos para serem consumidos pelos processos aplicacionais sem ter de comprar RAM adicional – o que neste momento significaria gastar 800-1200€ (na altura que estou a escrever este post) por mais 128GB de RAM ECC para EPYC.
O overhead de CPU é negligível no meu caso – o ksmd consome consistentemente 2-3% de um core dos múltiplos cores disponíveis no EPYC, algo perfeitamente aceitável dado o ganho substancial de memória e a capacidade de processamento disponível.
Ferramentas Auxiliares: ksmtuned
A Red Hat desenvolveu ainda o ksmtuned, um daemon que ajusta automaticamente os parâmetros do KSM baseado em condições do sistema. É particularmente útil em ambientes dinâmicos.
Instalar (em sistemas baseados em RHEL/CentOS):
yum install ksmtuned
systemctl enable ksmtuned
systemctl start ksmtuned
O ksmtuned monitoriza o sistema e ajusta pages_to_scan e sleep_millisecs automaticamente. Quando há muita RAM livre, relaxa. Quando a pressão de memória aumenta, torna-se mais agressivo.
Para outras distros, podem criar lógica similar com scripts bash e cron jobs, monitorizando /proc/meminfo e ajustando parâmetros do KSM conforme necessário.
O Contexto Mais Amplo: Estratégias de Sobrevivência
O KSM é apenas uma ferramenta numa estratégia maior para sobreviver a esta crise de preços de RAM. Outras táticas que recomendo:
- Usar containers em vez de VMs quando possível LXC ou Docker containers partilham o kernel do host, eliminando duplicação massiva de memória.
- Otimizar aplicações Rever configurações de aplicações. Esse MySQL precisa mesmo de um buffer pool de 8GB? Esse Java application precisa de -Xmx4g? /me olha para o meu graylog a gritar de dor :X
- Implementar swap inteligente Com SSDs NVMe decentes, swap bem configurada pode ser uma válvula de escape. Não é ideal, mas é melhor que não conseguir correr aplicações. Já fiz isso no passado em outra altura de pico do custo da RAM (creio que em 2014, mas se procurarem no blog, fiz um artigo sobre isso na altura).
O Futuro: Quando Isto Acaba?
A má notícia? Especialistas dizem que os preços vão continuar elevados até pelo menos Q4 2027. A produção de HBM para IA não vai abrandar tão cedo. Samsung, SK Hynix e Micron estão a construir novas fabs, mas levam anos até estarem operacionais.A boa notícia? Tecnologias como KSM tornam-se cada vez mais relevantes. O kernel Linux continua a evoluir – a versão 6.7 trouxe “smart scan”, uma otimização que reduz scanning de páginas únicas em 10-20%, baixando overhead de CPU.
Há também desenvolvimentos interessantes em “partitioned KSM” – para os velhos aqui, tem a ver com tecnologia de outras épocas em que existiam fabricantes de Unix empresarial – e outros mecanismos mais granulares de controlo. O futuro pode trazer KSM ainda mais eficiente e seguro.
Conclusão: Adaptar ou Morrer (Financeiramente)
Neste momento, com RAM a custar o equivalente ao PIB de um país pequeno, ferramentas como KSM deixaram de ser “nice to have” e passaram a ser essenciais. Para homelabbers e PMEs, a diferença entre ativar KSM e não ativar pode ser literal mente poder adicionar mais serviços ao vosso ambiente ou ter de gastar centenas de euros em RAM nova.
Sim, como em tudo existem tradeoffs. Sim, requer algum tuning. Mas comparado com pagar 400€ por 64GB de DDR4 ou ainda mais por DDR5, eu diria que vale bem a pena passar umas horas a optimizar configurações.
E a verdade é esta: se não começarem a usar ferramentas como KSM, a alternativa é pagar preços completamente insanos ou simplesmente não conseguirem escalar os vossos ambientes. Para mim, a escolha é óbvia.
Portanto, se ainda não ativaram o KSM no vosso ambiente de virtualização, façam isso hoje. Monitorizem durante uma semana. Ajustem conforme necessário. Vão-me agradecer quando virem a RAM que pouparam – RAM que não tiveram de comprar a preços de ouro.
Até ao próximo post, e lembrem-se: numa crise, quem se adapta sobrevive. Perguntem aos crocodilos que sobreviveram a todos os eventos de extinção em massa do planeta. E neste caso, adaptar-se significa espremer até ao último byte das vossas máquinas.
Abraço, Nuno
P.S.: Se experimentarem o KSM e conseguirem métricas interessantes, partilhem nos comentários. Adoro ver casos reais de uso e números concretos. E se encontrarem configurações que funcionam particularmente bem para vossos workloads, a comunidade agradece!
P.P.S: Sim, estou a escrever isto enquanto olho para o registo do Keepa dos preços de RAM na Amazon e a pensar…. irra!