NGINX-Proxy-Sockets planen, bevor worker_connections erhöht wird
Eine proxied Verbindung belegt meist einen Client- und einen Upstream-Socket; unterscheiden Sie das Worker-Verbindungslimit vom Dateideskriptorlimit des Dienstes.
Eine langlebige proxied Verbindung belegt meist zwei Sockets: den des Clients und den des Upstreams. worker_connections zählt beide Seiten. Eine Multiplikation mit worker_processes verspricht daher keine Kapazität für Proxy-Nutzer.
Wenn Verbindungen fehlschlagen, folgen Sie dem gemeldeten Limit:
| Beleg | Zu prüfende Einstellung oder Prozesszustand |
|---|---|
| Erschöpfung von worker_connections | Das Verbindungsbudget des Workers einschließlich Upstream-Sockets |
| Betriebssystemmeldung „Zu viele offene Dateien“ | Das Dateideskriptorlimit, das der tatsächliche Dienstprozess erbt |
Auch Listening-Sockets, Logs und andere offene Dateien verbrauchen Deskriptoren. Verbindungswiederverwendung und der Traffic-Mix verändern das Verhältnis zwischen Nutzern und Sockets.
worker_rlimit_nofile passt die Worker-Limits im Rahmen der Umgebungsberechtigungen an. Eine systemd-Unit kann LimitNOFILE setzen; ulimit einer interaktiven Shell ändert den laufenden Dienst nicht.
Bemessen Sie die Limits an der Arbeitslast und prüfen Sie, wer sie verbraucht. Unerwartete Clients oder wiederholt scheiternde Upstream-Verbindungen können ein zuvor ausreichendes Budget erschöpfen. Ein höheres Prozess- oder Speicherlimit behebt keinen Deskriptormangel.