Aula 26: Tuning de performance — parâmetros de kernel e sysctl

O tuning de performance é a arte e a ciência de extrair o máximo de um sistema Linux ajustando parâmetros de kernel, subsistemas de memória, rede e I/O sem adicionar hardware. Ao contrário do que muitos imaginam, o kernel Linux já vem com valores padrão extremamente conservadores. Esses padrões são escolhidos para funcionar bem na maior variedade possível de cenários, mas raramente são ideais para servidores de banco de dados, gateways de rede, ambientes virtualizados ou workloads com alto volume de conexões simultâneas. Nesta aula, vamos mergulhar fundo no mecanismo sysctl, entender como o kernel expõe seus parâmetros em tempo de execução e como tornar as alterações persistentes entre reinicializações no Ubuntu, Debian, CentOS, Rocky Linux e derivados RHEL.

O termo sysctl refere-se tanto a uma interface de sistema quanto a um comando utilitário. Ele permite visualizar e modificar parâmetros do kernel em execução, sem necessidade de reiniciar a máquina. Esses parâmetros ficam disponíveis no pseudo-filesystem /proc/sys. Quando você ajusta, por exemplo, o vm.swappiness para reduzir o uso de swap, está alterando uma variável que o kernel consulta constantemente durante a alocação de memória. Esse tipo de ajuste é imediato, mas volátil: desaparece após um reboot, a menos que você o registre em arquivos de configuração apropriados. Aqui você aprenderá exatamente como fazer isso de forma segura, testável e reversível.

Ao final desta aula, você terá um fluxo de trabalho completo e profissional para tuning de performance. Começaremos pela base teórica, passando pela exploração dos parâmetros existentes, identificação de gargalos, ajustes de memória, rede e I/O, e finalizaremos com testes de verificação e solução de erros comuns. Todos os procedimentos foram validados em laboratório com servidores reais, em projetos de infraestrutura executados pela nossa equipe de engenharia. Em nossos projetos na JRT Technology Solutions, nossos especialistas utilizam diariamente os procedimentos que você verá a seguir para estabilizar ambientes de produção sob alta carga.

Você vai perceber que tuning de performance não é uma ciência exata. Um ajuste que acelera um servidor web pode degradar um servidor de banco de dados. Por isso, cada seção desta aula enfatiza o contexto, o teste e a verificação. Nada de aplicar receitas cegas. Ao concluir, você saberá não apenas o que alterar, mas por que alterar, quando alterar e como reverter se algo sair do esperado.

O que você vai aprender nesta aula

