O sysctl do Linux é a principal interface para ler e modificar parâmetros do kernel em tempo de execução sem reinicialização. Seja em um servidor web de alto tráfego, um host de banco de dados ou uma carga de trabalho conteinerizada, ajustar o kernel com sysctl pode melhorar drasticamente o throughput, reduzir a latência e evitar o esgotamento de recursos. Neste guia você aprenderá quais parâmetros são mais importantes, como aplicá-los com segurança e como torná-los persistentes entre reinicializações usando /etc/sysctl.conf e arquivos de configuração drop-in em /etc/sysctl.d/.

Pré-requisitos

  • Um sistema Linux executando o kernel 4.x ou superior (Ubuntu 20.04+, Debian 11+, RHEL 8+ ou equivalente)
  • Acesso sudo ou root
  • Familiaridade básica com a linha de comando e um editor de texto (nano, vim ou vi)
  • Compreensão da carga de trabalho que o servidor executa (servir web, banco de dados, uso geral)

Entendendo a Interface sysctl

O comando sysctl é um invólucro fino em torno do pseudo-sistema de arquivos /proc/sys/. Cada parâmetro ajustável possui um arquivo correspondente nesse caminho. Por exemplo, o parâmetro net.ipv4.tcp_fin_timeout mapeia para /proc/sys/net/ipv4/tcp_fin_timeout. Você pode lê-lo diretamente com cat ou via sysctl:

# Ambos os comandos retornam o mesmo resultado
sysctl net.ipv4.tcp_fin_timeout
cat /proc/sys/net/ipv4/tcp_fin_timeout

Escrever nesses arquivos é equivalente a executar sysctl -w, mas as alterações feitas de qualquer forma são temporárias — desaparecem ao reiniciar. O fluxo de trabalho padrão é: testar com -w primeiro e, em seguida, persistir em um arquivo de configuração quando estiver satisfeito.

Para ver todos os parâmetros ajustáveis de uma vez:

sysctl -a

Para filtrar por namespace:

sysctl -a | grep net.ipv4.tcp

Parâmetros de Gerenciamento de Memória

vm.swappiness

vm.swappiness controla com que avidez o kernel move páginas de memória da RAM para o espaço de swap. A escala vai de 0 (evitar swap ao máximo) a 200 (fazer swap agressivamente). O padrão do kernel é 60.

Para servidores de aplicação e bancos de dados que precisam manter dados na RAM:

sudo sysctl -w vm.swappiness=10

Para desktops onde a responsividade importa mais do que manter caches aquecidos, 60 ou até mais alto pode ser adequado. Para sistemas sem swap algum, definir como 0 impede qualquer atividade de swap.

vm.dirty_ratio e vm.dirty_background_ratio

Esses parâmetros controlam quanto de memória suja (não gravada) o sistema tolera antes de forçar uma descarga para o disco.

  • vm.dirty_background_ratio (padrão 10) — percentual da memória total em que começa a gravação em segundo plano
  • vm.dirty_ratio (padrão 20) — percentual em que os processos são bloqueados até que as páginas sujas sejam gravadas

Para servidores com SSDs rápidos ou cargas de trabalho com muita escrita, valores menores reduzem o risco de grandes pausas de escrita:

sudo sysctl -w vm.dirty_background_ratio=5
sudo sysctl -w vm.dirty_ratio=10

vm.vfs_cache_pressure

Este parâmetro controla com que agressividade o kernel recupera memória usada para cachear objetos de diretório e inode. O padrão é 100. Reduzi-lo (ex.: 50) faz o kernel manter metadados do sistema de arquivos em cache por mais tempo, o que beneficia cargas de trabalho com muitos arquivos pequenos:

sudo sysctl -w vm.vfs_cache_pressure=50

Ajuste da Pilha de Rede com net.core e net.ipv4

net.core.somaxconn

net.core.somaxconn define o comprimento máximo da fila de escuta para aceitar novas conexões TCP. O padrão do kernel é 128, muito baixo para qualquer serviço voltado para a web. Nginx, Apache e Node.js se beneficiam de um valor muito maior:

sudo sysctl -w net.core.somaxconn=65535

Sua aplicação também deve chamar listen() com um backlog grande. Para o Nginx, defina listen 80 backlog=65535; no bloco server.

net.core.netdev_max_backlog

Controla quantos pacotes a placa de rede pode enfileirar antes que o kernel os descarte. Sob cargas de alta largura de banda, o padrão de 1000 pode causar descarte de pacotes:

sudo sysctl -w net.core.netdev_max_backlog=5000

Tamanhos dos Buffers TCP

O kernel usa buffers de recebimento e envio por socket para armazenar dados em trânsito. Buffers maiores melhoram o throughput em links de alta latência (redes longas e gordas):

