Skip to main content

File Descriptors | Linux | NGINX

  • File Descriptors | Linux | NGINX

🔥 Erro: Too many open files while connecting to upstream no Nginx​

📌 Visão geral​

Esse erro ocorre quando o Nginx atinge o limite de arquivos abertos (file descriptors, ou FDs) permitidos pelo sistema operacional. Esse limite não se refere apenas a arquivos de disco, mas também a conexões de rede, sockets TCP, pipes, arquivos de log, etc.

Mensagem de erro típica nos logs do Nginx:

[crit] 852346#852346: accept4() failed (24: Too many open files)

ou:

[error] ... while connecting to upstream, client: x.x.x.x, server: ..., upstream: "http://127.0.0.1:7070", host: ...

🧠 O que está acontecendo?​

🔥 Interpretação​

O erro indica que:

  • O Nginx está tentando aceitar uma nova conexão de entrada ou criar uma nova conexão com um servidor upstream (por exemplo, 127.0.0.1:7070);
  • Porém, o limite de arquivos abertos para o processo foi atingido (erro 24 = EMFILE);
  • O sistema operacional não permite mais abertura de arquivos/sockets naquele processo;
  • Como consequência, o Nginx não consegue se comunicar com o backend, e retorna erro ao cliente.

⚙️ Arquitetura envolvida​

🎯 Linux​

  • Cada processo tem um limite máximo de arquivos abertos, definido por ulimit -n, /etc/security/limits.conf, ou systemd.
  • File descriptors incluem:
    • Conexões com clientes (TCP sockets)
    • Conexões com upstreams (outros servidores ou serviços)
    • Arquivos de log (access.log, error.log)
    • Arquivos de configuração abertos
    • Pipes internos

🧩 Nginx​

  • O Nginx é event-driven, com múltiplos workers, cada um podendo aceitar e lidar com milhares de conexões.
  • Cada worker process precisa de FDs para:
    • Cada socket aceito
    • Cada proxy_pass aberto para upstream
    • Cada log
  • O número total de FDs que ele pode usar depende de:
    • ulimit
    • worker_rlimit_nofile
    • worker_connections

🔧 O que é worker_rlimit_nofile​

worker_rlimit_nofile 65535;

📘 Definição​

É uma diretiva global do Nginx que ajusta o limite de file descriptors que cada processo worker pode abrir. Funciona como um "pedido" ao sistema operacional, e precisa que o sistema permita isso (via ulimit ou systemd).

Sem essa diretiva, mesmo com o ulimit alto, o Nginx pode continuar limitado.

📌 Local correto​

# Fora de todos os blocos
worker_processes auto;
worker_rlimit_nofile 65535;  # ✅ Aqui!

events {
    worker_connections 8192;
}

📐 Relação com worker_connections​

  • worker_connections: define quantas conexões por worker o Nginx pode lidar.
  • worker_rlimit_nofile: define quantos FDs (arquivos/sockets) por worker podem ser usados.

🔢 Recomendação:

worker_rlimit_nofile ≥ worker_connections × worker_processes

🛠 Como aplicar corretamente​

1. Aumentar limites no sistema​

/etc/security/limits.conf​

* soft nofile 65535
* hard nofile 65535

Para serviços systemd​

sudo systemctl edit nginx
[Service]
LimitNOFILE=65535
sudo systemctl daemon-reexec
sudo systemctl restart nginx

2. Ajustar o nginx.conf​

worker_processes auto;
worker_rlimit_nofile 65535;

events {
    worker_connections 8192;
}

3. Validar e reiniciar​

sudo nginx -t
sudo systemctl restart nginx

🔍 Monitoramento e verificação​

🔎 Ver número de FDs usados:​

lsof -u nginx | wc -l

🔎 Ver limite real do processo:​

cat /proc/$(pidof nginx | awk '{print $1}')/limits

✅ Conclusão​

ProblemaSolução
Too many open filesAumentar ulimit, worker_rlimit_nofile e systemd
Nginx não consegue se conectar ao upstreamVerificar se backend está disponível e escalável
Processos ficam sem FDsMonitorar com lsof, ajustar limites de forma coerente

✅ O worker_rlimit_nofile é essencial para liberar o real potencial de paralelismo do Nginx, evitando travamentos em cenários de carga alta.

Artigo​

Blog Pantuza - File Descritors