Explorar a árvore /proc/sys e entender sua relação com o kernel em tempo de execução;
Utilizar o comando sysctl para leitura, escrita e persistência de parâmetros;
Configurar corretamente os arquivos /etc/sysctl.conf e /etc/sysctl.d/*.conf em distribuições Debian/Ubuntu e RHEL/CentOS/Rocky;
Identificar gargalos de performance em memória, rede, CPU e disco antes de sair alterando valores;
Ajustar o vm.swappiness, vm.dirty_ratio, vm.vfs_cache_pressure e outros parâmetros críticos de memória;
Aplicar ajustes avançados de rede como net.core.somaxconn, net.ipv4.tcp_fin_timeout e net.ipv4.ip_local_port_range;
Verificar a aplicação de cada ajuste com comandos de inspeção e interpretar as saídas;
Resolver os erros mais frequentes em ambientes de produção que envolvem tuning de kernel.

Pré-requisitos e Ambiente

Antes de iniciar esta aula, você precisa ter acesso root ou privilégios de sudo em uma máquina Linux. Recomendamos fortemente que você execute os procedimentos em uma VM dedicada ou contêiner com snapshot, pois alguns parâmetros podem causar instabilidade se aplicados incorretamente. O ambiente mínimo para acompanhar esta aula inclui:

Ubuntu 22.04 LTS ou Debian 12 (ou superiores);
CentOS Stream 9 ou Rocky Linux 9 (para cobertura RHEL);
Conhecimento básico de shell, edição de arquivos com nano ou vi;
Entendimento dos conceitos de memória RAM, swap, sockets TCP e I/O de disco, vistos nas aulas anteriores;
Acesso à internet opcional, para consulta de documentação do kernel;
Pelo menos 2 GB de RAM e 2 vCPUs para observar efeitos práticos dos ajustes.

Se você não tem uma VM disponível, pode usar qualquer instância cloud. A JRT Technology Solutions oferece treinamentos e implementação em Linux, e nossos laboratórios costumam usar exatamente as versões citadas acima. Ter um ambiente descartável é a regra de ouro: você vai alterar parâmetros que impactam o kernel e precisa garantir que pode recomeçar do zero se algo der errado.

Fundamentos de Tuning de Performance no Linux

O kernel Linux é monolítico, mas altamente modular em seu comportamento. Ele expõe centenas de parâmetros ajustáveis em tempo real por meio do pseudo-filesystem /proc/sys. A ideia central do tuning de performance é alinhar o comportamento do kernel com o perfil de uso do sistema. Por exemplo, um servidor web com milhares de conexões curtas se beneficia de um timeout de conexão menor e de buffers maiores, enquanto um servidor de banco de dados com poucas conexões longas pode preferir o oposto. Não existe configuração universal: existe configuração adequada ao workload.

Os parâmetros são organizados em diretórios que representam subsistemas. O diretório /proc/sys/vm contém ajustes de gerenciamento de memória virtual. O diretório /proc/sys/net contém ajustes de rede. O diretório /proc/sys/fs contém ajustes de file system e I/O. E o diretório /proc/sys/kernel contém ajustes gerais do kernel, como limites de fila e parâmetros de processos. Cada arquivo nesses diretórios representa uma variável do kernel que pode ser lida com cat e, na maioria dos casos, escrita com echo ou com o utilitário sysctl.

É importante entender a diferença entre alteração volátil e persistente. Quando você executa sysctl -w vm.swappiness=10, o valor muda imediatamente, mas volta ao padrão no próximo boot. Para persistir, você deve incluir a linha vm.swappiness=10 em um arquivo em /etc/sysctl.d/ ou no arquivo /etc/sysctl.conf, dependendo da distribuição. O comando sysctl –system aplica todas as configurações persistentes, enquanto sysctl -a lista todas as variáveis disponíveis. Essa distinção é o alicerce de qualquer rotina profissional de tuning de performance.

Outro conceito essencial é o de benchmark e linha de base. Antes de alterar qualquer parâmetro, você precisa medir o estado atual do sistema. Ferramentas como top, htop, vmstat, iostat, free, ss e sar são aliadas indispensáveis. Sem uma medição de referência, você não saberá se o ajuste melhorou ou piorou o desempenho. Em nossos projetos na JRT Technology Solutions, estabelecemos um mantra: medir, ajustar, medir novamente. Isso evita alterações baseadas em achismos que depois se revelam prejudiciais.

Por fim, saiba que nem todo parâmetro aceita qualquer valor. Alguns exigem valores booleanos (0 ou 1), outros inteiros, outros faixas específicas. Toda vez que você for ajustar um parâmetro, consulte a documentação do kernel para entender o tipo e o impacto. Vamos abordar os mais utilizados e seguros, com faixas bem definidas e efeitos previsíveis.

O Sistema sysctl e o Diretório /proc/sys

O comando sysctl é a interface principal para consultar e modificar parâmetros do kernel. Sua sintaxe básica para leitura é sysctl parametro e para escrita é sysctl -w parametro=valor. Por exemplo, para verificar o tamanho máximo da fila de conexões pendentes, use sysctl net.core.somaxconn. Para alterá-lo para 65535, execute sysctl -w net.core.somaxconn=65535. A resposta imediata do comando confirma o novo valor.

O diretório /proc/sys é montado automaticamente pelo kernel e não existe fisicamente em disco. Cada arquivo ali corresponde a um parâmetro. Você pode ler diretamente com cat /proc/sys/net/core/somaxconn e obter o mesmo resultado de sysctl net.core.somaxconn. A grande vantagem do sysctl é a sintaxe simplificada com pontos, em vez de barras, e a possibilidade de carregar múltiplas configurações de uma só vez com sysctl -p ou sysctl –system.

Existem centenas de parâmetros, mas não se assuste. Na prática, os administradores lidam com algumas dezenas de ajustes relevantes para tuning de performance. A árvore mais importante inclui vm.swappiness, vm.dirty_ratio, vm.dirty_background_ratio, vm.vfs_cache_pressure, net.core.somaxconn, net.core.netdev_max_backlog, net.ipv4.tcp_fin_timeout, net.ipv4.tcp_tw_reuse, net.ipv4.ip_local_port_range, fs.file-max e kernel.pid_max. Vamos explorar cada um com profundidade nas próximas seções.

Uma observação importante: a localização dos arquivos de configuração persistente varia entre distribuições. Em Ubuntu e Debian, o diretório /etc/sysctl.d/ é o local preferido, e o arquivo /etc/sysctl.conf ainda é lido. Em CentOS, Rocky Linux e RHEL, o diretório /etc/sysctl.d/ também é suportado, e o arquivo /etc/sysctl.conf é o padrão. A ordem de leitura segue a ordem alfabética dos arquivos dentro de /etc/sysctl.d/, e o arquivo 99-sysctl.conf normalmente aponta para /etc/sysctl.conf. Vamos usar como boa prática criar um arquivo dedicado, como /etc/sysctl.d/90-tuning.conf, para organizar nossos ajustes.

Identificando Gargalos de Performance Antes de Tunar

Aplicar tuning de performance sem diagnóstico é como trocar o óleo do carro sem verificar se o problema é na ignição. Antes de alterar qualquer parâmetro, você deve coletar métricas do sistema para identificar o gargalo. Comece com o comando free -h para ver memória total, usada, livre, cache e swap. Se o sistema está usando swap mesmo com memória livre disponível, o vm.swappiness provavelmente está alto demais para o seu cenário. Se o cache está consumindo toda a RAM, mas isso não é necessariamente ruim, pois o kernel libera cache sob pressão.

Em seguida, use vmstat 1 10 para observar atividade de CPU, memória, processos bloqueados e swap em tempo real. As colunas si e so mostram swap in e swap out. Valores constantemente altos indicam pressão de memória e necessidade de mais RAM ou de ajuste do swappiness. A coluna procs b mostra processos bloqueados aguardando I/O; se esse número está sempre alto, o gargalo é de disco. A coluna wa no top também indica tempo de CPU aguardando I/O.

Para rede, use ss -s para resumo de sockets e ss -tan para listar conexões TCP ativas. Se você observar muitos sockets em estado TIME_WAIT, o servidor está lidando com muitas conexões curtas e pode se beneficiar de ajustes como net.ipv4.tcp_tw_reuse e redução do tcp_fin_timeout. Se você vir conexões sendo descartadas ou filas estouradas, verifique net.core.somaxconn e net.core.netdev_max_backlog. Use netstat -s para estatísticas detalhadas de protocolos e procure por incrementos de erros.

Para I/O de disco, o comando iostat -x 1 10 (do pacote sysstat) fornece métricas por dispositivo, incluindo await (tempo médio de espera por requisição) e %util (porcentagem de utilização). Valores de %util próximos de 100% indicam disco saturado. O comando dmesg | tail -50 pode revelar erros de disco ou rede no kernel. Por fim, o sar -r 1 10 é excelente para memória e o sar -n DEV 1 10 para throughput de rede. Colete pelo menos 10 segundos de cada métrica antes de iniciar os ajustes.

Passo a Passo — Tuning de Performance com sysctl

Agora que você entendeu a base e identificou seus gargalos, vamos executar um fluxo completo de tuning de performance usando o comando sysctl. Mostraremos cada comando com comentários e a saída esperada. O procedimento foi validado em Ubuntu 22.04 e Rocky Linux 9. Siga cada passo na ordem apresentada.

Verifique a versão do kernel e da distribuição: execute uname -r e cat /etc/os-release. Isso confirma que você está em um ambiente compatível e ajuda a consultar a documentação correta do kernel.
Liste todos os parâmetros disponíveis com sysctl -a. A saída é longa, então filtre com grep. Por exemplo, sysctl -a | grep vm.swappiness para ver o valor atual.
Altere um parâmetro em tempo real: use sysctl -w vm.swappiness=10. O comando deve ecoar o novo valor, confirmando a mudança.
Confirme a leitura direta no /proc/sys: execute cat /proc/sys/vm/swappiness. A saída deve ser 10.
Teste a persistência criando um arquivo de configuração: crie o arquivo /etc/sysctl.d/90-tuning.conf com seus ajustes (mostraremos o conteúdo completo na próxima seção).
Aplique as configurações persistentes: execute sysctl –system. Isso recarrega todos os arquivos de configuração, incluindo o seu novo arquivo.
Verifique se o valor sobreviveu à recarga: execute sysctl vm.swappiness e compare com o valor definido no arquivo.
Reinicie o sistema ou, pelo menos, valide o comportamento dos parâmetros em diferentes cargas. Em produção, não reinicie se não puder. Em laboratório, reinicie para confirmar a persistência.

O bloco de comandos abaixo mostra o fluxo completo em um sistema Ubuntu ou Rocky. Comentários explicam cada etapa.

# 1. Confirmar ambiente
uname -r                                 # Exibe a versão do kernel
cat /etc/os-release | head -5            # Mostra distribuição e versão

# 2. Consultar valor atual do swappiness
sysctl vm.swappiness                     # Saída esperada: vm.swappiness = 60

# 3. Alterar swappiness em tempo real
sysctl -w vm.swappiness=10               # Saída esperada: vm.swappiness = 10

# 4. Confirmar via /proc/sys
cat /proc/sys/vm/swappiness              # Saída esperada: 10

# 5. Criar arquivo de tuning persistente
sudo tee /etc/sysctl.d/90-tuning.conf <<'EOF'
# Arquivo de tuning de performance
vm.swappiness=10
vm.dirty_ratio=15
vm.dirty_background_ratio=5
EOF

# 6. Recarregar todas as configurações
sudo sysctl --system                     # Aplica /etc/sysctl.d/*.conf e /etc/sysctl.conf

# 7. Confirmar persistência
sysctl vm.swappiness                     # Saída esperada: vm.swappiness = 10

# 8. Listar todas as variáveis de memória para inspeção
sysctl -a | grep '^vm\.'                 # Filtra apenas parâmetros de memória virtual

Saída esperada no terminal (parcial, pois a saída completa de sysctl -a é extensa):

$ uname -r
5.15.0-91-generic
$ cat /etc/os-release | head -5
PRETTY_NAME="Ubuntu 22.04.3 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION_CODENAME=jammy
ID=ubuntu
$ sysctl vm.swappiness
vm.swappiness = 60
$ sysctl -w vm.swappiness=10
vm.swappiness = 10
$ cat /proc/sys/vm/swappiness
10
$ sudo sysctl --system
* Applying /etc/sysctl.d/10-console-messages.conf ...
kernel.printk = 4 4 1 7
* Applying /etc/sysctl.d/90-tuning.conf ...
vm.swappiness = 10
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5
* Applying /etc/sysctl.conf ...
$ sysctl vm.swappiness
vm.swappiness = 10
$ sysctl -a | grep '^vm\.'
vm.admin_reserve_kbytes = 8192
vm.block_dump = 0
vm.compact_memory = 1
vm.dirty_background_ratio = 5
vm.dirty_ratio = 15
vm.dirtytime_expire_seconds = 43200
vm.swappiness = 10
vm.vfs_cache_pressure = 100
...

Repare que, após a execução de sysctl –system, o kernel percorre os arquivos em ordem alfabética e aplica cada linha. Se houver conflito, o último arquivo lido prevalece. Essa característica é útil para sobrepor valores padrão da distribuição sem modificar arquivos originais. Em nossos projetos na JRT Technology Solutions, sempre utilizamos arquivos prefixados com números altos, como 90-, para garantir que nossas configurações prevaleçam sobre as defaults.

Configuração Detalhada — Arquivo /etc/sysctl.d/90-tuning.conf

O arquivo /etc/sysctl.d/90-tuning.conf é o coração da persistência dos seus ajustes. Cada linha segue o formato parametro=valor, sem espaços ao redor do sinal de igual. Linhas em branco são ignoradas, e comentários começam com # ou ;. Você pode organizar o arquivo por subsistema, criando seções lógicas para memória, rede, file system e kernel. Abaixo, apresentamos um conteúdo completo e comentado, que serve como base sólida para servidores web e de aplicação.

# /etc/sysctl.d/90-tuning.conf
# Tuning de performance para servidores Linux
# Aplicado com: sysctl --system
# Última atualização: 24/08/2026

# ---------------- MEMÓRIA ----------------
# Reduz inclinação a usar swap. 10 é agressivo para manter em RAM.
vm.swappiness = 10
# Percentual máximo de memória suja antes de forçar gravação em disco.
vm.dirty_ratio = 15
# Percentual de memória suja que dispara gravação em segundo plano.
vm.dirty_background_ratio = 5
# Reduz pressão sobre cache de inodes/dentries. Valores > 100 favorecem cache.
vm.vfs_cache_pressure = 50

# ---------------- FILE SYSTEM ----------------
# Número máximo de arquivos abertos pelo sistema.
fs.file-max = 2097152
# Número máximo de inotify watches (útil para verificação de arquivos).
fs.inotify.max_user_watches = 524288

# ---------------- REDE ----------------
# Tamanho máximo da fila de conexões pendentes aceitas por socket.
net.core.somaxconn = 65535
# Backlog máximo de pacotes na fila de entrada da interface.
net.core.netdev_max_backlog = 65535
# Reutiliza sockets em TIME_WAIT para novas conexões.
net.ipv4.tcp_tw_reuse = 1
# Reduz timeout de TIME_WAIT de 60s para 15s.
net.ipv4.tcp_fin_timeout = 15
# Portas efêmeras disponíveis para conexões de saída.
net.ipv4.ip_local_port_range = 1024 65535
# Ativa SYN cookies para mitigar ataques SYN flood.
net.ipv4.tcp_syncookies = 1
# Aumenta buffer de recepção padrão.
net.core.rmem_default = 262144
# Aumenta buffer de envio padrão.
net.core.wmem_default = 262144
# Buffer máximo de recepção (ajustável pelo kernel).
net.core.rmem_max = 16777216
# Buffer máximo de envio (ajustável pelo kernel).
net.core.wmem_max = 16777216

# ---------------- KERNEL ----------------
# Aumenta limite máximo de processos individuais.
kernel.pid_max = 4194304
# Ativa o magic SysRq para depuração emergencial.
kernel.sysrq = 1

Esse arquivo deve ser criado com permissões de root e, de preferência, com um backup do estado anterior. Para criar, use sudo nano /etc/sysctl.d/90-tuning.conf ou sudo tee como mostrado anteriormente. Após salvar, execute sudo sysctl –system para aplicar. Para desfazer, basta excluir o arquivo e recarregar com sudo sysctl –system. Toda alteração é reversível, desde que você mantenha o arquivo original da distribuição intacto.

Tuning de Performance de Memória e Swap

O gerenciamento de memória é, disparado, o alvo mais comum de tuning de performance. O parâmetro vm.swappiness controla o quão agressivamente o kernel move páginas da RAM para o swap. O valor padrão no Ubuntu costuma ser 60, o que significa que o kernel começa a usar swap relativamente cedo, mesmo quando ainda há memória livre. Para servidores de aplicação ou banco de dados, reduzir para 10 ou 5 mantém os processos em RAM e evita queda de performance por swap. Para desktops com pouca RAM, um valor mais alto pode ser benéfico, mas para servidores, valores baixos são regra.

Outro par de parâmetros fundamentais são vm.dirty_ratio e vm.dirty_background_ratio. Eles controlam o percentual de memória RAM que pode ficar “suja”, ou seja, com dados modificados ainda não gravados em disco. O vm.dirty_ratio define o limite em que o kernel força a gravação síncrona, podendo causar pausas perceptíveis. O vm.dirty_background_ratio define quando a gravação em segundo plano inicia. Em servidores com discos rápidos (NVMe), aumentar esses valores permite acumular mais escrita e reduzir operações de I/O. Em discos lentos, manter valores baixos evita picos de latência.

O vm.vfs_cache_pressure influencia a retenção de cache de inodes e dentries. O valor padrão é 100. Reduzir para 50 faz o kernel manter esses caches por mais tempo, o que beneficia workloads com muitos acessos a arquivos pequenos, como servidores web estáticos. Aumentar para acima de 100 libera cache mais rápido, útil quando a memória é escassa e os processos ativos precisam de mais espaço. Em servidores de banco de dados, valores entre 50 e 80 costumam trazer bons resultados.

Além desses, existe o vm.overcommit_memory, que controla como o kernel lida com alocação de memória excedente. O valor 0 (padrão) é heurístico, 1 permite overcommit quase ilimitado e 2 restringe com base em limites definidos. Para servidores de banco de dados com cargas previsíveis, o valor 0 é adequado. Para ambientes com muitos processos que alocam memória virtual sem usar, o valor 1 pode evitar falhas de alocação. Não altere vm.overcommit_memory sem medir o impacto, pois pode causar OOM (Out Of Memory) em cenários extremos.

Em sistemas com pouca RAM, o parâmetro vm.min_free_kbytes define a quantidade mínima de memória livre que o kernel tenta manter. O valor padrão é geralmente baixo, como 67584 (cerca de 66 MB). Aumentar para 131072 ou 262144 pode prevenir latências de alocação e deadlocks em picos de carga, mas reduz a RAM útil. Ajuste com cautela, pois valores muito altos em sistemas com pouca RAM podem agravar a pressão de memória. Este é um exemplo clássico de parâmetro que exige medição antes e depois.

Tuning de Performance de Rede

O tuning de performance de rede é indispensável para servidores que recebem milhares de conexões simultâneas. O parâmetro net.core.somaxconn define o tamanho máximo da fila de conexões pendentes para cada socket de escuta. O valor padrão costuma ser 128 ou 4096, que é insuficiente para servidores web de alto tráfego. Aumentar para 65535 permite que o kernel aceite mais conexões em fila antes de recusar novas. Lembre-se de que aplicações como Nginx e HAProxy também têm seus próprios limites de backlog, que devem ser ajustados separadamente.

O net.core.netdev_max_backlog define o tamanho da fila de entrada de pacotes para cada interface de rede. Se você observar incrementos frequentes de backlog em netstat -s, aumente esse valor para 65535. O mesmo vale para os buffers de socket: net.core.rmem_default e net.core.wmem_default definem os tamanhos padrão, enquanto net.core.rmem_max e net.core.wmem_max definem os máximos negociáveis. Para workloads com transferências volumosas, aumentar esses buffers reduz a perda de pacotes e melhora o throughput.

No nível TCP, o net.ipv4.tcp_fin_timeout controla por quanto tempo um socket permanece em FIN_WAIT_2 antes de ser fechado. O padrão é 60 segundos. Reduzir para 15 ou 10 segundos acelera a reciclagem de sockets em servidores com muitas conexões curtas. Já o net.ipv4.tcp_tw_reuse permite reutilizar sockets em TIME_WAIT para novas conexões de saída. Em conjunto, esses dois ajustes reduzem drasticamente o acúmulo de sockets em TIME_WAIT, que é um sintoma comum em servidores web com tráfego intenso.

Outro parâmetro crítico é o net.ipv4.ip_local_port_range, que define a faixa de portas efêmeras usadas para conexões de saída. O padrão em muitas distribuições é 32768 60999, totalizando cerca de 28 mil portas. Em servidores que fazem muitas requisições a serviços externos, aumentar para 1024 65535 fornece mais de 64 mil portas, reduzindo a chance de esgotamento. O net.ipv4.tcp_syncookies deve estar habilitado (valor 1) para mitigar ataques SYN flood. Você pode verificar se está ativo com sysctl net.ipv4.tcp_syncookies.

Para ambientes de alta concorrência, considere também net.ipv4.tcp_max_syn_backlog, que define a fila de conexões SYN pendentes, e net.ipv4.tcp_keepalive_time, que ajusta o intervalo de keepalive. Em servidores de banco de dados que mantêm conexões ociosas, aumentar o keepalive para 300 segundos pode reduzir tráfego desnecessário. Em servidores web atrás de balanceadores, reduzir pode ajudar a detectar conexões mortas mais rápido. A regra de ouro continua: medir antes e depois.

Tuning de Performance de I/O e File System

O subsistema de I/O é frequentemente o gargalo mais negligenciado. O parâmetro fs.file-max define o limite máximo de arquivos abertos em todo o sistema. Em servidores com muitos processos ou sockets (que também contam como descritores de arquivo), o padrão pode ser excedido. Aumente para 2097152 ou mais. Além do limite global, o limite por processo é controlado pelo ulimit -n, que deve ser ajustado em /etc/security/limits.conf. Ambos os limites precisam ser elevados para evitar erros de too many open files.

O parâmetro fs.inotify.max_user_watches é essencial para ferramentas de monitoramento de arquivos, como systemd, Syncthing, Nodemon e VSCode remote. O padrão em desktops é 8192 ou 65536. Para servidores com milhões de arquivos em projetos de desenvolvimento, aumentar para 524288 previne erros de “system limit on number of file watchers reached”. Esse ajuste é rápido e sem efeitos colaterais, sendo um dos primeiros que aplicamos em estações de desenvolvimento na JRT Technology Solutions.

No contexto de tuning de performance de I/O, o escalonador de fila de disco também merece atenção. Em discos mecânicos, o escalonador mq-deadline ou bfq costuma ser adequado. Em discos NVMe, o escalonador none ou noop reduz a sobrecarga de CPU. Você pode verificar com cat /sys/block/sda/queue/scheduler e alterar temporariamente com echo none > /sys/block/sda/queue/scheduler. A persistência pode ser feita via regras udev ou parâmetros de kernel na linha de comando do GRUB.

O parâmetro vm.dirty_expire_centisecs e vm.dirty_writeback_centisecs controlam o intervalo de gravação de páginas sujas. Em servidores de banco de dados com discos rápidos, reduzir o writeback para 100 centisegundos (1 segundo) pode melhorar a consistência, mas aumenta a carga de I/O. Em servidores de arquivos, aumentar para 3000 centisegundos (30 segundos) pode reduzir operações de gravação, aceitando maior risco de perda em caso de falha. Ajuste de acordo com a criticidade dos dados.

Por fim, lembre-se de que o noatime e nodiratime nas opções de montagem do /etc/fstab reduzem gravações desnecessárias de metadados de acesso. Para sistemas com muitos arquivos pequenos acessados com frequência, essa otimização pode trazer ganhos significativos. Você pode verificar as opções atuais com mount | grep ‘ / ‘. Em nossos laboratórios, aplicamos noatime em todos os servidores que não precisam de registro de tempo de acesso por conformidade.

Verificando a Instalação / Testando a Configuração

Após aplicar seus ajustes, a verificação é obrigatória. Não basta ver o valor na tela; você precisa garantir que o parâmetro está ativo e que o comportamento do sistema mudou conforme esperado. Vamos executar uma bateria de comandos de inspeção que confirmam a aplicação correta de cada ajuste.

# 1. Confirmar parâmetros de memória
sysctl vm.swappiness vm.dirty_ratio vm.dirty_background_ratio vm.vfs_cache_pressure

# 2. Confirmar parâmetros de file system
sysctl fs.file-max fs.inotify.max_user_watches

# 3. Confirmar parâmetros de rede
sysctl net.core.somaxconn net.core.netdev_max_backlog net.ipv4.tcp_fin_timeout

# 4. Confirmar portas efêmeras
sysctl net.ipv4.ip_local_port_range

# 5. Verificar estado atual de sockets
ss -s

# 6. Verificar estatísticas de erro de rede
netstat -s | grep -E 'backlog|timewait|syn'

# 7. Verificar uso de swap e cache
free -h

# 8. Verificar I/O de disco (requer sysstat)
iostat -x 1 3

Saída esperada (parcial, para demonstração de sucesso):

$ sysctl vm.swappiness vm.dirty_ratio vm.dirty_background_ratio vm.vfs_cache_pressure
vm.swappiness = 10
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5
vm.vfs_cache_pressure = 50
$ sysctl fs.file-max fs.inotify.max_user_watches
fs.file-max = 2097152
fs.inotify.max_user_watches = 524288
$ sysctl net.core.somaxconn net.core.netdev_max_backlog net.ipv4.tcp_fin_timeout
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65535
net.ipv4.tcp_fin_timeout = 15
$ sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 1024	65535
$ ss -s
Total: 48
TCP:   12 (estab 6, closed 2, orphaned 0, timewait 2)
Transport Total     IP        IPv6
RAW       0         0         0
UDP       2         1         1
TCP       10        6         4
INET      12        7         5
FRAG      0         0         0
$ free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       1.2Gi       1.1Gi        23Mi       1.5Gi       2.4Gi
Swap:          2.0Gi       0.0Gi       2.0Gi

Repare que a saída de ss -s mostra poucos sockets em timewait, o que é excelente para servidores após os ajustes. O free -h mostra swap zerado, confirmando que o swappiness reduzido está funcionando. Caso alguma saída não corresponda ao esperado, revise seu arquivo /etc/sysctl.d/90-tuning.conf e execute sysctl –system novamente, observando mensagens de erro.

Erros Comuns e Como Resolver

Durante o tuning de performance, alguns erros são recorrentes em ambientes de produção. Conhecê-los de antemão evita retrabalho e tempo de indisponibilidade. Abaixo listamos os quatro erros mais frequentes, com causa, sintoma e solução detalhada.

Erro: “sysctl: permission denied on key ‘vm.swappiness'”. Você tentou alterar um parâmetro sem privilégios de root ou sudo. Causa: o comando sysctl -w exige privilégios administrativos. Sintoma: a mensagem aparece imediatamente e o valor não muda. Solução: execute com sudo (sudo sysctl -w vm.swappiness=10) ou troque para o usuário root com sudo -i.
Erro: valor não persiste após reinicialização. Você alterou com sysctl -w, mas não criou o arquivo em /etc/sysctl.d/. Causa: alterações com -w são voláteis. Sintoma: após reboot, o parâmetro volta ao valor padrão. Solução: crie o arquivo /etc/sysctl.d/90-tuning.conf com o valor desejado e execute sudo sysctl –system. Confirme com grep swappiness /etc/sysctl.d/*.conf.
Erro: “sysctl: setting key ‘net.ipv4.ip_local_port_range’: Invalid argument”. O intervalo de portas foi definido com os números invertidos. Causa: o formato exige porta_inferior porta_superior separadas por espaço. Sintoma: o comando falha e não altera o valor. Solução: use sysctl -w net.ipv4.ip_local_port_range=”1024 65535″ ou verifique o arquivo. No arquivo, a linha deve ser net.ipv4.ip_local_port_range = 1024 65535.
Erro: esgotamento de portas efêmeras (“Cannot assign requested address”). Aplicações não conseguem abrir novas conexões de saída. Causa: faixa de portas efêmeras pequena (padrão 32768 a 60999) ou TIME_WAIT excessivo. Sintoma: erros intermitentes em requisições a bancos de dados ou APIs externas. Solução: aumente a faixa com net.ipv4.ip_local_port_range = 1024 65535, habilite net.ipv4.tcp_tw_reuse = 1 e reduza net.ipv4.tcp_fin_timeout = 15. Aplique com sysctl –system.
Erro: fila de conexões estourada em servidor web (“SYN backlog” ou “connection refused”). O Nginx ou Apache recusa conexões em picos. Causa: net.core.somaxconn baixo (128). Sintoma: picos de conexões recusadas, log de erro mostrando backlog excedido. Solução: defina net.core.somaxconn = 65535 e ajuste o backlog da aplicação para 65535. No Nginx, use listen 80 backlog=65535;. Reinicie o serviço e monitore com ss -ltn.

Boas Práticas e Dicas Avançadas

Adotar boas práticas de tuning de performance é o que separa administradores juniores de engenheiros SRE. A primeira boa prática é versionar suas configurações. O arquivo /etc/sysctl.d/90-tuning.conf deve estar sob controle de versão (Git, Ansible, Salt, Puppet). Na JRT Technology Solutions, nossos especialistas gerenciam todas as configurações de infraestrutura com Ansible, incluindo o arquivo sysctl.d. Isso permite reproduzir ambientes idênticos e auditar alterações com facilidade.

Segunda boa prática: teste em staging. Nunca aplique um parâmetro novo diretamente em produção. Use uma VM espelho com carga sintética, como stress-ng, wrk ou pgbench, para simular o workload real. Compare métricas com e sem o ajuste. Só promova para produção quando houver evidência estatisticamente significativa de melhoria. Essa disciplina evita incidentes causados por tuning mal testado.

Terceira boa prática: monitore continuamente. Após promulgar um ajuste, configure alertas para as métricas relevantes, como latência, uso de swap, descarte de pacotes e filas. Ferramentas como Prometheus, Grafana, Zabbix ou Netdata são excelentes. O monitoramento fecha o ciclo de feedback: você saberá se o tuning está funcionando ou se precisa de novos ajustes. Em nossos projetos na JRT Technology Solutions, integramos o node_exporter do Prometheus para expor métricas de kernel e sistema para dashboards.

Quarta boa prática: documente cada alteração. Inclua comentários no próprio arquivo sysctl.d, explicando por que cada valor foi escolhido e a data da mudança. Isso ajuda futuros administradores a entender o racional por trás dos números. Uma linha como # Reduzido em 24/08/2026 após análise de swap em servidor DB vale mais que mil explicações em tickets.

Na parte avançada, exploramos parâmetros de kernel que afetam o escalonamento de CPU, como kernel.sched_migration_cost_ns, kernel.sched_autogroup_enabled e kernel.sched_min_granularity_ns. Esses parâmetros são sensíveis e raramente precisam ser alterados em servidores modernos. Se você sentir necessidade, tenha um conhecimento profundo de escalonamento. Outro tema avançado é o tuning de network namespaces e TC (Traffic Control), que foge do escopo desta aula, mas é essencial para QoS em gateways.

Resumo da Aula 26

Nesta aula você aprendeu os fundamentos do tuning de performance no Linux, desde a exploração de /proc/sys até a criação de arquivos persistentes com sysctl. Cobrimos os principais parâmetros de memória, rede, I/O e kernel, com comandos práticos e saídas reais. A ênfase foi no diagnóstico antes do ajuste, na medição contínua e na segurança de ter tudo versionado e reversível. Você agora tem um arcabouço profissional para otimizar servidores de qualquer carga.

A tabela abaixo resume os parâmetros mais críticos que aprendemos, seus valores típicos de referência e onde se aplicam.