Grootmade@app-node - 11: Recurso temporalmente no disponible

Soporte Instalación
1

Hola a todos,

Estoy atascado con un problema intermitente de pérdida de conexiones en nuestro nodo de producción de la aplicación Discourse y necesito consejos de administradores de sistemas o expertos en redes del kernel.

Durante los picos de tráfico, Nginx comienza a devolver 502 Bad Gateway y las conexiones interrumpidas se propagan en cascada a los servicios upstream. Al principio, asumí que se trataba de un límite estándar de la piscina de Postgres/Redis, pero al revisar la pila de red, los indicios apuntan a una agotamiento de sockets y a la saturación de la tabla conntrack.

Lo que he verificado

  • Los límites están aumentados a 65535 en limits.conf y verificados para los procesos en ejecución.
  • Las colas de Puma/Sidekiq son normales, la utilización de CPU se mantiene en torno al ~45%.
  • Las llamadas a la API saliente y los handshakes de usuario entrante se cuelgan intermitentemente durante 10–30 segundos.

A continuación, el historial crudo de la terminal de mi sesión justo después del último pico, mostrando lo que revisé y los errores lanzados:

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

Mis preguntas:

  1. ¿Cuáles son los compromisos de memoria recomendados para escalar nf_conntrack_max a 1048576 en un nodo con 16 GB de RAM?

  2. Incluso con tcp_tw_reuse = 2, estamos obteniendo EAGAIN en los enlaces de puertos locales a Postgres. ¿Debemos ampliar ip_local_port_range o habilitar las keep-alives HTTP upstream en Nginx?

  3. ¿Sería una solución permanente segura añadir reglas iptables raw NOTRACK para el tráfico interno de loopback y VPC, o ¿introduce problemas de estado ocultos con las redes de contenedores?

¡Se agradecería mucho cualquier consejo o fragmentos probados de sysctl.conf!

¡Gracias!

2

Discourse moderno no ejecuta Puma. ¿Qué versión de Discourse estás ejecutando? ¿Es una instalación no estándar?