Ulimit no Linux: localizar um limite de arquivos antes que um serviço caia

Um serviço que de repente recusa novas conexões ou escreve “Too many open files” não necessariamente tem um problema de memória. Pode ter atingido seu limite de descritores de arquivos. No Linux, um socket, um log, um arquivo e às vezes um pipe consomem um descritor.

O comando ulimit -n exibe o limite do shell atual. Ele não prova o limite do serviço já iniciado. Para um daemon gerenciado por systemd, verifique o processo, a unidade e a configuração persistente antes de mudar qualquer coisa.

Ler o limite do shell e o do processo

No seu terminal, comece por distinguir o limite suave do limite duro. O primeiro pode ser reduzido por um processo. O segundo define o teto que um usuário não privilegiado não pode ultrapassar.

ulimit -Sn
ulimit -Hn

Um resultado de 1024 pode ser suficiente para uma sessão interativa. Ele rapidamente se torna curto para um proxy, um servidor web ou uma aplicação que mantém muitas conexões abertas. Não copie um valor encontrado em um fórum: comece medindo o que o serviço utiliza.

Identifique seu PID e, em seguida, leia os limites realmente aplicados:

systemctl show nginx -p MainPID
sudo grep 'Max open files' /proc/1234/limits
sudo ls /proc/1234/fd | wc -l

Substitua 1234 pelo PID retornado pelo systemd. O contador em /proc/1234/fd fornece uma fotografia do número de descritores abertos. Compare-o com Max open files. Uma discrepância reduzida explica melhor uma saturação do que uma simples impressão de lentidão.

Controlar o limite do systemd antes de modificá-lo

Um serviço do systemd não recupera automaticamente o valor da sua sessão SSH. A unidade pode definir LimitNOFILE, ou herdar um valor global. Exiba o valor efetivo:

systemctl show nginx -p LimitNOFILE
systemctl cat nginx

Se a unidade exibir um limite baixo e os logs confirmarem erros de abertura, crie uma sobreposição em vez de modificar o arquivo fornecido pelo pacote:

sudo systemctl edit nginx

Em seguida, adicione esta seção, com um valor dimensionado para sua aplicação:

[Service]
LimitNOFILE=65535

Para um serviço exposto em produção, mantenha uma segunda sessão SSH aberta. Um erro na unidade ou uma reinicialização mal-sucedida não deve deixá-lo sem acesso. Verifique também a documentação da aplicação: algumas impõem seu próprio teto, distinto do systemd.

Reiniciar e verificar o valor realmente considerado

Após a sobreposição, recarregue a configuração e reinicie apenas o serviço em questão:

sudo systemctl daemon-reload
sudo systemctl restart nginx
systemctl show nginx -p LimitNOFILE
systemctl status nginx --no-pager

Leia novamente /proc/PID/limits com o novo PID. Se LimitNOFILE for 65535 no systemd, mas o processo permanecer em 1024, você provavelmente está olhando para um PID antigo, um serviço diferente ou um supervisor intermediário.

Os controles a serem feitos antes de aumentar o limite

• Confirme o erro exato em journalctl -u nginx ou nos logs da aplicação.
• Meça o número de descritores abertos antes e depois de um pico de carga.
• Aumente o limite para uma unidade específica, não para todos os serviços da máquina.
• Monitore as conexões, arquivos e sockets que permanecem abertos: um vazamento de descritores se corrige na aplicação.

Um limite mais alto evita a parada abrupta de um serviço, mas não repara um processo que abre arquivos sem fechá-los. Mantenha os valores observados e os trechos de logs: eles permitirão decidir se o limite estava muito baixo ou se o serviço precisa ser corrigido.