# Buffer de recepção mínimo, padrão e máximo (bytes)
sudo sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"

# Buffer de envio mínimo, padrão e máximo (bytes)
sudo sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

# Máximo global para buffers de socket
sudo sysctl -w net.core.rmem_max=16777216
sudo sysctl -w net.core.wmem_max=16777216

TIME_WAIT e Reuso de Conexões

Servidores de alto tráfego criam milhares de conexões de curta duração. Sem ajuste, os sockets ficam em TIME_WAIT por até dois minutos e esgotam as portas efêmeras:

# Reutilizar sockets TIME_WAIT para novas conexões de saída
sudo sysctl -w net.ipv4.tcp_tw_reuse=1

# Reduzir a duração do TIME_WAIT (padrão 60 segundos)
sudo sysctl -w net.ipv4.tcp_fin_timeout=30

# Expandir o intervalo de portas locais para conexões de saída
sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535"

Proteção Contra SYN Flood

Ative os SYN cookies para proteger contra ataques SYN flood sem descartar conexões legítimas:

sudo sysctl -w net.ipv4.tcp_syncookies=1
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=2048

Limites de Descritores de Arquivo e Processos

Servidores de alta concorrência (servidores web, brokers de mensagens, agentes de monitoramento) abrem milhares de descritores de arquivo simultaneamente. O limite global do kernel é controlado por fs.file-max:

# Visualizar o máximo atual do sistema
sysctl fs.file-max

# Aumentar para 2 milhões em servidores com alta carga
sudo sysctl -w fs.file-max=2000000

Observe que fs.file-max é um teto no nível do kernel. Você também deve aumentar os limites por processo via /etc/security/limits.conf ou LimitNOFILE na unit do systemd para permitir que processos individuais usem o novo espaço.

Persistindo Configurações: sysctl.conf vs Arquivos Drop-in

A Abordagem Tradicional: /etc/sysctl.conf

Adicione parâmetros diretamente em /etc/sysctl.conf:

# Ajuste de memória
vm.swappiness = 10
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
vm.vfs_cache_pressure = 50

# Ajuste de rede
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048

# Limite de descritores de arquivo
fs.file-max = 2000000

Aplicar sem reiniciar:

sudo sysctl -p

A Abordagem Moderna: Arquivos Drop-in em /etc/sysctl.d/

Arquivos drop-in em /etc/sysctl.d/ são a abordagem preferida em distribuições baseadas em systemd. Eles permitem que pacotes, ferramentas de gerenciamento de configuração (Ansible, Puppet, Chef) e scripts personalizados gerenciem cada um seu próprio conjunto de parâmetros sem editar um arquivo compartilhado.

Crie um arquivo dedicado:

sudo nano /etc/sysctl.d/99-webserver-tuning.conf

Adicione seus parâmetros no mesmo formato chave = valor. Recarregue todos os arquivos drop-in e /etc/sysctl.conf com:

sudo sysctl --system

Os arquivos são processados em ordem lexicográfica. O prefixo 99- garante que seu arquivo seja carregado por último, substituindo quaisquer padrões conflitantes definidos pelos pacotes do sistema operacional.

Parâmetros Padrão vs Recomendados: Tabela Comparativa

ParâmetroPadrão do KernelRecomendado (Servidor Web)Observações
vm.swappiness6010Mantém dados da aplicação na RAM
vm.dirty_background_ratio105Descarrega páginas sujas mais cedo
vm.dirty_ratio2010Reduz o risco de pausas de escrita
vm.vfs_cache_pressure10050Mantém metadados de diretório em cache por mais tempo
net.core.somaxconn12865535Suporta alta concorrência de conexões
net.core.netdev_max_backlog10005000Evita descarte de pacotes sob carga
net.ipv4.tcp_fin_timeout6030Libera sockets mais rapidamente
net.ipv4.tcp_tw_reuse01Reutiliza sockets TIME_WAIT
net.ipv4.ip_local_port_range32768–609991024–65535Mais portas efêmeras
fs.file-max~1000002000000Suporta alto número de arquivos abertos

Cenário do Mundo Real

Você tem um servidor Nginx em produção gerenciando 5.000 conexões HTTP simultâneas. Os usuários estão vendo erros 502 Bad Gateway intermitentes e timeouts de conexão durante os horários de pico. Você executa ss -s e vê milhares de sockets presos em TIME_WAIT, e o dmesg mostra TCP: request_sock_TCP: Possible SYN flooding on port 443. O servidor tem 16 GB de RAM e mal usa swap, mas o free -h mostra que o uso de buffer/cache está baixo.

Esta é a sequência de ajuste que você aplica:

