Grootmade@app-node - 11: Recurso temporariamente indisponível

Suporte Instalação
1

Olá a todos,

Estou enfrentando um problema intermitente de quedas de conexão no nó da nossa aplicação Discourse em produção e preciso de algumas orientações de sysadmins ou especialistas em rede de kernel.

Durante picos de tráfego, o Nginx começa a retornar 502 Bad Gateway e as conexões derrubadas se propagam em cascata pelos serviços upstream. Inicialmente, assumi que se tratava de um limite padrão de pool do Postgres/Redis, mas ao verificar a pilha de rede, os indícios apontam para esgotamento de sockets e saturação da tabela conntrack.

O que verifiquei

  • Os limites foram aumentados para 65535 no limits.conf e verificados para os processos em execução.
  • As filas Puma/Sidekiq estão normais e a utilização de CPU está em torno de ~45%.
  • Chamadas de API de saída e handshakes de usuários de entrada ficam pendurados intermitentemente por 10 a 30 segundos.

Abaixo está o histórico bruto do terminal da minha sessão logo após o último pico, mostrando o que verifiquei e os erros lançados:

grootmade@app-node-01:~$ netstat -nat | awk '{print $6}' | sort | uniq -c | sort -n
      4 LAST_ACK
     12 LISTEN
     48 FIN_WAIT2
    312 ESTABLISHED
   8940 TIME_WAIT

grootmade@app-node-01:~$ sysctl net.ipv4.tcp_tw_reuse
net.ipv4.tcp_tw_reuse = 2

grootmade@app-node-01:~$ sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
net.netfilter.nf_conntrack_count = 262140
net.netfilter.nf_conntrack_max = 262144

grootmade@app-node-01:~$ dmesg -T | grep -i conntrack | tail -n 5
[Sun Aug 23 14:10:02 2026] nf_conntrack: nf_conntrack: table full, dropping packet
[Sun Aug 23 14:10:05 2026] nf_conntrack: nf_conntrack: table full, dropping packet
[Sun Aug 23 14:10:12 2026] nf_conntrack: nf_conntrack: table full, dropping packet

grootmade@app-node-01:~$ sudo ss -s
Total: 9648
TCP:   9410 (estab 312, closed 8940, orphaned 0, timewait 8940)

grootmade@app-node-01:~$ cat /proc/sys/net/ipv4/ip_local_port_range
32768	60999

grootmade@app-node-01:~$ ulimit -n
65535

grootmade@app-node-01:~$ cat /proc/sys/fs/file-nr
4128	0	65535

grootmade@app-node-01:~$ sudo iptables -L -n -v | grep -i DROP
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

grootmade@app-node-01:~$ sudo strace -p 1842 -e trace=connect,bind 2>&1 | head -n 10
connect(14, {sa_family=AF_INET, sin_port=htons(5432), sin_addr=inet_addr("10.0.1.25")}, 16) = -1 EAGAIN (Resource temporarily unavailable)

grootmade@app-node-01:~$ cat /etc/security/limits.d/discourse.conf
discourse soft nofile 65535
discourse hard nofile 65535

grootmade@app-node-01:~$ tail -n 20 /var/log/nginx/error.log | grep "failed"
2026/08/23 14:10:15 [crit] 1842#1842: *49102 connect() to 10.0.1.25:5432 failed (11: Resource temporarily unavailable)

grootmade@app-node-01:~$ history | tail -n 13

Minhas perguntas:

  1. Quais são os trade-offs de memória recomendados para escalar nf_conntrack_max para 1048576 em um nó com 16GB de RAM?

  2. Mesmo com tcp_tw_reuse = 2, estamos recebendo EAGAIN em bindings de portas locais para o Postgres. Devemos expandir o ip_local_port_range ou habilitar keep-alives HTTP upstream no Nginx?

  3. Adicionar regras raw de iptables com NOTRACK para tráfego interno de loopback e VPC seria uma correção permanente segura, ou isso introduz problemas ocultos de estado com redes de containers?

Qualquer conselho ou trechos testados em batalha de sysctl.conf seriam muito apreciados!

Obrigado!

2

O Discourse moderno não executa o Puma. Qual versão do Discourse você está usando? Essa é uma instalação não padrão?