Saltar para o conteúdo 
Vou mostrar-te como configurar o vm.swappiness para que os serviços Web e de bases de dados nos servidores de alojamento respondam mais rapidamente e causem menos I/O. Com passos claros, valores iniciais adequados e monitorização, vais tirar maior partido da RAM disponível e reduzir Latências e evita o swapping desnecessário.
Pontos centrais
Estes pontos dão-te uma visão geral rápida para um ajuste que podes aplicar imediatamente.
- Comportamento do Swappiness: Controla com que antecedência o kernel transfere a RAM para o espaço de troca.
- Referência à carga de trabalho: Adaptar os valores ao tipo de aplicação, como uma base de dados ou a Web.
- Testar temporariamente: Verificar primeiro em tempo real e, só depois, definir de forma definitiva.
- Disposição do swap: Ter em conta a dimensão, o contexto e as prioridades.
- Monitorização: Monitorizar e ajustar a E/S, a RAM e os tempos de resposta.
O que é o vm.swappiness e como funciona
O parâmetro do kernel vm.swappiness define o grau de agressividade com que o Linux transfere páginas de memória da RAM para a área de swap. Podes encontrar o valor atual no pseudo-sistema de ficheiros em /proc/sys/vm/swappiness e alterá-lo em tempo de execução ou de forma permanente. Um valor elevado leva a uma transferência mais precoce para a área de swap, enquanto um valor baixo mantém o conteúdo na RAM por mais tempo. O objetivo é alcançar um bom equilíbrio entre a utilização da RAM, a cache de páginas e um comportamento controlado da área de swap. Tenho sempre em mente que a RAM é muito mais rápida do que qualquer SSD, por isso prefiro Memória de trabalho claramente antes do swap.
Por que é que a Swappiness é importante nos servidores de alojamento
Nos servidores web e de aplicações, a configuração de Trocas sobre o tempo de resposta e o rendimento. A troca agressiva de memória gera uma carga adicional de E/S e atrasa as consultas, sobretudo em cargas de trabalho com grande volume de dados de base de dados. Por outro lado, valores demasiado baixos acarretam o risco de ocorrências de OOM posteriores, que encerram os processos abruptamente. Por isso, além da RAM e do espaço de swap, avalio também picos de carga típicos, caches e padrões de consultas. Quem reduz as latências evita os solavancos e mantém as transações visivelmente líquido.
Recomendações consoante a carga de trabalho
Raramente existe um valor único que se adapte a todos os cenários; por isso, começo com intervalos comprovados na prática e, depois, faço ajustes com base nos dados de medição. As bases de dados beneficiam de configurações muito baixas, enquanto os servidores web puros suportam frequentemente valores um pouco mais elevados. Os sistemas de teste ou de desenvolvimento podem funcionar mais próximos do padrão, porque a facilidade de utilização desempenha um papel mais importante. Utilizo o esquema seguinte como ponto de partida pragmático para Hospedagem-Cargas de trabalho. Depois, analiso a E/S, a utilização da memória de swap e os tempos de resposta, e faço os ajustes necessários consoante as necessidades.
| Carga de trabalho | Swappiness recomendado | Objetivo |
|---|---|---|
| Bases de dados (MySQL, PostgreSQL) | 0–10 | Manter a memória tampão na RAM, manter as latências baixas |
| Em tempo real/baixa latência | 0–10 | Evitar picos de E/S através do swap |
| Servidor Web com caches | 10–20 (em alguns casos, 10–30) | Transferir páginas inativas para o disco, manter os pedidos ativos na RAM |
| Desenvolvimento/Testes | 30–60 | Conforto e estabilidade acima da latência |
Verificar o valor atual
Antes de alterar os valores, leio o estado e registo o Linha de base. Para isso, utilizo o comando `cat /proc/sys/vm/swappiness` ou `sysctl vm.swappiness`; ambas as opções apresentam um valor como 60. Paralelamente, verifico a utilização da RAM e do espaço de swap com o comando `free -h`. Com o comando `swapon –show`, identifico o tamanho, a prioridade e o suporte dos dispositivos de swap ativos. Estes dados iniciais ajudam-me a avaliar os efeitos posteriormente atribuir ser capaz de o fazer.
Fazer testes temporários em vez de alterar de forma definitiva logo de início
Vou instalar o Swappiness primeiro, a título experimental, para ver as reações em condições reais Carga A ver. O comando sysctl vm.swappiness=10 tem efeito imediato, mas só se mantém até ao reinício. Durante os testes, observo o top ou o htop, verifico o vmstat e o iostat e medo os tempos de resposta dos serviços. Se a taxa de swap diminuir e as latências se mantiverem estáveis, prossigo com passos razoáveis. Só quando as métricas forem convincentes é que registo o valor permanente fixo.
Configurar de forma permanente
Se o valor do teste estiver correto, insiro-o numa configuração sysctl e atualizo as definições. No ficheiro /etc/sysctl.conf, acrescento a linha vm.swappiness=10 e ativo-a com o comando sysctl -p. Para maior clareza, prefiro criar um ficheiro próprio em /etc/sysctl.d/, por exemplo 99-swappiness.conf, e carregá-lo com o comando sysctl –system. Isto facilita a gestão de versões e a integração em processos de automatização. Esta publicação fornece uma visão geral mais aprofundada sobre parâmetros relacionados: ajuste do sysctl, que me ajuda a organizar as alterações e Clareza traz.
Tamanho da área de troca, disposição da memória e suportes de dados
A «swappiness» nunca atua isoladamente, por isso avalio a dimensão e a localização do Troca sempre. Um espaço de swap insuficiente enche-se rapidamente, enquanto um espaço de swap sobredimensionado prolonga as fases de E/S sob pressão. Num SSD ou NVMe, o swap é mais rápido do que num HDD, mas a RAM continua a estar várias ordens de grandeza à frente. A utilização de vários dispositivos de swap com prioridades ajuda a utilizar primeiro o suporte mais rápido. Quem quiser aprofundar-se nas vantagens e desvantagens encontrará nesta visão geral sobre Memória virtual no alojamento reflexões úteis para a Prática.
Fluxo de trabalho na clínica: passo a passo
Começo por fazer um balanço da situação: registo o valor atual do Swappiness, a utilização da RAM e do espaço de swap, bem como a utilização da CPU e das E/S, e guardo-os como Referência Salvar. Em seguida, classifico a carga de trabalho: principalmente bases de dados, Web com cache, operação mista ou em contentores. Depois, defino um valor-alvo: para bases de dados, 0–10; para a Web, geralmente 10–20; para cargas mistas, vou avançando com cautela. Defino o valor temporariamente, observo várias fases de carga e comparo métricas. Se o resultado for consistente, fixo o valor, documento a alteração e verifico-a após atualizações do kernel, do hardware ou Libertação-Mudar novamente.
Cenários específicos: contentores, máquinas virtuais e nuvem
Em contentores e máquinas virtuais, aumento o valor de swappiness ao nível do anfitrião e do convidado em conjunto . As plataformas de orquestração, como o Kubernetes, beneficiam geralmente de configurações muito baixas nos nós de trabalho, para manter baixas as latências dos pods. Nas máquinas virtuais, defino internamente valores adequados, mas certifico-me de que o hipervisor não atua de forma contrária. Em configurações elásticas na nuvem, valores conservadores ajudam a suavizar os picos até que a escalabilidade entre em ação. Evito que um único contentor, devido a um comportamento intensivo de swap, afete toda a Plataforma abranda.
Monitorização e resolução de problemas
Consido que os sinais de alerta típicos de um valor inadequado de swappiness são uma elevada carga de E/S com RAM ainda disponível, tempos de resposta instáveis e consultas à base de dados lentas. Verifico esses padrões com o vmstat, o iostat, o sar e as métricas da minha pilha de observabilidade. Se o sistema apresentar uma utilização elevada da memória de troca apesar de haver RAM livre, costumo reduzir o valor de swappiness. Se observar registos de OOM ou falhas devido à falta de RAM, aumentei moderadamente o valor de swappiness ou ajusto a configuração da memória de troca. A tabela seguinte classifica os sintomas de uma provável Causa e indica uma primeira orientação.
| Sintoma | Causa provável | Próximo passo |
|---|---|---|
| E/S elevada com RAM disponível | Nível de swappiness demasiado elevado | Reduzir o valor, medir o impacto |
| Eventos OOM sob carga | O Swappiness está demasiado baixo ou há pouca memória de swap | Aumentar o valor, verificar o tamanho do swap |
| Consultas lentas apesar da reserva da CPU | Buffer da base de dados transferido para a memória externa | Valor entre 0 e 10, analisar o buffer DB |
| Picos de carga sem estrangulamento do processador | Picos de E/S induzidos pelo swap | Reduzir o Swappiness, verificar os acertos na cache |
Compreender métricas de granularidade fina
Para avaliar objetivamente a «swappiness», analiso mais detalhadamente os contadores do kernel. Em /proc/vmstat, os valores pswpin e pswpout indicam o número de páginas lidas e libertadas, respetivamente. Os valores pgscan_kswapd_* e pgsteal_* mostram o grau de agressividade com que o Reclaimer opera. Se os pgmajfault (erros graves de página) se acumularem, isso indica recargas com elevada carga de E/S. Analiso estes valores repetidamente ou com os comandos `sar -B` e `sar -W`, para observar as taxas e não apenas instantâneos. Com o comando vmstat 1, identifico si/so (Swap in/out) e consigo associar picos a eventos reais. Além disso, o diretório /proc/pressure/memory fornece uma estimativa do grau em que as tarefas são afetadas pela pressão de memória bloco (PSI). Se esses valores subirem parcialmente ou totalmente, tenho uma indicação clara de que o processo de recuperação está a ser demasiado agressivo ou de que o nível de swappiness não é adequado.
Swappiness 0 vs. 1: o que o kernel realmente faz
Muitas vezes, parte-se do princípio de que Swappiness=0 desativa completamente o swap. Isso não é verdade. O valor 0 indica ao kernel que deve evitar o swap tanto quanto possível e utilizá-lo apenas em caso de verdadeira pressão sobre a memória. Na prática, um valor entre 1 e 10 é suficiente para obter um comportamento muito conservador, enquanto o valor 0, em algumas versões, pode ocasionalmente levar a fases de recuperação tardias, mas intensas. Para serviços em que a latência é crítica, costumo definir valores entre 1 e 5 e observar se os valores de pswpout/pswpin permanecem praticamente nulos. Se, com o valor 0, ocorrerem eventos OOM durante picos de carga, aumentei ligeiramente o valor para que o kernel alivie a pressão mais cedo e de forma suave, em vez de o fazer de forma abrupta invadir.
Utilizar o Zswap e o ZRAM de forma eficaz
Para além do swap clássico em disco, utilizo o Zswap ou o ZRAM, consoante o perfil. O Zswap comprime as páginas transferidas para a memória de swap e mantém-nas inicialmente na RAM, antes de as enviar para o disco, se necessário. Isto reduz as operações de E/S e suaviza as latências, mas consome recursos da CPU. Em máquinas com uma forte reserva de CPU, isto é um mais lucrativo Compromisso. O ZRAM disponibiliza a área de troca comprimida diretamente na RAM – ideal para cargas com picos de atividade ou máquinas virtuais muito pequenas, nas quais prefiro utilizar RAM comprimida em vez de E/S lenta. Importante: opto conscientemente por um dos conceitos e defino as prioridades de forma a que o caminho mais rápido seja atendido em primeiro lugar. A «swappiness» continua a ser um instrumento de controlo: mesmo com o Zswap/ZRAM, pretendo evitar ondas de recuperação desnecessárias.
Cache de páginas, vfs_cache_pressure e acertos de cache
O Swappiness interage com o Page Cache, que mantém ficheiros e inodes na RAM. Com o vm.vfs_cache_pressure, controlo o grau de agressividade com que o kernel esvazia estes caches em relação a páginas anónimas. Valores demasiado elevados fazem com que os caches de metadados desapareçam demasiado depressa, o que abranda os servidores Web. Normalmente, começo com valores entre 50 e 100, avalio as taxas de acerto do cache e observo como se comportam as latências nos recursos estáticos e nas respostas da API. O objetivo é manter os conteúdos mais utilizados na RAM, sem que as páginas raramente utilizadas sobrecarreguem a memória. Se a taxa de acertos se mantiver boa e a E/S baixa, significa que o equilíbrio está correto; caso contrário, ajusto a swappiness e o vfs_cache_pressure no Tandem.
Evitar o «dirty writeback» e os picos de E/S
Os percursos de gravação influenciam as latências, tal como o swap. Com os parâmetros vm.dirty_background_ratio/bytes e vm.dirty_ratio/bytes, defino a quantidade de cache sujo que é criada antes de o kernel proceder à gravação. Prefiro *_bytes em vez de percentagens para definir limites máximos – especialmente em configurações com grande capacidade de RAM, nas quais as percentagens podem gerar enormes picos de writeback. Objetivo: gravação contínua e planeável, em vez de picos esporádicos que, juntamente com o swap, geram bloqueios de E/S. Verifico o iostat e as filas de gravação e mantenho os valores de forma a que os SSD/NVMe estejam constantemente ocupados, mas não atropelar tornar-se.
NUMA, Zone Reclaim e hosts de grande dimensão
Em sistemas com NUMA, a localização da memória é importante. Se o vm.zone_reclaim_mode estiver ativo, o kernel pode recuperar memória de forma mais agressiva no nó NUMA local, o que pode provocar picos indesejados de recuperação de memória. Para muitas cargas de trabalho de alojamento, desativo a recuperação de zona e deixo a localização a cargo do agendador, para obter um comportamento mais estável. Além disso, verifico as Transparent Huge Pages (THP): As bases de dados reagem frequentemente melhor a THP=never ou madvise, porque a desfragmentação não planeada e as atribuições de THP podem provocar picos de latência. O swappiness pode ser perfeito – se as políticas de THP ou NUMA interferirem, as Treinador.
Detalhes sobre os contêineres e os cgroups
Com o Cgroups v2, além do host-swappiness, tenho outras opções de ajuste: o `memory.high` promove uma recuperação suave, o `memory.max` define limites máximos rígidos e o `memory.swap.max` limita a utilização do swap por carga de trabalho. Desta forma, evito que determinados contentores abrandem o anfitrião através do swap. Defino valores baixos de swappiness no nó e atribuo prioridade às cargas de trabalho críticas através do `memory.low`, para que os seus conjuntos ativos permaneçam mais tempo na RAM. No Kubernetes, presto atenção à forma como o nó lida com o swap e testo as alterações primeiro em pools fora de produção. O importante é a visão global: os parâmetros do anfitrião, os limites do Cgroup e o orquestrador têm de estar em sintonia; caso contrário, a pressão apenas se desloca de um nível para o outros.
Implementação, automatização e recaída
Implemento as alterações no Swappiness de forma controlada, tal como qualquer otimização de desempenho: primeiro num pequeno grupo de nós praticamente idênticos (Canary) e, depois, de forma gradual a um conjunto mais vasto. O systemd-sysctl ou a gestão de configurações integram os valores de forma reprodutível. Documento os valores iniciais e finais, os momentos, os hosts envolvidos e Métricas. Para o caso de uma recaída, planeio antecipadamente a alteração inversa (por exemplo, sysctl vm.swappiness=60) e guardo os ficheiros sysctl anteriores. Durante as janelas de manutenção, avalio deliberadamente cenários típicos de carga, para não confundir as alterações com flutuações relacionadas com a hora do dia ou com o tráfego. Só assim as decisões mantêm a sua fiabilidade e são consensuais na equipa compreensível.
Equívocos comuns e anti-padrões
- „Swappiness=0 desativa o swap“: Não, o kernel continua a utilizar a memória de swap – mas de forma muito moderada.
- „Quanto mais swap, mais seguro é“: Um uso excessivo da memória de swap prolonga os períodos de carga elevada e mascara os estrangulamentos de RAM, em vez de os resolver.
- „Com o NVMe, o swapping não faz diferença“: O NVMe é rápido, mas várias ordens de grandeza mais lento do que a RAM. As latências continuam a ser percetíveis.
- „Um valor para todos os servidores“: As cargas de trabalho variam bastante. Sem medição, o ajuste fica ao acaso.
- „O Swappiness resolve qualquer problema de latência“: Muitas vezes, os problemas prendem-se com os acertos na cache, o writeback, o THP, os planos de consulta ou os percursos de rede.
Resumo para um início rápido
Normalmente, defino o vm.swappiness para servidores Web entre 10 e 20 e para bases de dados entre 0 e 10, testo o efeito e observo a E/S, as latências e Troca-Proporção. Defino o valor final através do sysctl no ficheiro /etc/sysctl.d/ e mantenho as alterações documentadas. Paralelamente, garanto uma configuração de swap adequada: tamanho adequado, suporte rápido, prioridades sensatas. No que diz respeito à pressão de memória, tenho também em conta o Page Cache e o seu comportamento; esta visão geral fornece uma boa introdução ao tema Expulsão da cache de páginas, que me ajuda na análise das causas e Contexto . Com este procedimento, consigo tempos de resposta fiáveis, evito picos de paging e utilizo a memória RAM disponível de forma eficaz.
