{"id":18577,"date":"2026-03-31T11:51:02","date_gmt":"2026-03-31T09:51:02","guid":{"rendered":"https:\/\/webhosting.de\/server-ulimits-hosting-grenzen-serverressourcen-ultimativ\/"},"modified":"2026-03-31T11:51:02","modified_gmt":"2026-03-31T09:51:02","slug":"server-ulimits-hosting-graenser-serverresurser-ultimate","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/server-ulimits-hosting-grenzen-serverressourcen-ultimativ\/","title":{"rendered":"Server Ulimits i hosting: optimera fil- och processgr\u00e4nser"},"content":{"rendered":"<p><strong>Server Ulimits<\/strong> steuern im Hosting ganz konkret, wie viele Dateien und Prozesse Ihre Dienste gleichzeitig offen halten d\u00fcrfen, und entscheiden damit \u00fcber Latenz, Fehlermeldungen und Verf\u00fcgbarkeit. Ich zeige Schritt f\u00fcr Schritt, wie ich Datei- und Prozessgrenzen messe, anpasse und \u00fcberwache, damit Webserver selbst unter Last <strong>zuverl\u00e4ssig<\/strong> arbeiten.<\/p>\n\n<h2>Zentrale Punkte<\/h2>\n\n<ul>\n  <li><strong>Soft\/Hard<\/strong> Limits verstehen und passend setzen<\/li>\n  <li><strong>nofile<\/strong> (Dateien) und <strong>nproc<\/strong> (Prozesse) gezielt erh\u00f6hen<\/li>\n  <li><strong>PHP-FPM<\/strong> und Warteschlangen richtig konfigurieren<\/li>\n  <li><strong>Monitoring<\/strong> nutzen und Engp\u00e4sse erkennen<\/li>\n  <li><strong>Security<\/strong> mit sinnvollen Obergrenzen wahren<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/server-umlimits-hosting-4829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ulimits kurz erkl\u00e4rt: Soft vs. Hard<\/h2>\n\n<p>Ich setze Ulimits ein, um pro Benutzer oder Prozess verl\u00e4ssliche <strong>Grenzen<\/strong> f\u00fcr Ressourcen zu definieren. Soft Limits sind die aktuellen, ver\u00e4nderbaren Grenzen, die ich bis zur Hard-Grenze anheben darf, wenn die Anwendung kurzfristig mehr Spielraum braucht. Die Hard Limits stellen die absolute Obergrenze dar und verhindern unkontrolliertes Wachstum einzelner Dienste, das den gesamten Host in Mitleidenschaft zieht. Standardm\u00e4\u00dfig bezieht sich der ulimit-Befehl ohne Schalter auf die Hard-Grenze, was Anpassungen f\u00fcr Administratoren mit Rechten erleichtert. So verhindere ich, dass ein einzelnes Skript durch zu viele Dateien oder Prozesse den Server <strong>\u00fcberlastet<\/strong>.<\/p>\n\n<p>Ich unterscheide dabei immer die wichtigsten Parameter wie <strong>nofile<\/strong> (offene Dateien), <strong>nproc<\/strong> (Prozesse\/Threads), fsize (Dateigr\u00f6\u00dfe), stack (Stack-Gr\u00f6\u00dfe) und cpu (CPU-Zeit). Gerade Web-Stacks mit PHP, Datenbank und Cache-Komponenten ben\u00f6tigen oft deutlich mehr offene Deskriptoren, als die minimalen Defaultwerte vorsehen. Ohne korrekte Limits h\u00e4ufen sich Meldungen wie \u201etoo many open files\u201c, lange Antwortzeiten oder Timeouts bei Anfragen. Ich messe die tats\u00e4chliche Nutzung zuerst, erh\u00f6he Limits schrittweise und pr\u00fcfe danach Latenz, Fehlerz\u00e4hler und Durchsatz. So sichere ich unter hohen Zugriffen konsistente <strong>Antwortzeiten<\/strong>.<\/p>\n\n<h2>Warum Limits im Hosting entscheidend sind<\/h2>\n\n<p>Hosting-Umgebungen teilen Hardware-Ressourcen, daher verhindere ich mit passenden Limits unfairen Ressourcenzugriff durch einzelne Konten oder Dienste und halte die <strong>Performance<\/strong> stabil. In Einstiegspl\u00e4nen begrenzt man etwa gleichzeitige CGI-\/PHP-Prozesse und die CPU-Zeit pro Nutzer, damit ein fehlerhafter Cronjob nicht den gesamten Host ausbremst. In h\u00f6heren Pl\u00e4nen d\u00fcrfen mehr Prozesse laufen und mehr RAM gebunden werden, was anspruchsvollen Anwendungen wie Shops zugutekommt. Ich bewerte daf\u00fcr die Prozessanzahl, RAM pro Prozess und CPU-Zeit immer gemeinsam, damit keine k\u00fcnstlichen Engstellen zur\u00fcckbleiben. Einen ausf\u00fchrlichen Praxisrahmen zu fairen Ressourcen liefere ich im Beitrag zu <a href=\"https:\/\/webhosting.de\/ressourcen-limits-shared-hosting-cpu-ram-io-praxis-kapazitaet\/\">Shared-Hosting Limits<\/a>, der die Zusammenh\u00e4nge kompakt <strong>ordnet<\/strong>.<\/p>\n\n<p>Auch die <strong>file<\/strong> descriptor limit ist kritisch, weil jede offene Datei, jeder Socket und jede Pipe einen Descriptor bindet. Standardwerte von 1024 sind f\u00fcr moderne Webanwendungen oft zu klein, gerade wenn viele gleichzeitige Verbindungen anliegen. Ich lese darum zuerst reale Spitzen aus Logs und Tools ab, bevor ich Werte erh\u00f6he, damit ich die Auswirkungen auf Kernel-Tabellen und Speicherdruck kenne. So erh\u00f6he ich den Durchsatz, ohne die Sicherheit und Reaktionsf\u00e4higkeit des Hosts zu riskieren. Wer das Prinzip versteht, meidet zuf\u00e4llige Ausf\u00e4lle durch zu enge <strong>Schranken<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/server_optimierung_meeting_2831.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Die wichtigsten Parameter im Alltag: nofile, nproc und Co.<\/h2>\n\n<p>F\u00fcr webnahe Workloads steht <strong>nofile<\/strong> ganz oben, weil HTTP-Verbindungen, Upstream-Sockets und Datenbank-Verbindungen massiv Deskriptoren verbrauchen. Ich plane Puffer f\u00fcr Spitzenlast ein, zum Beispiel das Zwei- bis Vierfache des typischen Peaks, damit kurze Traffic-Wellen nicht sofort zu Fehlern f\u00fchren. F\u00fcr Worker-basierte Services skaliere ich nofile parallel zur Worker-Zahl und deren maximalen Verbindungen. Kommt ein CDN, Reverse Proxy oder Messaging-Layer dazu, steigt der Bedarf nochmals, was ich bei der Kalkulation genau ber\u00fccksichtige. Erst mit sauberem Puffer verschwinden sporadische \u201eopen file\u201c-Fehler und die <strong>Fehlerrate<\/strong> sinkt.<\/p>\n\n<p>Beim <strong>nproc<\/strong>-Limit betrachte ich Prozesse und Threads gemeinsam, weil einige Laufzeiten Thread-Pools nutzen, die gegen die Obergrenze z\u00e4hlen. Ich pr\u00fcfe Spawn-Strategien von Webservern, App-Servern und Datenbank, damit die Obergrenze nicht unbemerkt greift und neue Worker blockiert. Zu niedrige nproc-Werte zeigen sich oft als schleppender Start von Diensten oder als Warteschlangen, die nicht abarbeiten. Ich erh\u00f6he die Grenze passend zur CPU-Kernzahl, zur IO-Last und zur Architektur der Anwendung. So bleibt der Spawn-Prozess kalkulierbar und verhindert starre <strong>Blockaden<\/strong>.<\/p>\n\n<h2>Ulimits pr\u00fcfen: so lese ich die Realit\u00e4t aus<\/h2>\n\n<p>Ich beginne jede Optimierung mit Sichtbarkeit, denn ohne Zahlen bleiben Ma\u00dfnahmen <strong>blind<\/strong>. Der Befehl ulimit -a zeigt mir die aktuellen Limits der Shell-Session und liefert damit die Basis f\u00fcr Abgleiche mit Service-Konfigurationen. Ich pr\u00fcfe separat nofile und nproc, weil genau diese Werte im Hosting zuerst an ihre Grenzen sto\u00dfen. Zus\u00e4tzlich setze ich lsof, ss oder netstat ein, um offene Dateien und Sockets pro Prozess zu z\u00e4hlen. Erst wenn ich die Spitze unter Produktionslast kenne, plane ich Puffer und verleibe sie in die <strong>Grenzwerte<\/strong> ein.<\/p>\n\n<pre><code># Alle Limits einer Session\nulimit -a\n\n# Datei-Deskriptoren (Soft\/Hard)\nulimit -n\nulimit -Hn\n\n# Prozesse\/Threads pro Benutzer\nulimit -u\nulimit -Hu\n<\/code><\/pre>\n\n<p>F\u00fcr Dienste, die systemd startet, schaue ich nicht nur auf meine interaktive Shell, denn systemd setzt eigene <strong>Limits<\/strong>. Ich vergleiche daher die effektiven Werte eines laufenden Prozesses \u00fcber \/proc\/&lt;pid&gt;\/limits, um Widerspr\u00fcche zwischen Shell und Dienst zu entlarven. Abweichungen deuten auf fehlende Einstellungen in Unit-Files hin, die ich dann direkt erg\u00e4nze. Dieser Abgleich spart mir langes R\u00e4tseln, warum eine App trotz h\u00f6herer Shell-Limits keine zus\u00e4tzlichen Dateien \u00f6ffnen darf. So finde ich Konfigurationsl\u00fccken z\u00fcgig und sorge f\u00fcr konsistente <strong>Rahmen<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/server-optimierung-ulimits-4736.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Tempor\u00e4r anpassen: schnelle Tests in laufenden Sessions<\/h2>\n\n<p>Bevor ich Limits dauerhaft setze, teste ich in einer Shell gezielt h\u00f6here <strong>Werte<\/strong>. So sehe ich ohne Neustart, ob die Anwendung wie erwartet mehr Verbindungen aufnimmt oder die Latenz sinkt. Erh\u00f6hte Werte gelten in dieser Session, bis ich sie schlie\u00dfe oder den Dienst neu starte. Ich dokumentiere die Wirkung auf syslog, Error-Logs und Metriken, damit sp\u00e4tere Daueranpassungen fundiert sind. Kurze Versuche ersparen mir gro\u00dfe Rollbacks und liefern belastbare <strong>Belege<\/strong>.<\/p>\n\n<pre><code># Tempor\u00e4r in der aktuellen Shell\nulimit -n 65536     # Datei-Deskriptoren anheben\nulimit -u 4096      # Prozess-\/Thread-Grenze erh\u00f6hen\n\n# Hard-Limits explizit pr\u00fcfen\/anpassen (Root)\nulimit -Hn 131072\nulimit -Hu 8192\n<\/code><\/pre>\n\n<p>Ich f\u00fchre solche Tests zu Zeiten geplanter Lastspitzen aus, um reale Effekte zu <strong>sehen<\/strong>. Wenn die Fehler \u201etoo many open files\u201c aufh\u00f6ren und die Anfragenzahl pro Sekunde steigt, halte ich die Messwerte fest. Bleibt die Auswirkung gering, suche ich Parallelbremsen wie zu enge Socket-Backlogs, Worker-Grenzen im Webserver oder Datenbank-Connection-Pools. Erst wenn die gesamte Kette skaliert, zahlt sich ein h\u00f6heres ulimit server sauber aus. So verhindere ich Teiloptimierungen, die am Ende keine sp\u00fcrbare <strong>Verbesserung<\/strong> bringen.<\/p>\n\n<h2>Dauerhaft konfigurieren: limits.conf und systemd<\/h2>\n\n<p>F\u00fcr dauerhafte Werte editiere ich \/etc\/security\/limits.conf und erg\u00e4nze user- oder service-spezifische <strong>Zeilen<\/strong>. Ich unterscheide Soft- und Hard-Grenzen, damit Anwendungen kurzfristig hochelastisch bleiben, aber dennoch eine klare Oberkante besitzen. Bei systemd-Diensten setze ich zus\u00e4tzlich LimitNOFILE und LimitNPROC, weil Unit-Files ansonsten Shell-\u00c4nderungen \u00fcbergehen. Nach dem Anpassen lade ich systemd neu und starte die betroffenen Dienste, damit die neuen Grenzwerte greifen. Der Neustart ist wichtig, sonst verharren Prozesse in alten <strong>Rahmenwerten<\/strong>.<\/p>\n\n<pre><code># \/etc\/security\/limits.conf (Beispiel)\n*          soft    nofile   65536\n*          hard    nofile   131072\nwww-data   soft    nproc    4096\nwww-data   hard    nproc    8192\n\n# systemd-Unit (z.B. \/etc\/systemd\/system\/nginx.service.d\/limits.conf)\n[Service]\nLimitNOFILE=65536\nLimitNPROC=4096\n\n# \u00c4nderungen aktivieren\nsystemctl daemon-reload\nsystemctl restart nginx\n<\/code><\/pre>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Kontext<\/strong><\/th>\n      <th><strong>Ort<\/strong><\/th>\n      <th><strong>G\u00fcltigkeit<\/strong><\/th>\n      <th><strong>Typisch<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Interaktive Session<\/td>\n      <td>ulimit in Shell<\/td>\n      <td>Nur aktuelle Shell\/Childs<\/td>\n      <td>Schnelle Versuche<\/td>\n    <\/tr>\n    <tr>\n      <td>Systemweit Benutzer<\/td>\n      <td>\/etc\/security\/limits.conf<\/td>\n      <td>Login-\/PAM-basierte Prozesse<\/td>\n      <td>Dauerhafte Basis<\/td>\n    <\/tr>\n    <tr>\n      <td>Dienste (systemd)<\/td>\n      <td>Unit-File: LimitNOFILE\/LimitNPROC<\/td>\n      <td>Nur betroffener Service<\/td>\n      <td>Klare Service-Grenzen<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/server_ulimits_optimierung_9876.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Systemweite Kernel-Grenzen richtig einordnen<\/h2>\n\n<p>Neben prozess- und benutzerbezogenen Ulimits existieren systemweite Caps, die ich stets gegenpr\u00fcfe. Selbst ein hohes nofile n\u00fctzt nichts, wenn der Kernel die globale Datei-Deskriptortabelle knapp h\u00e4lt. Ich kontrolliere deshalb fs.file-max (gesamt m\u00f6gliche offenen FDs) und fs.nr_open (maximal pro Prozess erlaubte FDs auf Kernel-Ebene). Passen diese Werte nicht, sto\u00dfe ich trotz angehobener Ulimits fr\u00fch an Grenzen.<\/p>\n\n<pre><code># Systemweite Grenzen pr\u00fcfen\ncat \/proc\/sys\/fs\/file-max\ncat \/proc\/sys\/fs\/nr_open\ncat \/proc\/sys\/fs\/file-nr   # In-Use, Free, Max\n\n# Tempor\u00e4r anheben (bis zum Reboot)\nsysctl fs.file-max=2097152\n\n# Dauerhaft (in \/etc\/sysctl.d\/99-ulimits.conf)\nfs.file-max = 2097152\n<\/code><\/pre>\n\n<p>Ich beachte die Kaskade: Prozess-Limit (RLIMIT_NOFILE) \u2264 fs.nr_open \u2264 fs.file-max (global). Wird nofile \u00fcber fs.nr_open gesetzt, ignoriert der Kernel den Wunsch still. Entsprechend dimensioniere ich global, dann pro Service. F\u00fcr accept-Backlogs skaliere ich zus\u00e4tzlich net.core.somaxconn und die Backlog-Parameter der jeweiligen Dienste, sonst verhungern ankommende Verbindungen weiterhin in der Warteschlange.<\/p>\n\n<h2>systemd-Feinheiten: TasksMax, PIDsMax und DefaultLimits<\/h2>\n\n<p>Auf modernen Distributionen limitiert systemd nicht nur Deskriptoren, sondern auch die Anzahl der Tasks (Prozesse\/Threads) pro Service via <strong>TasksMax<\/strong>. Ich setze bei hohen Concurrency-Setups angemessene Werte oder nutze \u201einfinity\u201c, wenn ich die Kontrolle an nproc \u00fcbergebe. F\u00fcr Benutzer-Services hilft <strong>user@.service<\/strong> beziehungsweise <strong>system.conf<\/strong> mit DefaultLimit*-Schaltern, um Baseline-Werte konsistent zu heben.<\/p>\n\n<pre><code># Service-Drop-in f\u00fcr mehr Tasks und FD\nmkdir -p \/etc\/systemd\/system\/php-fpm.service.d\ncat &lt;&lt;'EOF' &gt; \/etc\/systemd\/system\/php-fpm.service.d\/limits.conf\n[Service]\nLimitNOFILE=131072\nLimitNPROC=8192\nTasksMax=16384\nEOF\n\nsystemctl daemon-reload\nsystemctl restart php-fpm\n\n# Systemweite Defaults (vorsichtig einsetzen)\n# \/etc\/systemd\/system.conf\nDefaultLimitNOFILE=65536\nDefaultLimitNPROC=4096\nDefaultTasksMax=8192\n<\/code><\/pre>\n\n<p>Wichtig: sudo, su und SSH-Logins erben Limits unterschiedlich. F\u00fcr PAM-basierte Logins greift \/etc\/security\/limits.conf, f\u00fcr nicht-login Shells oder Cronjobs hingegen oft nicht. Ich teste daher immer den kompletten Pfad, \u00fcber den mein Dienst startet, damit keine stillen Abweichungen \u00fcbrig bleiben.<\/p>\n\n<h2>Webserver gemeinsam mit Ulimits skalieren<\/h2>\n\n<p>Bei NGINX verkn\u00fcpfe ich worker_processes, worker_connections und <strong>worker_rlimit_nofile<\/strong> mit den systemweiten Limits. Faustregel: Maximale gleichzeitige Verbindungen \u2248 worker_processes \u00d7 worker_connections, zuz\u00fcglich Reserve f\u00fcr Upstreams, Logs und interne Pipes. Ohne angehobenes worker_rlimit_nofile l\u00e4uft NGINX trotz hoher ulimits fr\u00fch in EMFILE.<\/p>\n\n<pre><code># NGINX-Beispiel (Ausschnitt)\nworker_processes auto;\nevents {\n    worker_connections 40960;\n    multi_accept on;\n    use epoll;\n}\nworker_rlimit_nofile 131072;\n<\/code><\/pre>\n\n<p>Bei Apache (MPM event) achte ich auf ServerLimit, ThreadsPerChild und MaxRequestWorkers. Steigt die Summe der m\u00f6glichen Verbindungen, muss nofile parallel wachsen. Andernfalls f\u00fcllen sich Warteschlangen, obwohl CPU und RAM noch Luft h\u00e4tten. Zus\u00e4tzlich passe ich die listen-Backlogs (z. B. bei NGINX: listen &#8230; backlog=&#8230;) und Kernel-somaxconn an, damit neue Accepts nicht abgeworfen werden.<\/p>\n\n<h2>Datenbanken und Caches: offene Dateien richtig budgetieren<\/h2>\n\n<p>Datenbanken und Caches haben eigene Stellschrauben: MySQL\/MariaDB nutzen <strong>open_files_limit<\/strong> und Connection-Parameter, PostgreSQL profitiert von Connection-Pooling davor, w\u00e4hrend Redis die Zahl der Clients direkt in offene FDs \u00fcbersetzt. Ich stelle sicher, dass die jeweiligen Dienste auf ein nofile treffen, das \u00fcber ihren internen Maximalwerten liegt. Sonst schlagen Start oder Lastspitzen fehl, obwohl der Applikations-Layer skaliert wurde.<\/p>\n\n<p>Ein typisches Muster: PHP-FPM erh\u00f6ht die Parallelit\u00e4t, aber der DB-Server bleibt auf alten FD-Limits und Connection-Caps. Ich messe pro Komponente offene Handles und lege die Puffer additiv aus. So verhindere ich, dass ein nachgelagerter Dienst die Gesamtperformance kastriert.<\/p>\n\n<h2>Container und Orchestrierung: Ulimits im Docker\/Kubernetes-Kontext<\/h2>\n\n<p>In Containern wirken Ulimits unabh\u00e4ngig vom Host-Login-Kontext. Ich setze sie explizit beim Start oder in der Orchestrierung und beachte zus\u00e4tzlich cgroups-Grenzen (PIDs, Memory). Im Docker-Umfeld definiere ich nofile\/nproc und optional eine PIDs-Grenze. Kubernetes kapselt das \u00fcber SecurityContext und RuntimeClass-spezifische Optionen; je nach Umgebung m\u00fcssen Ulimits via Container Runtime gesetzt werden.<\/p>\n\n<pre><code># Docker lokal\ndocker run --ulimit nofile=131072:131072 \\\n           --ulimit nproc=8192:8192 \\\n           --pids-limit 20000 \\\n           --name webapp -p 80:80 myimage:latest\n\n# Docker Compose (Ausschnitt)\nservices:\n  app:\n    image: myimage:latest\n    ulimits:\n      nofile:\n        soft: 65536\n        hard: 131072\n      nproc: 8192\n    pids_limit: 20000\n<\/code><\/pre>\n\n<p>Ich verifiziere Limits im Container stets via \/proc\/self\/limits und beobachte, dass Host-Anpassungen wie limits.conf nicht automatisch in Containerprozesse diffundieren. Transparenz schaffe ich mit klaren, versionskontrollierten Deploy-Parametern pro Dienst.<\/p>\n\n<h2>Fehlersuche in der Praxis: EMFILE, EAGAIN und langsame Spawns<\/h2>\n\n<p>F\u00fcr reproduzierbare Analysen setze ich strace ein und suche nach EMFILE (\u201eToo many open files\u201c) oder EAGAIN (\u201eResource temporarily unavailable\u201c) beim accept(), open(), pipe() oder clone(). Ich z\u00e4hle FDs pro Prozess regelm\u00e4\u00dfig und vergleiche mit den gesetzten Limits. Leaks bei Filehandles (z. B. vergessene Close()-Aufrufe) erkenne ich so schneller.<\/p>\n\n<pre><code># Offene FDs pro Prozess ermitteln\nls -l \/proc\/&lt;pid&gt;\/fd | wc -l\n\n# Systemweite Nutzung im Blick\ncat \/proc\/sys\/fs\/file-nr\n\n# strace auf FD-Fehler trimmen\nstrace -fp &lt;pid&gt; -e trace=desc,process,network 2&gt;&amp;1 | grep -E 'EMFILE|EAGAIN'\n<\/code><\/pre>\n\n<p>Startprobleme durch zu enge nproc-Limits enttarnen sich \u00fcber langsames Hochfahren, \u201ecan&#8217;t fork\u201c-Meldungen oder unvollst\u00e4ndige Worker-Pools. Ich korreliere diese Ereignisse mit Spawn-Strategien (Pre-Fork, Dynamic, On-Demand), damit Anpassungen nicht nur Symptome lindern, sondern die Architektur st\u00fctzen.<\/p>\n\n<h2>Automatisierung, Tests und Rollback<\/h2>\n\n<p>Ich halte Limit-\u00c4nderungen reproduzierbar: Drop-ins f\u00fcr systemd, sysctl.d-Dateien und Service-Templates pflege ich deklarativ. Jede \u00c4nderung erh\u00e4lt ein Ticket, Messwerte vor\/nachher und ein klares Rollback. In Staging simuliere ich Auslastung mit Tools wie wrk, vegeta oder k6 und achte dabei auf P95\/P99-Latenzen, Error-Rates und Queue-Zeiten. Erst belastbare Ergebnisse rechtfertigen eine Ausweitung in Produktion.<\/p>\n\n<pre><code># Drop-in-Ger\u00fcst f\u00fcr mehrere Services erstellen\nfor s in nginx php-fpm redis; do\n  mkdir -p \/etc\/systemd\/system\/$s.service.d\n  cat &lt;&lt;EOF &gt; \/etc\/systemd\/system\/$s.service.d\/limits.conf\n[Service]\nLimitNOFILE=65536\nLimitNPROC=4096\nTasksMax=8192\nEOF\ndone\nsystemctl daemon-reload\nsystemctl restart nginx php-fpm redis\n<\/code><\/pre>\n\n<p>Bei Kampagnen schalte ich Limits kontrolliert hoch, notiere Start-\/Endzeit und vergleiche sie mit Traffic-Kurven. Nach dem Peak f\u00fchre ich die konservativeren Werte wieder ein, um die Angriffsfl\u00e4che zu minimieren und ungenutzte Kernel-Ressourcen freizugeben.<\/p>\n\n<h2>Verwechslungsgefahr: Ulimits vs. Watcher\/Kernel-Parameter<\/h2>\n\n<p>Nicht jeder \u201ezu viele Dateien\u201c-Fehler r\u00fchrt von nofile her. Dateisystem-Watcher (inotify) besitzen eigene Grenzen (z. B. max_user_watches), die bei vielen kleinen Dateien oder Entwicklungs-Stacks schnell erreicht werden. Auch vm.max_map_count (z. B. f\u00fcr Such-Engines) oder net.ip_local_port_range (Ephemeral Ports) k\u00f6nnen als begrenzende Faktoren wirken. Ich pr\u00fcfe solche Parameter separat, damit ich nicht am falschen Regler drehe.<\/p>\n\n<h2>PHP-FPM richtig dimensionieren: Prozesse, Warteschlangen, Limits<\/h2>\n\n<p>Bei PHP-FPM koordiniere ich pm.max_children, pm.max_requests und die ulimit-Grenzen, damit Prozessstart, Speicher und <strong>Verbindungen<\/strong> ausgewogen bleiben. Wenn FPM seine Obergrenze erreicht, landen Anfragen in einer Queue; das ist gewollt, aber nur sinnvoll, wenn der Webserver Timeouts und Backoff sauber behandelt. Ich messe die durchschnittliche Ausf\u00fchrungszeit und leite daraus eine tragf\u00e4hige Prozesszahl ab, die CPU und RAM nicht \u00fcberzieht. Dazu passe ich das file descriptor limit an, damit parallele Upstream-Verbindungen und Log-Writer gen\u00fcgend Spielraum haben. Wer tiefer einsteigt, findet hier praktische Stellschrauben f\u00fcr <a href=\"https:\/\/webhosting.de\/php-fpm-prozess-management-pm-max-children-optimieren-core\/\">PHP-FPM Prozesse<\/a> und ermittelt die beste <strong>Balance<\/strong>.<\/p>\n\n<p>Ich pr\u00fcfe au\u00dferdem, wie viele Datenbank-Connections pro FPM-Worker gleichzeitig offen bleiben, damit Connection-Pools nicht zum <strong>Nadel\u00f6hr<\/strong> werden. Zu gro\u00dfe Worker-Zahlen erh\u00f6hen RAM-Druck und Kontextwechsel, zu kleine stagnieren den Durchsatz. Deshalb skaliere ich in Stufen, beobachte Latenz-P50\/P95 und Fehlschl\u00e4ge, und justiere in kleinen Schritten. Erst wenn Queue-Zeiten, CPU-Load und Fehlerraten im Lot sind, fixiere ich die Werte dauerhaft. So l\u00e4uft der Stack vorhersagbarer und bleibt unter Last <strong>reaktionsschnell<\/strong>.<\/p>\n\n<h2>Monitoring und Kapazit\u00e4tsplanung<\/h2>\n\n<p>Ich belege jeden Schritt mit Messdaten, sonst wirken \u00c4nderungen an Limits nur <strong>gef\u00fchlt<\/strong>. Metriken wie offene Dateien pro Prozess, laufende und wartende Requests, CPU-Sekunden pro Worker und RSS-Speicher helfen mir bei der Einordnung. Logs zeigen mir, wann die Hard-Grenzen greifen und ob Dienste deswegen Verbindungen verweigern. Dashboards mit P95\/P99-Latenzen entlarven Engp\u00e4sse, die Durchschnittswerte kaschieren. Aus all dem leite ich ein praktikables process limit hosting ab, das die Auslastung gl\u00e4ttet und Warteschlangen <strong>verk\u00fcrzt<\/strong>.<\/p>\n\n<p>Ich halte mir stets Reserved Headroom frei, damit kurze Peaks keine St\u00f6rungen <strong>erzeugen<\/strong>. Wer auf Monats- oder Kampagnen-Spitzen zusteuert, hebt Limits ein bis zwei Wochen vorher an und pr\u00fcft reale Traffic-Tests. Danach reaktiviere ich engere Grenzen wieder, um Ressourcen und Angriffsfl\u00e4chen klein zu halten. Dieser Rhythmus sch\u00fctzt die Plattform wirtschaftlich und senkt gleichzeitig das St\u00f6rungsrisiko. Planung zahlt sich hier mehrfach aus, weil proaktive Schritte Servicefenster und <strong>Uptime<\/strong> sichern.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/server_ulimits_szene_4213.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Inodes und Dateianzahl: leise Limits mit gro\u00dfer Wirkung<\/h2>\n\n<p>Neben nofile limitiert das Dateisystem die Anzahl an <strong>Inodes<\/strong> und damit die m\u00f6gliche Anzahl von Dateien, unabh\u00e4ngig vom belegten Speicher. Webprojekte mit vielen kleinen Cache-Dateien oder Session-Files schlagen hier schnell an. Ich pr\u00fcfe df -i, r\u00e4ume alte Artefakte, Rotationsreste und Temp-Verzeichnisse auf und passe bei Bedarf den Aufbau des Dateisystems an. Wer CMS-Caches konsolidiert oder in-memory legt, entlastet Inodes und IO-Druck gleichzeitig. Details, Hintergr\u00fcnde und Strategien binde ich in meinen Leitfaden zu <a href=\"https:\/\/webhosting.de\/filesystem-inodes-hosting-grenzen-serverdatei\/\">Inodes verstehen<\/a> ein, der das Thema f\u00fcr Hosting-Praxen <strong>aufschlie\u00dft<\/strong>.<\/p>\n\n<p>Wenn Inodes knapp sind, n\u00fctzt ein h\u00f6heres file descriptor limit alleine <strong>nichts<\/strong>. Ich sorge deshalb f\u00fcr klare Logrotation, begrenze Debug-Verbosity und verschiebe selten genutzte Artefakte in Archivspeicher. Auch Build-Pipelines sollten Artefakte aufr\u00e4umen, damit Deployments nicht schleichend die Inode-Reserven auffressen. Solche Hygiene h\u00e4lt Limits langfristig stabil und spart bei der Fehlersuche viel Zeit. Ein sauberer Blick auf Inodes verhindert unerwartete <strong>Stillst\u00e4nde<\/strong>.<\/p>\n\n<h2>Typische Fehlermeldungen gezielt beheben<\/h2>\n\n<p>Die Meldung \u201etoo many open files\u201c signalisiert mir fast immer ein zu knappes <strong>nofile<\/strong>. Ich erh\u00f6he tempor\u00e4r in der Shell, best\u00e4tige den Effekt und ziehe die Werte dann in limits.conf und systemd nach. Wenn \u201eresource temporarily unavailable\u201c beim Spawnen erscheint, liegt es oft am nproc-Limit, das ich passend zur Worker-Architektur erh\u00f6he. H\u00e4ngen PHP-Skripte scheinbar, pr\u00fcfe ich zus\u00e4tzlich memory_limit, max_execution_time und die CPU-Sekunden, die das Hosting-Setup f\u00fcr CGI\/FPM gew\u00e4hrt. Ich behebe Engp\u00e4sse entlang der Kette und verhindere, dass ein Schalter an einer Stelle nur neue <strong>Bremsen<\/strong> an anderer Position erzeugt.<\/p>\n\n<p>Treffen diese Fehler sporadisch auf, arbeite ich mit Metrik-Korrelationen, um den Zeitpunkt und die Lastsituation zu <strong>erwischen<\/strong>. Spitzen in gleichzeitigen Verbindungen, erh\u00f6hte Backend-Fehler oder lange DNS-Lookups liefern gute Hinweise. Ich pr\u00fcfe dann die Limits der betroffenen Dienste separat, um effektive Werte zu identifizieren. Stimmt die Konfiguration, aber die Fehler bleiben, suche ich nach Leaks bei Filehandles, defekten Watchern oder unn\u00f6tigen offenen Sockets. Schrittweise Eingrenzung spart Zeit und reduziert das <strong>Risiko<\/strong> erneuter Ausf\u00e4lle.<\/p>\n\n<h2>Leistung und Sicherheit klug austarieren<\/h2>\n\n<p>Ich erh\u00f6he Limits nie grenzenlos, weil zu weite \u00d6ffnungen Angriffsfl\u00e4chen <strong>vergr\u00f6\u00dfern<\/strong>. Brute-Force- oder DoS-Szenarien profitieren von zu hohen Grenzen, wenn keine weiteren Kontrollen greifen. Daher kombiniere ich Limits mit Rate Limiting, Backoff-Strategien und klaren Timeouts im Webserver und Upstream. Ich lege harte Oberkanten so, dass legitime Spitzen passieren, Missbrauch aber nicht eskalieren kann. So sichere ich Verf\u00fcgbarkeit, ohne die <strong>Kontrolle<\/strong> zu verlieren.<\/p>\n\n<p>Im Alltag zahlt sich ein abgestuftes Konzept aus: etwas Headroom f\u00fcr Peaks, messbare Wirkung, und regelm\u00e4\u00dfige <strong>Reviews<\/strong>. Wer Deployments, Traffic-Kampagnen und saisonale Lasten kennt, plant Limits proaktiv. Jede \u00c4nderung dokumentiere ich mit Datum, Grund und Messwerten, damit sp\u00e4tere Analysen nicht im Dunkeln tappen. Dieser Katalog beschleunigt k\u00fcnftige Entscheidungen und verhindert Doppelarbeit. Performance und Sicherheit profitieren, weil Entscheidungen auf <strong>Daten<\/strong> basieren.<\/p>\n\n<h2>Hosting-Pakete bewerten: worauf achte ich?<\/h2>\n\n<p>Ich pr\u00fcfe Hosting-Angebote nicht nur nach CPU und RAM, sondern explizit nach <strong>Ulimits<\/strong> f\u00fcr Prozesse, Deskriptoren und CPU-Sekunden. Konkrete Angaben zu nproc, nofile und ggf. Inode-Kontingenten helfen mir, Kapazit\u00e4t richtig einzusch\u00e4tzen. F\u00fcr Shops und APIs fordere ich transparente Zusagen f\u00fcr PHP-FPM-Prozesse, CPU-Budgets und Limit-Erh\u00f6hung auf Anfrage. VPS- oder Dedicated-Umgebungen geben mir die Hoheit, doch auch dort z\u00e4hlen sinnvolle Defaultwerte f\u00fcr den Betrieb. Klare Zahlen verhindern Entt\u00e4uschungen und halten Migrationen <strong>geradlinig<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Plan<\/strong><\/th>\n      <th><strong>Prozesslimit (nproc)<\/strong><\/th>\n      <th><strong>Dateien (nofile)<\/strong><\/th>\n      <th><strong>RAM\/Prozess<\/strong><\/th>\n      <th><strong>CPU-Zeit<\/strong><\/th>\n      <th><strong>Eignung<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Einsteiger<\/td>\n      <td>32\u201364<\/td>\n      <td>4096\u20138192<\/td>\n      <td>256\u2013512 MB<\/td>\n      <td>5\u2013600 s<\/td>\n      <td>Kleine Sites<\/td>\n    <\/tr>\n    <tr>\n      <td>Business<\/td>\n      <td>64\u2013128<\/td>\n      <td>16384\u201365536<\/td>\n      <td>512\u20131024 MB<\/td>\n      <td>600\u20133600 s<\/td>\n      <td>Shops, APIs<\/td>\n    <\/tr>\n    <tr>\n      <td>VPS\/Dedicated<\/td>\n      <td>Konfigurierbar<\/td>\n      <td>Konfigurierbar<\/td>\n      <td>Nach Bedarf<\/td>\n      <td>Nach Bedarf<\/td>\n      <td>Hohe Last<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/serverraum-optimierung-9847.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kurz zusammengefasst<\/h2>\n\n<p>Ich messe zuerst reale Nutzung, dann hebe ich <strong>Grenzen<\/strong> stufenweise an und pr\u00fcfe die Wirkung auf Latenz, Fehlerrate und Durchsatz. Kernschalter sind nofile f\u00fcr Dateien\/Sockets und nproc f\u00fcr Prozesse\/Threads, erg\u00e4nzt um fsize, stack und cpu. Dauerhafte Werte setze ich konsistent in limits.conf und in systemd-Units, damit Dienste identische Rahmenbedingungen vorfinden. F\u00fcr PHP-FPM stimme ich Prozesszahlen, Speicher und Warteschlangen eng auf das file descriptor limit ab. Monitoring, Inode-Hygiene und sinnvolle Oberkanten halten Hosting-Setups unter Last <strong>verl\u00e4sslich<\/strong> und reaktionsfreudig.<\/p>","protected":false},"excerpt":{"rendered":"<p>Optimera serverns ulimits i hosting: file descriptor limit, process limit hosting och ulimit server f\u00f6r stabil prestanda.<\/p>","protected":false},"author":1,"featured_media":18570,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-18577","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"499","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Server Ulimits","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"18570","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/18577","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/comments?post=18577"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/18577\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/18570"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=18577"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=18577"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=18577"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}