Utilizei este sysctl.conf por um bom tempo em servidores, desde databases (mysql, mariadb) a web servers (nginx, apache).
Basicamente é uma otimização, hardening tunning do sysctl para servidores Linux, onde já apliquei em SuSE (Open e Enterprise), Debian (6, 7 e 8), CentOS (6 e 7), Amazon Linux (1 e 2) e Ubuntu.
Possuía uma aplicação web numa VM que recebia um grande volume de conexões dos clientes, com o pico, geralmente travava e/ou parava de responder a novas conexões, aumentar os recursos da VM estava fora de cogitação, esta config do sysctl conseguiu suportar e resolver os alarmes que havia em relação ao servidor e manteve-se assim por mais uns 2 anos sem precisar alterar o hardware da VM e suportando o aumento de clientes.
Claramente, a config do sysctl para otimizar o seu Linux deve vir acompanhado de uma otimização das configurações do serviço em questão (apache, nginx, caddy, mysql, …), num próximo post eu compartilho uma config padrão que utilizava para novos servidores web e banco de dados.
Personalize esta config de acordo com o volume de CPUs e RAM do seu servidor! Pois dependendo pode ser muito (vai parar de responder em algum momento) ou não o suficiente e manter o mesmo padrão de comportamento.
Postei como gist/snippet no github e gitlab
Este script já me salvou e poupou stress em diversos casos, um dos que mais recordo foi prestando uma consultoria na qual o cliente estava com seu serviço degradado e com um possível ataque DDoS em andamento. Seu produto era uma instância (ec2 na AWS) com o front no Apache, pico de CPU e RAM, sem acesso ao host (ssh). Os demais recursos (banco, …) não estavam sendo afetados.
Após reiniciar e conseguir o acesso, habilitei a depuração de logs do sistema, apache, tcpdump, kdump, dentre outras ferramentas para analise. O host não possuía memoria swap, criei o arquivo de swap e adicionei esta configuração do sysctl.
Com o swap, ao esgotar a memória disponível, o apache não tinha o comportamento estranho e com a analise do trafego, chamadas dos clientes e o bom e velho (mais bom do que velho) tcpdump, conclui que era um comportamento anormal da aplicação nos clientes que estavam onerando este apache (quando o client não conseguia chegar no servidor, ele entrava em modo ‘furioso’ e ficava tentando - mesmo sem ter nada para atualizar ou sem ação de usuário - logo, após alguns segundos de falha no tempo de resposta o servidor tinha milhares de clients tentando conectar a qualquer custo).
#CONTEUDO PARA O SYSCTL.CONF
# Aumentar o num. max de conex tcp orfans
# Conexões que foram encerrados e já não têm um identificador de arquivo anexado a eles
net.ipv4.tcp_max_orphans = 262144
# Aumentar o número de conexões
net.core.somaxconn = 16384
# Aumentar o número de conexões de entrada backlog
# O número máximo de pacotes que podem ser enfileirados na entrada da interface
# Se o kernel está recebendo pacotes mais rápido do que podem ser processados
# Esta fila aumenta
net.core.netdev_max_backlog = 16384
# Máximo para Socket Receive Buffer (16Mb)
net.core.rmem_max = 16777216
# Padrão de envio de socket Buffer (16Mb)
net.core.wmem_max = 16777216
# Aumentar a alocação para tamanho maximo
net.ipv4.tcp_wmem = 4096 12582912 16777216
net.ipv4.tcp_rmem = 4096 12582912 16777216
# Aumentar o número de pedidos pendentes syn permitidos
net.ipv4.tcp_max_syn_backlog = 8096
# Para conexões HTTP persistentes
net.ipv4.tcp_slow_start_after_idle = 0
# Aumentar o tamanho de tcp-TIME-WAIT para evitar ataques de DOS simples
net.ipv4.tcp_tw_reuse = 1
# Range de portas para conexão
net.ipv4.ip_local_port_range = 1024 65535
fs.file-max = 2097152
#
fs.inotify.max_user_watches=524288
# Timeout - fechamento de conexões TCP após 7 segundos
net.ipv4.tcp_fin_timeout = 7
# Evitar cair de volta para retardar início depois que uma conexão estiver inativo
# Mantém nosso cwnd grande com as conexões de Atividade
net.ipv4.tcp_slow_start_after_idle = 0
# Só repetir a criação de conexões TCP duas vezes
# Minimizar o tempo que leva para que uma tentativa de conexão falhe
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2
# As unidades estão em tamanho de página (tamanho da página padrão é 4 KB)
# Estas são variáveis globais que afetam total de páginas para os socketes TCP
# 8388608 * 4 = 32 GB
# Quando o mem atribuído pelo TCP excede a "pressão", o kernel irá transferir a memória TCP
# Coloca os valores altos para evitar basicamente qualquer pressão mem nunca ocorra
net.ipv4.tcp_mem = 8388608 8388608 8388608
# Aumenta/limita o número máximo de soquetes permitido em TIME_WAIT
net.ipv4.tcp_max_tw_buckets = 6000000
# Aumenta/limita conexões max semi-aberto.
net.ipv4.tcp_max_syn_backlog = 65536
# Diminuir o uso de swap
# caso não tenha swap, dependendo do tipo de serviço no servidor,
# coloque ao menos alguns megabytes:
# siga este how-to:
# https://esli.blog.br/ram-e-swap
vm.swappiness = 5
vm.dirty_ratio = 10
vm.dirty_background_ratio = 5
# baseado no Tuning da Netflix para as EC2 com Ubuntu:
# https://www.slideshare.net/brendangregg/performance-tuning-ec2-instancesFontes, com a versão sempre atualizada: gist no GitHub e snippet no GitLab