Grootmade@app-node - 11: Ресурс временно недоступен

Поддержка Самостоятельное хостинг
1

Привет, все,

Я упёрся в стену из-за периодических обрывов соединений на нашем продукционном узле приложения Discourse и нуждаюсь в совете от системных администраторов или экспертов по сетевому стеку ядра.

Во время всплесков трафика Nginx начинает возвращать 502 Bad Gateway, а обрывы соединений каскадно распространяются по вышестоящим сервисам. Сначала я предположил, что это стандартное ограничение пула соединений Postgres/Redis, но проверка сетевого стека указывает на исчерпание сокетов и насыщение таблицы conntrack.

Что я проверил

  • Лимиты подняты до 65535 в limits.conf и проверены для запущенных процессов.
  • Очереди Puma/Sidekiq в норме, загрузка CPU держится на уровне ~45%.
  • Исходящие API-вызовы и входящие рукопожатия пользователей периодически зависают на 10–30 секунд.

Ниже приведена сырая история терминала из моей сессии сразу после последнего всплеска, показывающая то, что я проверял, и возникшие ошибки:

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

Мои вопросы:

  1. Каковы рекомендуемые компромиссы по использованию памяти при увеличении nf_conntrack_max до 1048576 на узле с 16 ГБ ОЗУ?

  2. Даже с tcp_tw_reuse = 2 мы получаем EAGAIN при привязке локальных портов к Postgres. Следует ли расширить ip_local_port_range или включить HTTP keep-alives на стороне Nginx для вышестоящих сервисов?

  3. Будет ли добавление правил raw iptables с флагом NOTRACK для внутреннего loopback-трафика и трафика VPC безопасным постоянным решением, или это влечёт за собой скрытые проблемы с состоянием в контейнерных сетях?

Любые советы или проверенные на практике фрагменты sysctl.conf будут очень ценны!

Спасибо!

2

Современная версия Discourse не использует Puma. Какую версию discourse вы используете? Это нестандартная установка?