Grootmade@app-node - 11: Ressource vorübergehend nicht verfügbar

Unterstützung Installation
1

Hallo zusammen,

ich stoße bei einem intermittierenden Verbindungsabbruch auf unserem Produktions-Discourse-App-Node an eine Wand und bräuchte Ratschläge von Sysadmins oder Kernel-Netzwerk-Experten.

Während Traffic-Spitzen beginnt Nginx, 502 Bad Gateway-Fehler zurückzugeben, und die abgebrochenen Verbindungen kaskadieren über die Upstream-Dienste. Zuerst vermutete ich eine Standard-Postgres-/Redis-Poolbegrenzung, aber die Prüfung des Netzwerkstcks deutet auf Socket-Erschöpfung und Sättigung der conntrack-Tabelle hin.

Was ich bereits überprüft habe

  • Die Limits wurden in limits.conf auf 65535 erhöht und für laufende Prozesse verifiziert.
  • Die Puma-/Sidekiq-Warteschlangen sind normal, die CPU-Auslastung liegt bei ca. 45 %.
  • Ausgehende API-Aufrufe und eingehende Benutzer-Handshakes hängen intermittierend für 10–30 Sekunden.

Nachfolgend die rohe Terminalhistorie meiner Sitzung direkt nach dem letzten Spike, die zeigt, was ich geprüft und welche Fehler aufgetreten sind:

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

Meine Fragen:

  1. Welche empfohlenen Speicher-Trade-offs gibt es, um nf_conntrack_max auf einem Node mit 16 GB RAM auf 1048576 zu skalieren?

  2. Selbst mit tcp_tw_reuse = 2 erhalten wir EAGAIN bei lokalen Port-Bindings zu Postgres. Sollen wir ip_local_port_range erweitern oder HTTP-Keep-Alives upstream in Nginx aktivieren?

  3. Würde das Hinzufügen von NOTRACK-Raw-iptables-Regeln für internen Loopback- und VPC-Traffic eine sichere dauerhafte Lösung darstellen, oder führt es zu versteckten Zustandsproblemen in Container-Netzwerken?

Jeder Ratschlag oder bewährte sysctl.conf-Snippets wäre sehr willkommen!

Danke!

2

Modern Discourse does not run Puma. Which version of Discourse are you running? Is this a non-standard installation?