Grootmade@app-node - 11: Risorsa temporaneamente non disponibile

Supporto Installazione
1

Ciao a tutti,

Sto riscontrando un problema intermittente di perdita di connessione sul nostro nodo di produzione dell’app Discourse e ho bisogno di consigli da sysadmin o esperti di rete kernel.

Durante i picchi di traffico, Nginx inizia a restituire 502 Bad Gateway e le connessioni interrotte si propagano a cascata tra i servizi upstream. Inizialmente, ho ipotizzato che si trattasse di un limite standard del pool Postgres/Redis, ma verificando lo stack di rete, il problema sembra puntare verso l’esaurimento dei socket e la saturazione della tabella conntrack.

Cosa ho verificato

  • I limiti sono stati portati a 65535 in limits.conf e verificati per i processi in esecuzione.
  • Le code Puma/Sidekiq sono normali, l’utilizzo della CPU si aggira intorno al ~45%.
  • Le chiamate API in uscita e le strette di mano degli utenti in ingresso si bloccano intermittentemente per 10–30 secondi.

Di seguito è riportato lo storico grezzo del terminale della mia sessione subito dopo l’ultimo picco, che mostra ciò che ho controllato e gli errori generati:

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

Le mie domande:

  1. Quali sono i compromessi di memoria consigliati per scalare nf_conntrack_max a 1048576 su un nodo con 16GB di RAM?

  2. Anche con tcp_tw_reuse = 2, stiamo ottenendo EAGAIN sui binding delle porte locali verso Postgres. Dovremmo espandere ip_local_port_range o abilitare le keep-alive HTTP upstream in Nginx?

  3. L’aggiunta di regole raw iptables NOTRACK per il traffico interno loopback e VPC sarebbe una soluzione permanente sicura, o introduce problemi di stato nascosti con le reti container?

Qualsiasi consiglio o frammento di sysctl.conf collaudato in battaglia sarebbe profondamente apprezzato!

Grazie!

2

La versione moderna di Discourse non utilizza Puma. Quale versione di Discourse stai utilizzando? Si tratta di un’installazione non standard?