# Passo 1: Diagnosticar
ss -s
sysctl net.core.somaxconn net.ipv4.tcp_fin_timeout fs.file-max

# Passo 2: Aplicar correções em tempo de execução
sudo sysctl -w net.core.somaxconn=65535
sudo sysctl -w net.ipv4.tcp_tw_reuse=1
sudo sysctl -w net.ipv4.tcp_fin_timeout=30
sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535"
sudo sysctl -w net.ipv4.tcp_syncookies=1
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=2048
sudo sysctl -w vm.swappiness=10
sudo sysctl -w fs.file-max=2000000

# Passo 3: Monitorar por 15 minutos
watch -n 5 ss -s

# Passo 4: Se melhorou, persistir as configurações
sudo tee /etc/sysctl.d/99-webserver-tuning.conf <<'EOF'
net.core.somaxconn = 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048
vm.swappiness = 10
fs.file-max = 2000000
EOF

sudo sysctl --system

A contagem de TIME_WAIT cai de vários milhares para algumas centenas em minutos, e os erros 502 param.

Armadilhas e Casos Especiais

As mudanças não são herdadas por processos em execução. Quando você aumenta fs.file-max, os workers do Nginx já em execução ainda operam sob o limite antigo por processo. Você também deve atualizar /etc/security/limits.conf e reiniciar o serviço, ou definir LimitNOFILE no arquivo de unit do systemd.

tcp_tw_reuse se aplica apenas a conexões de saída. Permite que a pilha local reutilize um socket TIME_WAIT como origem de uma nova conexão de saída. Não afeta conexões de entrada de clientes. Não confunda com tcp_tw_recycle, que foi removido no kernel 4.12 e causava falhas de conexão atrás de NAT.

net.core.somaxconn é um teto, não um piso. Se sua aplicação chamar listen() com um backlog menor, o kernel usa o menor valor. Ajuste tanto o parâmetro do kernel quanto a configuração da aplicação.

Contêineres herdam o namespace do kernel do host. Parâmetros sysctl definidos em /etc/sysctl.d/ no host se aplicam a todos os contêineres. Alguns parâmetros podem ser definidos por namespace de rede usando docker run --sysctl ou contextos de segurança de pod do Kubernetes, mas a maioria requer acesso no nível do host.

Testar com cargas de trabalho irreais é perigoso. Sempre faça benchmark com tráfego que espelhe a produção. Um parâmetro que melhora o throughput em um teste de laboratório pode degradar a latência em produção se as características da carga de trabalho forem diferentes.

Solução de Problemas

Permissão negada ao escrever um parâmetro: Alguns parâmetros são somente leitura (marcados em /proc/sys/ como modo 444) e não podem ser alterados em tempo de execução. Outros requerem uma opção de compilação específica do kernel. Verifique o dmesg para mensagens de erro após tentar uma escrita.

Configuração não sobrevive à reinicialização: Verifique se o arquivo está em /etc/sysctl.d/ com extensão .conf e não contém erros de sintaxe. Execute sudo sysctl --system e verifique a saída por “Applying /etc/sysctl.d/99-custom.conf” para confirmar que está sendo carregado.

Erro de parâmetro não encontrado (sysctl: cannot stat /proc/sys/...): O parâmetro requer um módulo do kernel que não está carregado. Carregue o módulo primeiro (ex.: modprobe nf_conntrack) e tente novamente.

Valores inesperadamente baixos após aplicar configurações: Outro arquivo de configuração carregado depois está substituindo o seu. Verifique a ordem de saída do sysctl --system e renomeie seu arquivo com um prefixo numérico maior (ex.: 99- em vez de 10-).

Resumo

  • sysctl lê e grava parâmetros do kernel expostos via /proc/sys/ em tempo de execução sem reinicialização
  • Use sysctl -w para testes temporários e, em seguida, persista os valores que funcionam em /etc/sysctl.d/99-custom.conf
  • Use sudo sysctl --system para recarregar todos os arquivos de configuração; use sudo sysctl -p para recarregar apenas /etc/sysctl.conf
  • vm.swappiness=10 mantém os dados da aplicação na RAM em servidores com memória adequada
  • net.core.somaxconn=65535 e net.ipv4.tcp_tw_reuse=1 são as mudanças de maior impacto para a concorrência em servidores web
  • fs.file-max define o teto do kernel para arquivos abertos — você também deve aumentar os limites por processo na aplicação ou na unit do systemd
  • Arquivos drop-in em /etc/sysctl.d/ são preferíveis a editar /etc/sysctl.conf diretamente
  • Sempre aplique as mudanças em tempo de execução primeiro, monitore sob carga e persista apenas o que se provar benéfico

Artigos Relacionados