File Descriptor (FD) Limits sind eine zentrale Stellschraube, wenn es darum geht, Webserver wie Nginx für hohe gleichzeitige Verbindungen zu skalieren. Jeder offene Socket, jede geöffnete Datei oder Pipe verbraucht ein File Descriptor. Standardmäßig ist die Zahl der FDs pro Prozess begrenzt, was bei hohen Lasten schnell zu “too many open files” Fehlern führt. In diesem Tutorial betrachten wir, wie ulimit, systemd und Nginx zusammenarbeiten, um stabile High-Concurrency-Setups zu ermöglichen.

Grundlagen von File Descriptors

Ein File Descriptor ist eine nicht-negative Ganzzahl, die vom Betriebssystem genutzt wird, um auf geöffnete Dateien, Sockets oder Pipes zu verweisen. Typischerweise gibt es:

• 0 – Standard Input (stdin)
• 1 – Standard Output (stdout)
• 2 – Standard Error (stderr)

Jeder weitere geöffnete Socket, z. B. eine HTTP-Verbindung, verbraucht einen FD. Bei 10.000 gleichzeitigen Verbindungen werden also mindestens 10.000 File Descriptors benötigt.

Systemweite Limits vs. Prozess-Limits

Linux unterscheidet zwischen systemweiten und prozessbezogenen FD-Limits:

• fs.file-max: Maximale Anzahl von FDs für das gesamte System
• ulimit/rlimit: Limits pro Prozess oder User

Abfragen der aktuellen Limits

# Systemweite maximale FDs
cat /proc/sys/fs/file-max
Limits für den aktuellen User
ulimit -n

ulimit korrekt setzen

Die einfachste Methode, um FD-Limits zu erhöhen, ist über ulimit in der Shell oder in Startskripten. Für Nginx oder andere Server ist jedoch zu beachten, dass der Prozess seine eigenen Limits beim Start übernimmt.

Beispiel: FD-Limit erhöhen

# Temporär für die Shell
ulimit -n 65535
Dauerhaft in /etc/security/limits.conf
nginx  soft  nofile  65535

nginx  hard  nofile  65535

Wichtig: Ein zu hoher Wert kann das System belasten, daher sollte die Zahl realistisch an die erwartete Last angepasst werden.

systemd und FD-Limits

Auf modernen Systemen wird Nginx oft als systemd-Service gestartet. Hier überschreibt systemd die ulimit-Werte in den Unit-Dateien.

Beispiel für systemd Service-Override

# Erstellen Sie ein Override-Verzeichnis
sudo systemctl edit nginx
Fügen Sie folgende Zeilen ein:
[Service]

LimitNOFILE=65535
Service neu laden und starten
sudo systemctl daemon-reexec

sudo systemctl restart nginx

Damit stellen Sie sicher, dass Nginx beim Start die gewünschten Limits erhält.

Nginx-spezifische Einstellungen

Nginx nutzt Worker-Prozesse, die jeweils FDs benötigen. Neben den Systemlimits gibt es auch Konfigurationen in Nginx:

worker_rlimit_nofile

Mit dieser Direktive können Sie Nginx anweisen, die FD-Limits der Worker zu erhöhen:

worker_processes auto;
worker_rlimit_nofile 65535;
events {

worker_connections 10240;

}

Die maximal möglichen gleichzeitigen Verbindungen berechnet sich ungefähr so:

Max Connections = worker_processes * worker_connections

Monitoring von File Descriptors

Vor und nach dem Tuning ist Monitoring entscheidend:

• Prozess-FDs anzeigen: lsof -p <pid>
• Gesamte offene FDs im System: cat /proc/sys/fs/file-nr
• Alerting bei Annäherung an Limits über Tools wie Prometheus/node_exporter

Tipps für High Concurrency

• Setzen Sie sowohl systemweite als auch prozessbezogene Limits passend zur Last.
• Für Nginx gilt: worker_rlimit_nofile >= worker_connections * worker_processes.
• Nutzen Sie systemd-Overrides für persistente Konfigurationen.
• Testen Sie unter Last, um echte Limitierung und Engpässe zu erkennen.
• Berücksichtigen Sie andere Ressourcen wie RAM, da jeder offene Socket Speicher benötigt.

Praktisches Beispiel: Nginx auf 50.000 gleichzeitige Verbindungen

worker_processes 4;
worker_rlimit_nofile 65535;
events {

worker_connections 12800;

}

Berechnung: 4 Worker * 12800 Connections = 51.200 gleichzeitige Verbindungen theoretisch möglich.

Fazit

File Descriptor Limits sind ein oft unterschätzter Faktor für skalierbare Webserver. Die Kombination aus ulimit, systemd-Overrides und Nginx-spezifischen Einstellungen erlaubt es, High-Concurrency-Setups zuverlässig zu betreiben. Wichtig ist die Überwachung und iterative Anpassung an reale Lastszenarien, statt pauschaler Werte.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.