Como aumentar os limites de conexões simultâneas no Linux

O que acontece quando o Linux fica sem conexões simultâneas

Quando um servidor web de alta performance começa a receber milhares de acessos simultâneos, ele eventualmente esbarra em uma barreira invisível imposta pelo sistema operacional. Esse limite muitas vezes resulta no temido erro de 'Too many open files', que paralisa aplicações inteiras. Na prática, isso significa que o sistema operacional atingiu a quantidade máxima de descritores de arquivos permitidos para um processo ou usuário. Como no Linux tudo é tratado como arquivo — inclusive conexões de rede, sockets TCP e pipes —, abrir uma nova aba no navegador ou receber uma requisição HTTP consome preciosos descritores dessa tabela interna.

Para administradores de sistemas que mantêm servidores sob intensa carga, entender como gerenciar esses recursos é tão fundamental quanto aprender a limpar o cache do systemd journal e liberar disco no Linux para evitar gargalos de armazenamento. Sem a devida configuração, mesmo uma máquina com dezenas de gigabytes de memória RAM e processadores robustos vai recusar novas conexões de rede simplesmente porque a burocracia interna do kernel impediu a abertura de novos descritores. Resolver esse problema exige mexer em três camadas distintas: o comando de controle de recursos por sessão, a configuração dos serviços e os parâmetros globais do sistema operacional.

Como funciona o comando ulimit e seus limites

O comando ulimit é a ferramenta tradicional do Linux para consultar e definir limites de recursos para processos iniciados no terminal. Ele lida com dois conceitos fundamentais: o limite brando, conhecido como soft limit, que atua como um aviso ou teto flexível que o processo pode tentar ultrapassar, e o limite rígido, chamado de hard limit, que representa o teto absoluto imposto pelo administrador e que jamais pode ser superado pelo processo sem intervenção de privilégios elevados.

Para verificar quais são os limites atuais da sua sessão atual, basta executar um comando rápido no terminal. Na prática, isso revela o teto de descritores que o seu usuário pode abrir simultaneamente. Veja o exemplo prático de consulta:

ulimit -n

O retorno desse comando exibe um número inteiro, como 1024, que representa a quantidade máxima de arquivos e conexões de rede que o seu usuário consegue gerenciar de uma só vez. Se a sua aplicação web ultrapassar esse número de clientes conectados, novas conexões serão sumariamente rejeitadas, gerando falhas para os usuários finais. No entanto, alterar o valor com ulimit -n 65535 apenas resolve o problema temporariamente para aquela sessão interativa específica, desaparecendo assim que você fecha a janela do terminal ou reinicia a sessão de login.

Como ajustar os limites permanentes no limits.conf

Para garantir que os servidores e aplicações iniciem sempre com os limites ajustados de forma definitiva, é necessário configurar os arquivos de segurança do sistema operacional. O arquivo principal para essa finalidade fica localizado no diretório de configuração de segurança do PAM, o subsistema de autenticação do Linux. Nele, podemos definir regras específicas para usuários comuns ou para o sistema inteiro.

Abra o arquivo de configuração com um editor de texto com privilégios de superusuário e adicione as diretrizes necessárias para elevar o teto de arquivos abertos. Na prática, você define tanto o limite brando quanto o rígido para o usuário que executa a aplicação, como o usuário do servidor web Nginx ou Apache. Veja como estruturar a alteração:

*               soft    nofile  65535
*               hard    nofile  65535
www-data        soft    nofile  100000
www-data        hard    nofile  100000

Esse ajuste garante que qualquer usuário comum receba um limite de 65.535 descritores, enquanto o usuário específico www-data receba um teto ainda maior de 100.000 conexões simultâneas. Contudo, vale notar que em distribuições Linux modernas que utilizam o systemd como gerenciador de inicialização, essas regras tradicionais podem ser ignoradas por serviços executados como daemons isolados, exigindo um passo adicional de configuração diretamente nas unidades de serviço do systemd.

Como configurar o systemd para ignorar o ulimit padrão

