Saltar para o conteúdo 
Alojamento Swap É isso que determina, no dia-a-dia, se um servidor continua a funcionar tranquilamente em caso de picos repentinos ou se fica mais lento devido à carga. Explico claramente quando é que a memória swap funciona eficazmente como buffer e a partir de que ponto começa a piorar os tempos de resposta – incluindo o planeamento do tamanho, o parâmetro «swappiness», os aspetos relacionados com E/S e a monitorização.
Pontos centrais
- Rede de segurança Em vez de uma falha do sistema, o swap dá-me tempo para reagir antes de os serviços serem encerrados.
- Libertação de memória RAM – eliminar as páginas inativas, manter a cache ativa: acesso mais rápido aos dados mais frequentes.
- Limite de desempenho – O swapp e o thrashing intensos aumentam as latências.
- Afinação fina – Um baixo nível de swappiness, Zswap/ZRAM e um armazenamento rápido reduzem a pressão de E/S.
- Monitorização – A utilização prolongada da memória swap, o elevado número de erros de página e os tempos de espera de E/S constituem sinais de alarme.
O que o swap realmente faz nos servidores Linux
Entendo «swap» como virtual Memória que transfere páginas de memória raramente utilizadas da RAM para o SSD/HDD, para que o código ativo e as caches permaneçam na memória de acesso rápido. Para tal, o kernel dá prioridade aos dados ativos na RAM e transfere as páginas inativas para a área de troca, sem encerrar imediatamente os processos. Desta forma, as aplicações que consomem muita memória funcionam em paralelo, apesar de a RAM física ser limitada. Para mais detalhes sobre o funcionamento, remeto para esta breve explicação sobre memória virtual. O importante é o seguinte: enquanto o conjunto de dados ativo couber na RAM, o impacto no tempo de resposta será reduzido e o servidor continuará a responder conforme o esperado.
Por que é que o swap ajuda no alojamento – vantagens reais
Utilizo o Swap porque ele é considerado como Tampão Evita falhas quando é necessária mais RAM a curto prazo. Sem reserva, o OOM-Killer entra em ação e encerra processos, o que interrompe abruptamente os serviços críticos. Com o swap, consigo fazer face aos picos de carga, analisar os registos e otimizar a carga antes de aumentar a RAM. Além disso, uma utilização moderada do swap aumenta a cache do sistema de ficheiros na RAM, o que acelera os acessos de leitura frequentes. A interação entre a RAM, a cache e o swap garante tempos de resposta mais uniformes, desde que o swap não se torne excessivo.
Quando é que o swap abranda e como é que posso perceber isso
Assim que um sistema intensivo Quando os dados alternam entre a RAM e a área de swap, as latências aumentam significativamente. Percebo isso quando a utilização do swap aumenta constantemente durante 10 a 15 minutos e os tempos de espera de E/S sobem. Se a isso se juntar o thrashing, o servidor passa a trabalhar principalmente com transferências de páginas em vez de carga útil – as solicitações demoram então segundos. Além disso, um valor elevado de «swappiness» provoca uma transferência desnecessária para a área de swap, mesmo que ainda haja RAM livre. Nessas fases, o gargalo desloca-se claramente para o armazenamento e a aplicação fica lenta.
Utilizar o Swappiness, o Zswap e o ZRAM de forma específica
Na maioria das vezes, considero a «swappiness» baixo, por exemplo, na faixa de 5 a 20, para que o swap só entre em ação em caso de pressão real. Desta forma, a memória ativa permanece mais tempo na RAM e a E/S mantém-se mais estável. O Zswap comprime as páginas na RAM antes de estas serem transferidas para o disco; assim, reduzo a carga de gravação e encurto os tempos de acesso. O ZRAM cria um dispositivo de RAM comprimido que entra em ação antes do swap físico, o que ajuda significativamente em pequenos VPS. Estas técnicas não substituem a RAM física, mas proporcionam-me janelas de tempo e suavizam os picos.
O tamanho adequado da área de swap por tipo de servidor
Escolho o tamanho relacionado com o contexto: adequado à carga de trabalho, à RAM e ao perfil de E/S. Os pequenos servidores web costumam necessitar de 1–2 GB para amortecer picos de carga. Os servidores de bases de dados beneficiam frequentemente de 4 a 8 GB para armazenar temporariamente consultas complexas ou cópias de segurança. Para VPS com pouca RAM, prevejo cerca de 1× a quantidade de RAM, para que os contentores não atinjam imediatamente o limite máximo durante os picos. Em grandes máquinas dedicadas, 4 a 8 GB fixos são frequentemente suficientes, uma vez que já existe RAM em abundância.
| Tipo de servidor | Tamanho da área de troca (valor orientativo) | Trocas | Nota |
|---|---|---|---|
| Servidor web (pequeno/médio) | 1–2 GB | 5-15 | Amortecer picos de carga, manter a cache na RAM |
| Servidor de base de dados | 4–8 GB | 5-10 | Armazenar em buffer os picos de consultas/backups |
| VPS com pouca memória RAM | até ~1× a RAM | 10-20 | Suportar picos de carga repentinos |
| Servidores dedicados (muita RAM) | 4–8 GB | 5-10 | Manter uma pequena reserva, evitar o «thrash» |
IO e SSDs: prolongar a vida útil, garantir o desempenho
Vou colocar o Swap em rápido e SSDs fiáveis, mas tenho o cuidado de não sobrecarregar permanentemente o desempenho de gravação. Uma carga de swap prolongada aumenta as latências e pode reduzir a vida útil da memória flash. Por isso, reduzo o Swappiness e, se necessário, ativo o Zswap para diminuir a pressão de E/S. A partir de tempos de espera de E/S superiores a cerca de 20 ms, dou prioridade às otimizações antes que os utilizadores sintam a lentidão. Se o conjunto de trabalho ultrapassar significativamente a capacidade da RAM, aumento a memória de trabalho, em vez de aumentar a área de swap.
Monitorização: Detetar precocemente os sinais de alerta
Eu controlo contínuo Acompanho a utilização da memória de swap ao longo do tempo e considero críticos os aumentos que se mantêm durante 10 a 15 minutos. Paralelamente, observo as taxas de falhas de página e a atividade do kswapd, pois isso fornece indícios precoces do início do thrashing. Latências de E/S persistentemente elevadas e filas crescentes confirmam o estrangulamento no armazenamento. Se se verificar um tráfego de swap elevado, embora haja memória RAM livre, reduzo o Swappiness e analiso as estratégias de cache. Para uma melhor compreensão dos efeitos do cache, este artigo prático sobre Cache do servidor e paginação.
Na prática: exemplos de configuração e comandos
Defino a Swappiness consciente Através do sysctl: vm.swappiness=10 limita a transferência agressiva para a memória virtual. Para o Zswap, ativo o parâmetro do kernel zswap.enabled=1 e escolho um compressor eficiente, como o zstd. Configuro o ZRAM com uma proporção de 25–50% da RAM, testo picos de carga e faço os ajustes necessários em seguida. Crio ficheiros de swap de forma flexível através do `fallocate`, atribuo direitos restritivos e ativo-os com o `swapon`. Após os ajustes, verifico o `dmesg`, o `iostat` e o `vmstat` para avaliar os efeitos nas latências e nas falhas de página.
Como interpretar corretamente as comparações de produtos de alojamento swap
Ao analisar as propostas, eu verifico exatamente, que estratégia de swap e que funções de monitorização o fornecedor disponibiliza. São relevantes valores padrão claros para a „swappiness“, métricas transparentes para as latências de E/S e percursos de atualização simples. Em caso de utilização prolongada da swap, opto por aumentar a RAM numa fase inicial, em vez de mascarar o problema com uma swap maior. Avalio afirmações como «não é necessária swap» no contexto de perfis de carga reais e do comportamento da cache. Este guia sobre a Utilização da memória swap no alojamento.
Implementação da memória virtual: partição vs. ficheiro, prioridades e distribuição
Na prática, opto por uma partição de swap ou por um ficheiro de swap consoante a flexibilidade e a facilidade de utilização. Uma Ficheiro de swap pode ser criada, ampliada ou removida rapidamente – ideal para ambientes dinâmicos e VPS. Uma Partição de swap tem uma estrutura ligeiramente mais simples e, em sistemas muito antigos, é, em parte, mais eficiente; no entanto, a diferença é insignificante nos núcleos modernos. O importante é a Definição de prioridades: Com as prioridades do swapon, determino qual o dispositivo a ser utilizado em primeiro lugar. Prioridades iguais levam à distribuição pelo conjunto de dispositivos; assim, distribuo as operações de E/S e aumente a taxa de transferência, por exemplo, quando tenho dois SSDs NVMe a funcionar em paralelo. Se os dispositivos de swap estiverem em suportes físicos diferentes, o sistema beneficia de um verdadeiro paralelismo – num único conjunto RAID, o efeito é, naturalmente, menor. No Btrfs, tenho o cuidado de colocar os ficheiros de swap em áreas NoCoW e sem instantâneos; no ZFS, prefiro utilizar um zvol em vez de um ficheiro. A questão mantém-se: planeio o swap de forma a que, em caso de necessidade, previsível e rápido responde – não que compense a falta de memória RAM.
Containers, Kubernetes e Cgroups: limitar o swap de forma seletiva
Em ambientes de contentores, utilizo o swap de forma mais restritiva. Muitas configurações do Kubernetes funcionam tradicionalmente com o swap desativado, porque o agendador beneficia de limites rígidos e pretende evitar picos de latência. Nos casos em que o swap é permitido, limito-o por carga de trabalho através de Cgroups (cgroup v2: memory.max, memory.high, memory.swap.max), definindo assim a quantidade máxima de swap que um contentor pode utilizar. Para serviços em que a latência é crítica, escolho orçamentos de swap muito baixos ou nulos e protejo-os adicionalmente com memory.low ou memory.min, para que as tarefas em segundo plano não lhes retirem recursos. Para irritável Nos contentores auxiliares (por exemplo, backup, batch), permito um swap moderado para evitar que sejam encerrados. Importante: observo o próprio nó – se o anfitrião já estiver a utilizar swap de forma percetível, controlo a densidade dos pods e o overcommit, em vez de aumentar a swappiness. Em pequenos nós VPS, o ZRAM funciona como buffer, para que picos momentâneos nos contentores não conduzam imediatamente a uma situação de OOM.
Características específicas da carga de trabalho: bases de dados, JVM e serviços em memória
Em Bases de dados Só tolero uma utilização moderada do swap. Algumas páginas inativas e transferidas para o swap não fazem mal; assim que os pools de buffer (por exemplo, o pool de buffer do InnoDB ou os buffers partilhados do PostgreSQL) começam a ir parar ao swap em quantidades significativas, as latências aumentam drasticamente. Por isso, mantenho o Swappiness baixo, verifico as Transparent Huge Pages (THP) e, se necessário, defino HugePages fixas, caso a pilha beneficie com isso. Para Baseado na JVM Nas aplicações, planeio o heap e a memória nativa de forma conservadora, defino o Xms próximo do Xmx para que a JVM aloque o conjunto de trabalho numa fase inicial e, assim, reduzo as falhas graves sob carga. Nos casos em que o tempo de arranque é secundário, faz sentido utilizar o «pre-touch» do heap para evitar picos de falhas de página no tráfego. Serviços em memória No caso de sistemas como o Redis, o Memcached ou determinados caches, bloqueio-os parcialmente na RAM através do mlock ou atribuo-lhes limites rígidos; prefiro um erro definido a picos de latência que duram segundos devido ao swap. Para pilhas de pesquisa como o Elasticsearch, prevejo RAM suficiente para as caches de ficheiros, pois estas beneficiam enormemente da cache do sistema operativo – o swap só deve existir como uma pequena margem de segurança.
NUMA e hosts de grande dimensão: garantir latências consistentes
Em sistemas com dois soquetes ou NUMA, evito uma ocupação desigual da memória, que provoca picos tardios de swap. Verifico o parâmetro `zone_reclaim_mode` e, normalmente, mantenho-o desativado (0), para que o kernel não recupere memória local de forma agressiva e recorra desnecessariamente à swap. Para serviços com grande pegada de memória, opto pela alocação intercalada, para evitar que um nó NUMA fique cheio enquanto outro ainda tem reservas — nós desequilibrados são um terreno fértil para o thrashing. Se tiver vários dispositivos de armazenamento rápidos, defino vários dispositivos de swap com a mesma prioridade, para evitar o IO. Além disso, nas máquinas de grande porte, mantenho deliberadamente um espaço livre na RAM (headroom), para absorver simultaneamente os picos no cache do sistema de ficheiros e no espaço do utilizador.
Manual de resolução de problemas em picos de swap
Quando as latências aumentam e o swap se torna visível, sigo um procedimento claro:
- Análise do estado do sistema: os comandos `free -h`, `vmstat 1` e `iostat -x 1` mostram-me se a RAM está escassa, se as E/S estão sobrecarregadas e qual é o nível de si/so (Swap-In/-Out). Além disso, verifico o tempo de CPU do kswapd e o comprimento da fila do armazenamento.
- Identificar a causa: com o top/htop, o pidstat -r -p PID, o smem ou o pmap, consigo ver quais os processos que estão a crescer, a gerar muitos «Major Faults» ou a atingir os limites através dos Cgroups.
- Medidas imediatas: reduzir o Swappiness, ativar o Zswap, limitar ou adiar tarefas em lote que se destaquem, ajustar os limites consoante a gravidade. Evito utilizar o swapoff sob carga, porque aumenta a pressão a curto prazo aumentado e o IO avança.
- Ajustes posteriores: verificar as estratégias de cache do sistema de ficheiros, avaliar os parâmetros vfs_cache_pressure e Dirty-Writeback, sem levar o kernel a um esvaziamento agressivo. Otimizo os planos de consulta, as janelas de lote e os tamanhos de cache na aplicação.
- Solução duradoura: atualização da RAM e planeamento da capacidade com base na carga de trabalho real (percentil 95/99), e não em valores médios. O swap permanece reduzido, mas Fiável.
Para o sistema de alarme, considero ainda Falhas graves de página e – caso estejam disponíveis – as métricas PSI (Pressure Stall Information) do kernel. A experiência mostra que valores crescentes de memory.stall estão fortemente correlacionados com reclamações dos utilizadores.
Segurança e conformidade no âmbito dos swaps
O swap pode conter dados sensíveis – palavras-passe, material de chave ou partes de sessões. Em ambientes regulamentados fechar Utilizo o swap (por exemplo, através do dm-crypt) para que, em caso de substituição de hardware ou roubo, não fiquem informações em texto simples. No caso dos SSDs, sempre que for adequado, utilizo o Discard/TRIM para a área de swap, de modo a manter o desempenho e a vida útil estáveis. Ao desativar um sistema, desativo a área de swap de forma adequada, reinicializo-a (mkswap) ou sobrescrevo-a, para que não fiquem resíduos. A hibernação raramente é relevante em servidores; caso seja, planeio o tamanho e a localização da área de troca em conformidade e reforço adicionalmente a encriptação.
Detalhes do sistema de ficheiros e do kernel: pequenos ajustes, grandes efeitos
Alguns pormenores acabam por compensar na prática. Verifico se o Agendador IO adequado ao suporte (por exemplo, mq-deadline/kyber para SSDs SATA, none para NVMe modernos), de modo a manter as latências baixas. Em núcleos mais antigos, ajusto cuidadosamente o vm.page-cluster (swap readahead), caso esteja disponível; readaheads demasiado grandes aumentam as E/S sem trazerem benefícios reais. Defino valores como vfs_cache_pressure e os rácios de dados sujos (dirty_ratio/dirty_background_ratio) de forma a que o kernel não esvazie as caches prematuramente e distribua a carga de escrita de forma mais uniforme. E, por fim: observo /proc/meminfo – Campos como SwapCached, Active(file)/Inactive(file) ou Dirty ajudam-me a distinguir a dinâmica da cache de uma verdadeira falta de RAM.
Planeamento da capacidade: compreender o volume de trabalho, nivelar os picos
Assim, o Swap no dia-a-dia Ajudas Em vez de me concentrar nos problemas, medo a taxa de utilização efetiva. Estabeleço uma correlação entre a carga de utilizadores, as taxas de pedidos e os acertos na cache com a utilização da RAM ao longo de várias semanas. O que me interessa é saber qual é a quente Qual é a parte da memória (que é realmente utilizada de forma contínua) e qual é a magnitude dos picos. Com base nisso, planeio um buffer de RAM que cubra as cargas do 95.º e 99.º percentis e mantenho o swap como rede de segurança. Paralelamente, otimizo os processos que produzem objetos grandes e de curta duração (exportações em lote, transcodificação de imagens/vídeos), dividindo-os em fases e limitando a E/S e a CPU. Desta forma, aumenta a probabilidade de que o swap seja utilizado apenas curto é utilizado – é precisamente para isso que foi concebido.
Resumo para a prática
Para mim, o swap continua a ser um Cinto de segurança, não é um substituto da RAM. Dimensiono-o de forma moderada, mantenho o Swappiness baixo, utilizo o Zswap/ZRAM quando necessário e faço medições regulares. Se a utilização do swap e as latências de E/S aumentarem de forma sustentada, reajo com ajustes e ampliação da RAM, em vez de aumentar o swap. É assim que utilizo o buffer de forma seletiva, mantenho o conjunto de dados ativo na RAM e garanto tempos de resposta constantes. Quem respeitar estas orientações transforma o swap num auxiliar fiável – e não na causa de problemas de desempenho.
