UNODATA · Cloud for Humans

18 de maio de 2026 · 5 min de leitura

Melhorias no swap do Linux: o que muda na prática para sysadmins

Melhorias no swap do Linux: como swap tables, swap_ops e otimizações para SSD afetam desempenho e troubleshooting na prática de quem administra produção.

Administrador de sistemas em frente a dois monitores exibindo gráficos de uso de memória e swap, sala de servidores com iluminação fria, expressão focada em análise de logs.

No meu dia a dia como analista de suporte na UNODATA, vejo sistemas entrarem em swap em momentos inesperados. Quando a memória RAM acaba, o kernel move páginas anônimas para disco e o desempenho despenca. Essa realidade mudou pouco nos últimos anos, até que o subsistema de swap voltou a receber atenção séria dos desenvolvedores.

O Linux Storage, Filesystem, Memory Management and BPF Summit de 2026 dedicou três sessões ao tema. Duas focaram em performance e manutenibilidade do código. A terceira, compartilhada com a trilha de armazenamento, tratou de tornar o swap mais amigável a dispositivos de estado sólido. Essas discussões não são apenas teóricas. Elas afetam diretamente quem precisa diagnosticar lentidão em produção.

Eu acompanhei os resumos publicados na LWN e refleti sobre como essas mudanças chegariam aos kernels que usamos em nossos clientes. A aposta é que o swap deixe de ser um recurso secundário e passe a funcionar de forma mais previsível em hardware moderno.

O papel atual do swap em cargas de trabalho reais

Em ambientes com contêineres e bancos de dados, a pressão de memória aparece rápido. O swap tradicional grava páginas inteiras no disco sem muita inteligência sobre o tipo de dado. Isso gera latência alta quando o sistema precisa trazer a página de volta.

No meu time já lidamos com casos em que um único processo consumia memória anônima e forçava swap agressivo. O resultado era fila de I/O no disco e tempo de resposta acima de dois segundos. Ferramentas como vmstat e sar ajudavam a identificar o sintoma, mas o root cause ficava no kernel.

As sessões do summit mostraram que o subsistema precisa evoluir para separar melhor as responsabilidades. Em vez de uma única camada de código cuidando de tudo, surgem estruturas mais modulares que permitem otimizações específicas.

Novas estruturas: swap tables e swap_ops

Uma das propostas mais interessantes é o uso de swap tables. Elas substituem parte da lógica atual de gerenciamento de slots no dispositivo de swap. A ideia é permitir buscas e atualizações mais rápidas sem percorrer longas listas ligadas.

Outra mudança relevante é a introdução de swap_ops. Essa interface permite que diferentes backends de swap registrem suas próprias operações. Em vez de o kernel assumir que todo dispositivo de swap se comporta como um disco comum, cada implementação pode declarar como quer receber e entregar páginas.

No dia a dia isso significa que poderemos ter backends otimizados para diferentes tipos de armazenamento sem alterar o restante do gerenciador de memória. Para quem faz troubleshooting, a visibilidade melhora porque as métricas podem vir diretamente do backend.

  • Redução de travas globais durante operações de swap
  • Possibilidade de priorizar páginas por tipo de workload
  • Logs mais detalhados sobre decisões de paginação
  • Menor overhead em arquiteturas com muitos núcleos

Swap amigável a SSDs

A sessão conjunta com a trilha de armazenamento tratou de um ponto prático: SSDs não gostam de escritas aleatórias pequenas. O swap tradicional gera exatamente esse padrão quando páginas são trocadas de forma individual.

As propostas incluem agrupar páginas antes de gravar e usar comandos de trim de forma mais inteligente. O objetivo é reduzir amplificação de escrita e aumentar a vida útil do dispositivo. Em nossos ambientes de nuvem, onde muitos servidores usam NVMe, essa mudança pode baixar a latência percebida em cenários de memória pressionada.

O swap deixou de ser um mecanismo de último recurso para se tornar uma ferramenta que o kernel pode usar de forma controlada.

Testes preliminares mostrados no summit indicam ganhos de até 30% em latência de paginação quando o agrupamento é ativado. Ainda falta validar em kernels estáveis, mas o caminho parece promissor.

O que muda para quem opera sistemas em produção

Como analista de suporte, minha preocupação imediata é saber quando essas alterações chegam aos kernels de distribuições enterprise. A recomendação atual é acompanhar os patches em linux-next e testar em ambientes de homologação com cargas que simulam memória escassa.

Métricas que já monitoramos, como swappiness e uso de swap por processo, continuam úteis. Elas só ganham contexto adicional quando o kernel passa a expor mais detalhes sobre as decisões internas.

A evolução do subsistema de swap mostra que o Linux continua investindo em áreas que pareciam esquecidas. Para quem resolve problemas reais de desempenho, isso é notícia boa.

Perguntas frequentes

O que são swap tables no contexto do kernel?

Swap tables são estruturas propostas para substituir parte da lógica atual de gerenciamento de slots no dispositivo de swap, permitindo buscas e atualizações mais rápidas.

Como swap_ops melhora a manutenibilidade?

Swap_ops define uma interface que permite diferentes backends registrarem suas operações específicas, reduzindo acoplamento no código principal do gerenciador de memória.

SSDs realmente se beneficiam dessas mudanças?

Sim. O agrupamento de páginas antes da escrita e o uso mais inteligente de trim reduzem escritas aleatórias pequenas, que são prejudiciais à vida útil e ao desempenho de SSDs.

Devo alterar a configuração de swappiness agora?

Ainda não. Aguarde a chegada dessas funcionalidades em kernels estáveis de distribuições enterprise e teste em ambiente controlado antes de ajustar parâmetros.

achou útil? compartilha. ou nos diga se não achou

WhatsApp LinkedIn Facebook

esse texto te ajudou?

continuar lendo

linux-kernel · swap · performance · sysadmin · ssd