O systemd revolucionou a inicialização de sistemas Linux, mas também introduziu novas camadas de isolamento que frequentemente pegam administradores de surpresa. Serviços modernos executados pelo systemd rodam em seus próprios namespaces e ignoram completamente os limites configurados no arquivo limits.conf. Se você aumentou o limite no arquivo anterior e percebeu que o seu serviço web continua travando com o mesmo erro de descritores esgotados, o culpado quase com certeza é o isolamento de recursos do systemd.

Para corrigir esse comportamento indesejado em um serviço específico, como o Nginx ou um processo em Node.js, é preciso criar um arquivo de substituição chamado override. Esse mecanismo permite alterar diretrizes sem modificar o arquivo original fornecido pelo pacote do sistema. Veja como abrir o editor de configuração para o seu serviço:

sudo systemctl edit nginx

Dentro do editor que se abrirá, você deve inserir a diretiva responsável por forçar o novo teto de descritores de arquivos diretamente na inicialização daquele serviço específico. Na prática, isso diz ao gerenciador de sistema para abrir a torneira de recursos para o processo em questão. Adicione o seguinte bloco de texto:

[Service]
LimitNOFILE=100000
LimitNOFILE=100000:100000

Depois de salvar o arquivo, é necessário recarregar as configurações do gerenciador e reiniciar o serviço para que a alteração entre em vigor imediatamente. Para validar se a modificação funcionou, você pode inspecionar os limites ativos do processo em tempo de execução usando ferramentas de inspeção do próprio systemd. Essa verificação garante que a aplicação não voltará a falhar sob picos repentinos de tráfego de rede.

Como ajustar os parâmetros globais do kernel com sysctl

Além de ajustar os limites por usuário e por serviço, o próprio kernel do Linux possui travas globais que controlam a quantidade total de arquivos abertos em todo o sistema operacional. Se a soma dos descritores de todos os processos ativos atingir esse teto global, nenhuma nova aplicação conseguirá abrir arquivos ou sockets, independentemente dos limites individuais configurados anteriormente.

Para visualizar o limite global atual do sistema, você pode consultar a árvore de diretórios virtuais do kernel através de um comando simples no terminal. Na prática, esse número representa a saúde de todo o ecossistema de E/S do sistema operacional. Veja como fazer a verificação:

cat /proc/sys/fs/file-max

Se esse valor parecer baixo para a capacidade do seu hardware — por exemplo, em servidores corporativos com centenas de gigabytes de RAM —, ele deve ser aumentado permanentemente no arquivo de configuração de parâmetros do kernel. Abra o arquivo de configuração sysctl para edição com o comando adequado e adicione a nova diretriz global:

sudo nano /etc/sysctl.conf

Adicione a seguinte linha no final do documento para elevar o teto global do sistema de arquivos para um patamar seguro de alta carga:

fs.file-max = 2097152

Para aplicar a alteração imediatamente sem precisar reiniciar a máquina inteira, execute o comando que recarrega as configurações do kernel. Essa prática garante que o sistema operacional aceite novos pools de conexões simultâneas de forma estável e sem interrupções nos serviços em produção. Para complementar essa implementação em produção, vale conferir também nossas análises técnicas sobre Como testar o chip Super I/O na placa-mãe com multímetro e Como configurar VLAN por porta em switch TP-Link de forma simples.

sudo sysctl -p

Considerações Finais

Gerenciar conexões simultâneas em servidores Linux exige uma visão holística que vai desde o comportamento de processos individuais até as restrições impostas pelo núcleo do sistema operacional. O esgotamento de descritores de arquivos é um dos problemas mais comuns em ambientes de alta carga, mas pode ser totalmente evitado com o planejamento adequado das camadas de configuração do ulimit, do systemd e dos parâmetros globais do kernel.

Adotar uma rotina de monitoramento desses limites garante que sua infraestrutura permaneça resiliente mesmo diante de picos inesperados de tráfego ou campanhas de acesso massivo. Manter esses ajustes documentados e testados em ambientes de homologação evita surpresas desagradáveis e assegura que seus serviços web entreguem a máxima disponibilidade e performance esperadas pelos usuários.