{"id":18128,"date":"2026-03-06T08:39:37","date_gmt":"2026-03-06T07:39:37","guid":{"rendered":"https:\/\/webhosting.de\/kernel-tuning-linux-sysctl-parameter-serverboost-opti\/"},"modified":"2026-03-06T08:39:37","modified_gmt":"2026-03-06T07:39:37","slug":"kernel-tuning-linux-sysctl-parameter-serverboost-opti","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/kernel-tuning-linux-sysctl-parameter-serverboost-opti\/","title":{"rendered":"Kerneltuning in Linux hosting: Sysctl parameters in een oogopslag"},"content":{"rendered":"<p><strong>Kernel-Tuning<\/strong> im Linux-Hosting bringt messbare Performance-Gewinne, weil ich gezielt sysctl-Parameter f\u00fcr Netzwerk, Speicher, CPU und Sicherheit anpasse. Dabei lade ich Profile ohne Neustart und stimme Werte auf Workloads, Concurrency und I\/O-Verhalten ab, damit der <strong>Server<\/strong> unter Last schnell reagiert und verl\u00e4sslich arbeitet.<\/p>\n\n<h2>Zentrale Punkte<\/h2>\n\n<ul>\n<li><strong>sysctl<\/strong> steuert Kernel-Verhalten zur Laufzeit<\/li>\n<li><strong>Netzwerk<\/strong> optimieren: Backlogs, Sockets, TCP<\/li>\n<li><strong>Speicher<\/strong> trimmen: Swapping, Dirty Pages<\/li>\n<li><strong>CPU<\/strong> feintunen: Scheduler, PIDs<\/li>\n<li><strong>Sicherheit<\/strong> h\u00e4rten ohne Overhead<\/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\/linux-hosting-kernel-4892.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Was ist sysctl im Linux-Hosting?<\/h2>\n\n<p>Mit <strong>sysctl<\/strong> lese und \u00e4ndere ich Kernel-Parameter zur Laufzeit, ohne den Kernel zu kompilieren. Die Werte liegen als Dateien im Verzeichnis \/proc\/sys, etwa net\/ipv4\/tcp_max_syn_backlog, und steuern Netzwerk, Speicher und Sicherheit. F\u00fcr Hosting-Workloads mit vielen Verbindungen reduziert das direkte Tuning Latenzspitzen und Zeitouts. Ich \u00e4ndere tempor\u00e4r mit sysctl -w und schreibe dauerhafte Profile in \/etc\/sysctl.d\/*.conf. Danach lade ich alles mit sysctl &#8211;system und pr\u00fcfe dmesg sowie Journal-Logs, damit ich Fehlkonfigurationen schnell erkenne.<\/p>\n\n<h2>So wende ich sysctl sicher an<\/h2>\n\n<p>Vor \u00c4nderungen sichere ich <strong>Profile<\/strong> und dokumentiere Ist-Werte mit sysctl -a, damit ich jederzeit zur\u00fcckrollen kann. Ich teste neue Werte zuerst auf Staging-VMs mit vergleichbarer Last. Danach erh\u00f6he ich Parameter schrittweise, beobachte Metriken und passe erneut an. So verhindere ich OOM-Kills, Socket-Drops und sporadische Retransmits. F\u00fcr reproduzierbare Setups lege ich eine eigene Datei wie \/etc\/sysctl.d\/99-hosting.conf an und lade sie kontrolliert.<\/p>\n<pre><code># tempor\u00e4r testen\nsudo sysctl -w net.core.somaxconn=65535\nsudo sysctl -w net.ipv4.tcp_max_syn_backlog=4096\n\n# dauerhaft setzen\nsudo tee \/etc\/sysctl.d\/99-hosting.conf &gt;\/dev\/null &lt;&lt;'EOF'\nnet.core.somaxconn = 65535\nnet.ipv4.tcp_max_syn_backlog = 4096\nvm.swappiness = 10\nvm.dirty_ratio = 20\nEOF\n\nsudo sysctl --system\n<\/code><\/pre>\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\/kernel_tuning_sysctl1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Netzwerk-Parameter, die Webserver tragen<\/h2>\n\n<p>F\u00fcr viele gleichzeitige Verbindungen erh\u00f6he ich <strong>somaxconn<\/strong>, damit der Listen-Backlog von Nginx oder Apache nicht \u00fcberl\u00e4uft. Mit net.ipv4.tcp_max_syn_backlog vergr\u00f6\u00dfere ich die Warteschlange halboffener Verbindungen, was unter Traffic-Spitzen hilft. In reinen Web-Setups lasse ich net.ipv4.ip_forward meist aus, bei Reverse-Proxies oder Gateways schalte ich es an. Ich validiere Backlog-Drops mit ss -s und netstat -s und pr\u00fcfe, ob Accept-Queues leer laufen. Wer tiefer in Staukontrolle gehen will, bewertet zus\u00e4tzlich Algorithmen wie CUBIC oder BBR; dazu passt mein Hinweis auf <a href=\"https:\/\/webhosting.de\/tcp-congestion-control-auswirkungen-vergleich-latenz\/\">TCP Congestion Control<\/a>.<\/p>\n<pre><code># Beispielwerte f\u00fcr stark frequentierte Webserver\nnet.core.somaxconn = 65535\nnet.ipv4.tcp_max_syn_backlog = 4096\nnet.ipv4.ip_forward = 0\n<\/code><\/pre>\n\n<h2>Speicher- und VM-Tuning f\u00fcr Hosting-Workloads<\/h2>\n\n<p>Ich senke <strong>swappiness<\/strong> auf 10, damit der Kernel RAM l\u00e4nger nutzt und weniger swappt. Mit vm.dirty_ratio von 15 bis 20 Prozent begrenze ich schmutzige Seiten, damit Schreiblast nicht zu langen Flush-Bursts f\u00fchrt. F\u00fcr viele Prozesse setze ich vm.overcommit_memory auf 1, wenn ich die Applikationen kenne und ihre Reserven verstehe. Erg\u00e4nzend beobachte ich Page-Cache-Treffer und IO-Wait, damit ich Caching-Effekte richtig deute. Einen tieferen Blick auf Cache-Verhalten liefere ich mit diesem Leitfaden zum <a href=\"https:\/\/webhosting.de\/filesystem-caching-linux-page-cache-cacheboost\/\">Page Cache<\/a>.<\/p>\n<pre><code># Speicher- und VM-Profile\nvm.swappiness = 10\nvm.dirty_ratio = 20\nvm.overcommit_memory = 1\n<\/code><\/pre>\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\/linux-kernel-tuning-hosting-5867.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>CPU- und Scheduler-Feinschliff<\/h2>\n\n<p>Bei hoher Concurrency hebe ich <strong>kernel.pid_max<\/strong> an, damit viele Worker-Prozesse IDs erhalten. F\u00fcr CFS-Quotas justiere ich kernel.sched_cfs_bandwidth_slice_us, um zu kurze Slices bei burstigen Diensten zu vermeiden. Ich pr\u00fcfe Run-Queue-L\u00e4ngen, Kontextwechsel und Steal-Zeiten, vor allem auf geteilten Hosts. Wenn ich CPU-Isolation brauche, binde ich Dienste via taskset oder cgroups an Kerne. Einen Einstieg in tiefere Kernel-Optimierung liefert dieser kompakte <a href=\"https:\/\/webhosting.de\/linux-kernel-performance-hosting-optimierung-kernelboost\/\">Kernel-Performance<\/a>-Leitfaden.<\/p>\n<pre><code># Prozess- und Scheduler-Parameter\nkernel.pid_max = 4194304\n# Beispiel f\u00fcr feinere CFS-Slices\nkernel.sched_cfs_bandwidth_slice_us = 5000\n<\/code><\/pre>\n\n<h2>Sicherheits-Parameter ohne Leistungsverlust<\/h2>\n\n<p>Ich aktiviere <strong>dmesg_restrict<\/strong>, damit keine unprivilegierten Nutzer Kernel-Logs auslesen. Mit kernel.kptr_restrict verberge ich Adressen, die Angreifern bei Exploits helfen k\u00f6nnten. Auf Netzwerkebene schalte ich rp_filter standardm\u00e4\u00dfig an, um IP-Spoofing zu unterbinden. Diese Einstellungen kosten kaum Performance und st\u00e4rken die Host-H\u00e4rtung deutlich. Kontrolliert lade ich sie in dieselbe sysctl-Datei, damit ich nachvollziehbar bleibe.<\/p>\n<pre><code># H\u00e4rtung via sysctl\nkernel.dmesg_restrict = 1\nkernel.kptr_restrict = 2\nnet.ipv4.conf.default.rp_filter = 1\nnet.ipv4.conf.all.rp_filter = 1\n<\/code><\/pre>\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\/kerneltuning_linux_hosting_9274.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Erweiterte Netzwerkpuffer f\u00fcr hohen Durchsatz<\/h2>\n\n<p>F\u00fcr High-Traffic-Hosts passe ich <strong>TCP-Puffer<\/strong> an, damit schnelle Verbindungen nicht im Window-Limit h\u00e4ngen. Mit net.ipv4.tcp_rmem und tcp_wmem definiere ich Mindest-, Standard- und Maximalgr\u00f6\u00dfen. net.core.optmem_max und net.core.netdev_max_backlog helfen dabei, kurze Bursts sauber zu absorbieren. Ich beobachte Retransmits, cwnd-Entwicklung und Puffer-F\u00fcllst\u00e4nde, bevor ich Werte weiter erh\u00f6he. Diese Schritte heben Durchsatz und senken Latenzschwankungen auf modernen 10G-Links sp\u00fcrbar.<\/p>\n<pre><code># erweiterte Netzwerkpuffer\nnet.core.optmem_max = 81920\nnet.core.netdev_max_backlog = 3000\nnet.ipv4.tcp_rmem = 4096 87380 16777216\nnet.ipv4.tcp_wmem = 4096 65536 16777216\n<\/code><\/pre>\n\n<h2>Praxis: Von Baseline zu messbarem Gewinn<\/h2>\n\n<p>Ich starte jedes Tuning mit einer <strong>Baseline<\/strong> und dokumentiere Kennzahlen wie P95-Latenz, Throughput und Fehlerquote. Danach \u00e4ndere ich wenige Parameter, lade das Profil und messe erneut mit ab, wrk oder sysbench. F\u00e4llt die Latenz, nehme ich die \u00c4nderung auf; steigt sie, rolle ich zur\u00fcck. So baue ich ein Hosting-Profil auf, das meiner Applikation entspricht. Abschlie\u00dfend verifiziere ich unter Produktionslast noch einmal, bevor ich die Werte dauerhaft lasse.<\/p>\n<pre><code># Ist-Zustand sichern\nsysctl -a &gt; \/root\/sysctl-baseline.txt\n\n# Netzwerkparameter sichten\nsysctl -a | grep -E 'net\\.core|net\\.ipv4'\n\n# Profile neu laden\nsysctl --system\n<\/code><\/pre>\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\/kernel_tuning_linux_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Vergleichstabelle: Standard vs. Hosting-Profil<\/h2>\n\n<p>Die folgende <strong>Tabelle<\/strong> zeigt praxistaugliche Startwerte, die ich h\u00e4ufig einsetze. Werte h\u00e4ngen von Workload, Netzwerk und Hardware ab. Ich beginne damit, pr\u00fcfe Metriken und justiere schrittweise. Bei Problemen gehe ich zu den Standardwerten zur\u00fcck und steigere erneut in kleinen Schritten. So halte ich Risiken gering und erreiche konsistente Ergebnisse.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parameter<\/th>\n      <th>Standard<\/th>\n      <th>Hosting-Profil<\/th>\n      <th>Nutzen<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>net.core.somaxconn<\/td>\n      <td>128<\/td>\n      <td>65535<\/td>\n      <td>Mehr angenommene Verbindungen<\/td>\n    <\/tr>\n    <tr>\n      <td>net.ipv4.tcp_max_syn_backlog<\/td>\n      <td>1024<\/td>\n      <td>4096<\/td>\n      <td>Weniger Drops bei Peaks<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.swappiness<\/td>\n      <td>60<\/td>\n      <td>10<\/td>\n      <td>Weniger Swapping unter Last<\/td>\n    <\/tr>\n    <tr>\n      <td>kernel.pid_max<\/td>\n      <td>32768<\/td>\n      <td>4194304<\/td>\n      <td>Mehr Prozesse\/Worker m\u00f6glich<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_ratio<\/td>\n      <td>30<\/td>\n      <td>20<\/td>\n      <td>Gleichm\u00e4\u00dfigeres Schreiben<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>H\u00e4ufige Fehler vermeiden und Monitoring<\/h2>\n\n<p>Ich setze keine <strong>Extremwerte<\/strong>, weil sie zu Zeitouts, OOM-Kills oder Paketverlust f\u00fchren k\u00f6nnen. \u00c4nderungen teste ich in Stufen, jeweils mit eindeutiger Metrik und kurzer Beobachtungsphase. Kritische Indikatoren sind Accept-Queue-L\u00e4nge, TCP-Retransmits, P95-Latenz, IO-Wait und Swap-In\/Out. F\u00fcr die \u00dcberwachung nutze ich leichtgewichtige Agenten und Dashboards, damit ich Trends rasch erkenne. Nach Kernel-Updates kontrolliere ich, ob sysctl-Profile noch g\u00fcltig sind und lade sie neu, falls n\u00f6tig.<\/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\/linux-kernel-tuning-5841.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Persistenz, Reihenfolge und Distributionen<\/h2>\n<p>Damit Profile reproduzierbar bleiben, beachte ich die Lade-Reihenfolge in \/etc\/sysctl.d: Dateien werden lexikografisch verarbeitet. Ich vergebe bewusst Pr\u00e4fixe wie 60-\u2026 oder 99-\u2026, um sicherzustellen, dass mein Hosting-Profil andere Defaults \u00fcberstimmt. Unterschiede zwischen Distributionen (Debian\/Ubuntu vs. RHEL\/Alma) betreffen meist nur Pfade und Standardwerte; sysctl &#8211;system l\u00e4dt stets \/etc\/sysctl.conf, \/etc\/sysctl.d\/*.conf und ggf. Vendor-Dateien. Nach gro\u00dfen Systemupdates pr\u00fcfe ich mit sysctl &#8211;system -o (Dry-Run je nach Version) oder vergleiche die geladene Effektivkonfiguration gegen meine Vorlage, um \u00dcberraschungen zu vermeiden.<\/p>\n<pre><code># Beispiel: saubere Reihenfolge sicherstellen\nsudo ls -1 \/etc\/sysctl.d\n10-vendor.conf\n50-defaults.conf\n99-hosting.conf  # \u00fcberschreibt alles davor\n\n# effektiv geladene Werte diffen\nsysctl -a &gt; \/root\/sysctl-after.txt\ndiff -u \/root\/sysctl-baseline.txt \/root\/sysctl-after.txt | less\n<\/code><\/pre>\n\n<h2>TCP-Lebenszyklus und Port-Management<\/h2>\n<p>Unter starker Last entstehen viele kurzlebige Verbindungen. Ich stelle <strong>ip_local_port_range<\/strong> breit ein, damit ausgehende Verbindungen (etwa von Proxies) nicht im Ephemeral-Port-Limit h\u00e4ngen. <strong>tcp_fin_timeout<\/strong> kontrolliert, wie lange Sockets in FIN-WAIT-2 verweilen. Mit sinnvollen <strong>Keepalive<\/strong>-Parametern baue ich tote Sessions schneller ab, ohne Verbindungen aggressiv zu kappen. TIME_WAIT ist normal und sch\u00fctzt vor sp\u00e4ten Paketen; ich reduziere es nicht blind. <strong>tcp_tw_reuse<\/strong> hilft prim\u00e4r auf Client-Hosts, bei reinen Servern bleibt es meist aus. Timestamps und SACK belasse ich an, da sie Performance und Robustheit verbessern.<\/p>\n<pre><code># Portbereich und TCP-Lebenszyklus\nnet.ipv4.ip_local_port_range = 10240 65535\nnet.ipv4.tcp_fin_timeout = 30\nnet.ipv4.tcp_keepalive_time = 600\nnet.ipv4.tcp_keepalive_intvl = 30\nnet.ipv4.tcp_keepalive_probes = 5\n# Vorsicht mit tcp_tw_reuse: nur f\u00fcr ausgehende Client-Last sinnvoll\n# net.ipv4.tcp_tw_reuse = 1\n<\/code><\/pre>\n\n<h2>IPv6 und Nachbartabellen stabil halten<\/h2>\n<p>Viele Hosts tragen heute Dual-Stack-Traffic. Ich optimiere die ARP\/ND-Tabellen, damit es nicht zu \u201eneighbour table overflow\u201c-Meldungen kommt, insbesondere auf Proxies oder Knoten mit zahlreichen Peers. Die <strong>gc_thresh<\/strong>-Schwellen definiere ich passend zur Verbindungsmatrix. ICMPv6- und Router-Advert-Optionen belasse ich bei Servern restriktiv, damit keine ungewollten Routen einflie\u00dfen. F\u00fcr IPv4 achte ich erg\u00e4nzend auf ARP-Garbage-Collection, damit Eintr\u00e4ge rechtzeitig altern, aber nicht zu fr\u00fch verschwinden.<\/p>\n<pre><code># Nachbartabellen: gro\u00dfz\u00fcgigere Schwellen\nnet.ipv4.neigh.default.gc_thresh1 = 1024\nnet.ipv4.neigh.default.gc_thresh2 = 4096\nnet.ipv4.neigh.default.gc_thresh3 = 8192\n\nnet.ipv6.neigh.default.gc_thresh1 = 1024\nnet.ipv6.neigh.default.gc_thresh2 = 4096\nnet.ipv6.neigh.default.gc_thresh3 = 8192\n\n# ARP\/ND-Aging konservativ\nnet.ipv4.neigh.default.gc_stale_time = 60\n<\/code><\/pre>\n\n<h2>Dateideskriptoren und Backlogs zusammen denken<\/h2>\n<p>Ein h\u00e4ufiger Engpass sind <strong>File-Deskriptoren<\/strong>. Wenn Anwendungen tausende Sockets halten, passen fs.file-max (systemweit) und ulimit\/nofile (pro Dienst) zusammen. somaxconn vergr\u00f6\u00dfert zwar die Listen-Queue, hilft aber nur, wenn der Webserver selbst mehr FDs \u00f6ffnen darf und die Accept-Rate hoch genug ist. Ich stelle sicher, dass System- und Service-Limits synchron sind, sonst entstehen k\u00fcnstliche Bottlenecks trotz \u201egro\u00dfer\u201c Kernel-Backlogs.<\/p>\n<pre><code># Systemweit mehr FDs erlauben\nfs.file-max = 2097152\n\n# Dienstseitig (Beispiel systemd-Unit)\n# [Service]\n# LimitNOFILE=1048576\n<\/code><\/pre>\n\n<h2>UDP\/QUIC-Workloads abfedern<\/h2>\n<p>DNS, Syslog, Telemetrie und QUIC (HTTP\/3) nutzen <strong>UDP<\/strong>. Hier skaliere ich die globalen Socket-Puffer und UDP-spezifischen Speichergrenzen. Bei gro\u00dfen, burstigen UDP-Lasten (etwa Telemetrie-Gateways) verhindert das Drops im Receive-Path. Ich beobachte mit ss -u -a und netstat -su die Fehlz\u00e4hler und passe die Maxima graduell an. F\u00fcr QUIC ist zudem net.core.rmem_max\/wmem_max relevant, da Userspace-Stacks oft per setsockopt an diese Grenzen sto\u00dfen.<\/p>\n<pre><code># UDP-Puffer und Limits\nnet.core.rmem_max = 268435456\nnet.core.wmem_max = 268435456\nnet.ipv4.udp_mem = 98304 131072 262144\nnet.ipv4.udp_rmem_min = 8192\nnet.ipv4.udp_wmem_min = 8192\n<\/code><\/pre>\n\n<h2>Dirty-Writeback pr\u00e4zisieren: Bytes statt Prozente<\/h2>\n<p>Auf Systemen mit viel RAM k\u00f6nnen Prozentwerte zu gro\u00dfen, schlagartigen Flushes f\u00fchren. Ich setze daher bevorzugt <strong>vm.dirty_background_bytes<\/strong> und <strong>vm.dirty_bytes<\/strong>, um absolute Obergrenzen zu definieren. Das stabilisiert die Schreibrate und gl\u00e4ttet Latenzen, vor allem bei HDDs oder gemischten Workloads. Zus\u00e4tzlich halte ich <strong>vm.min_free_kbytes<\/strong> moderat, damit der Kernel genug freien Speicher f\u00fcr Burst-Allokationen vorh\u00e4lt.<\/p>\n<pre><code># Beispiel: absolute Dirty-Grenzen (ca. 1G Hintergrund, 4G hart)\nvm.dirty_background_bytes = 1073741824\nvm.dirty_bytes = 4294967296\nvm.min_free_kbytes = 65536\n<\/code><\/pre>\n\n<h2>RPS\/RFS und Netz-IRQ-Last verteilen<\/h2>\n<p>Bei hohen PPS-Raten kann ein einzelner CPU-Kern am NIC-IRQ h\u00e4ngen. Ich nutze Receive Packet Steering (RPS) und ggf. Receive Flow Steering (RFS), um die Paketverarbeitung auf mehrere Kerne zu verteilen. Global setze ich <strong>net.core.rps_sock_flow_entries<\/strong>, die eigentliche Zuordnung erfolgt pro Queue via Sysfs. Das senkt CPU-Hotspots, verbessert Cache-Lokalit\u00e4t und reduziert Latenzspitzen. In Kombination mit net.core.netdev_max_backlog ergibt sich eine robustere Pipeline.<\/p>\n<pre><code># Globale Flow-Entries f\u00fcr RPS\nnet.core.rps_sock_flow_entries = 32768\n\n# Hinweis: Per-Queue-Tuning via \/sys\/class\/net\/&lt;iface&gt;\/queues\/rx-*\/rps_cpus\n# und rps_flow_cnt, je nach NIC und Queue-Anzahl.\n<\/code><\/pre>\n\n<h2>Container, Namespaces und VMs<\/h2>\n<p>In Containern sind viele <strong>net.*<\/strong>-Werte <em>namespaced<\/em> und k\u00f6nnen pro Network Namespace gelten. Ich dokumentiere daher, ob ich Host- oder Pod\/Container-Netzwerk anpasse. Orchestratoren erlauben oft nur eine Safe-List an Sysctls; Werte wie kernel.pid_max bleiben Host-seitig. Auf VMs pr\u00fcfe ich, welche virtuellen NICs und Offloads aktiv sind (virtio, ENA), denn Offloads und MTU wirken sich stark auf Pufferbedarf und cwnd-Entwicklung aus. NUMA-lastige Bare-Metal-Hosts profitieren von deaktiviertem <strong>vm.zone_reclaim_mode<\/strong> und bewusstem CPU\/IRQ-Affinity-Layout.<\/p>\n<pre><code># NUMA-Nebenwirkung vermeiden\nvm.zone_reclaim_mode = 0\n<\/code><\/pre>\n\n<h2>Conntrack und Stateful Firewalls im Blick<\/h2>\n<p>L\u00e4uft der Host als NAT\/Firewall oder beherbergt viele Container mit egress-NAT, skaliere ich die <strong>nf_conntrack<\/strong>-Tabelle. Zu kleine Hashtabellen erzeugen Drops und hohe Latenzen bei Tabellen-Scans. Ich messe die Auslastung mit nstat und schaue auf \u201eexpected\u201c vs. \u201ein use\u201c. F\u00fcr reine Webserver ohne NAT ist conntrack oft unkritisch oder gar deaktiviert; auf Gateways geh\u00f6rt es zwingend ins Tuning-Paket.<\/p>\n<pre><code># Conntrack-Gr\u00f6\u00dfe (nur wenn aktiv genutzt!)\nnet.netfilter.nf_conntrack_max = 1048576\n<\/code><\/pre>\n\n<h2>Robustheit gegen Angriffe und Anomalien<\/h2>\n<p>Unter Bot-Traffic und Scans helfen <strong>tcp_syncookies<\/strong> und konservative ICMP\/Redirect-Optionen. Syncookies retten den Handshake bei \u00fcberlaufenden SYN-Queues, ohne legitimen Traffic \u00fcberm\u00e4\u00dfig zu drosseln. Redirects und Source-Routes deaktiviere ich auf Servern, die nicht routen sollen. Diese H\u00e4rtungen sind leichtgewichtig und erg\u00e4nzen die oben genannten Schutzmechanismen sinnvoll.<\/p>\n<pre><code># SYN-Flood-Abwehr und konservatives Routing-Verhalten\nnet.ipv4.tcp_syncookies = 1\nnet.ipv4.conf.all.accept_redirects = 0\nnet.ipv4.conf.default.accept_redirects = 0\nnet.ipv4.conf.all.send_redirects = 0\nnet.ipv4.conf.default.send_redirects = 0\nnet.ipv4.conf.all.accept_source_route = 0\nnet.ipv4.conf.default.accept_source_route = 0\n<\/code><\/pre>\n\n<h2>Messpraxis vertiefen: Was ich regelm\u00e4\u00dfig pr\u00fcfe<\/h2>\n<p>F\u00fcr reproduzierbare Ergebnisse messe ich konsistent vor und nach \u00c4nderungen. Auf Netzwerkseite nutze ich ss -s, ss -ti, nstat und netstat -s, um Queue-L\u00e4ngen, Retransmits und Sack-Statistiken zu sehen. Auf Speicher-\/I\/O-Seite helfen vmstat, iostat und pidstat bei der Einordnung von Dirty-Flushes, Kontextwechseln und CPU-Wartezeiten. Unter Lasttests schaue ich zus\u00e4tzlich auf:<\/p>\n<ul>\n<li>Accept-Queue (LISTEN) und SYN-Queue: Dropped vs. Overflows<\/li>\n<li>Pacing\/Throughput pro Verbindung und cwnd-Entwicklung<\/li>\n<li>P95\/99-Latenzen im A\/B-Vergleich, statt nur Durchschnitt<\/li>\n<li>Swap-In\/Out-Rate und Page-Cache-Hitrate<\/li>\n<li>IRQ-Lastverteilung und Run-Queue-L\u00e4ngen pro CPU<\/li>\n<\/ul>\n<pre><code># schnelle Statuschecks\nss -s\nnetstat -s | egrep 'listen|SYN|retran|dropped'\nvmstat 1 10\npidstat -w -u -r 1 5\n<\/code><\/pre>\n\n<h2>Beispiel: Konsolidiertes Hosting-Profil<\/h2>\n<p>Zum Start kombiniere ich Basis- und erweiterte Werte in einer Datei. Dann erh\u00f6he ich in kleinen Schritten, jeweils mit klaren Messpunkten. Die folgenden Werte sind ein konservativer, aber performanter Ausgangspunkt f\u00fcr stark frequentierte Webserver und Proxies.<\/p>\n<pre><code>sudo tee \/etc\/sysctl.d\/99-hosting.conf &gt;\/dev\/null &lt;&lt;'EOF'\n# Netzwerk-Basics\nnet.core.somaxconn = 65535\nnet.ipv4.tcp_max_syn_backlog = 4096\nnet.core.netdev_max_backlog = 3000\nnet.core.optmem_max = 81920\n\n# TCP-Puffer und Ports\nnet.ipv4.tcp_rmem = 4096 87380 16777216\nnet.ipv4.tcp_wmem = 4096 65536 16777216\nnet.ipv4.ip_local_port_range = 10240 65535\nnet.ipv4.tcp_fin_timeout = 30\nnet.ipv4.tcp_keepalive_time = 600\nnet.ipv4.tcp_keepalive_intvl = 30\nnet.ipv4.tcp_keepalive_probes = 5\n\n# UDP\/QUIC\nnet.core.rmem_max = 268435456\nnet.core.wmem_max = 268435456\nnet.ipv4.udp_mem = 98304 131072 262144\nnet.ipv4.udp_rmem_min = 8192\nnet.ipv4.udp_wmem_min = 8192\n\n# Nachbartabellen\nnet.ipv4.neigh.default.gc_thresh1 = 1024\nnet.ipv4.neigh.default.gc_thresh2 = 4096\nnet.ipv4.neigh.default.gc_thresh3 = 8192\nnet.ipv6.neigh.default.gc_thresh1 = 1024\nnet.ipv6.neigh.default.gc_thresh2 = 4096\nnet.ipv6.neigh.default.gc_thresh3 = 8192\nnet.ipv4.neigh.default.gc_stale_time = 60\n\n# Sicherheit\nkernel.dmesg_restrict = 1\nkernel.kptr_restrict = 2\nnet.ipv4.conf.default.rp_filter = 1\nnet.ipv4.conf.all.rp_filter = 1\nnet.ipv4.tcp_syncookies = 1\nnet.ipv4.conf.all.accept_redirects = 0\nnet.ipv4.conf.default.accept_redirects = 0\nnet.ipv4.conf.all.send_redirects = 0\nnet.ipv4.conf.default.send_redirects = 0\nnet.ipv4.conf.all.accept_source_route = 0\nnet.ipv4.conf.default.accept_source_route = 0\n\n# Speicher\/VM\nvm.swappiness = 10\nvm.dirty_ratio = 20\nvm.dirty_background_bytes = 1073741824\nvm.dirty_bytes = 4294967296\nvm.min_free_kbytes = 65536\nvm.overcommit_memory = 1\nvm.zone_reclaim_mode = 0\n\n# CPU\/Prozesse\nkernel.pid_max = 4194304\nkernel.sched_cfs_bandwidth_slice_us = 5000\n\n# RPS\nnet.core.rps_sock_flow_entries = 32768\n\n# FDs\nfs.file-max = 2097152\nEOF\n\nsudo sysctl --system\n<\/code><\/pre>\n\n<h2>Zusammenfassung: Tuning als wiederkehrender Ablauf<\/h2>\n\n<p>Gezieltes <strong>Kernel-Tuning<\/strong> mit sysctl liefert im Hosting klare Effekte: k\u00fcrzere Antwortzeiten, h\u00f6here Durchsatzwerte und konstante Services. Ich beginne mit Netzwerk-Basics wie somaxconn und tcp_max_syn_backlog, k\u00fcmmere mich dann um Speicher mit swappiness und dirty_ratio. Anschlie\u00dfend optimiere ich PIDs und Scheduler und h\u00e4rte den Host mit dmesg_restrict, kptr_restrict und rp_filter. Jede \u00c4nderung messe ich, dokumentiere sie und behalte Metriken im Blick. So entsteht Schritt f\u00fcr Schritt ein Profil, das meine Workloads effizient bedient und Reserven f\u00fcr Traffic-Spitzen bereith\u00e4lt.<\/p>","protected":false},"excerpt":{"rendered":"<p>**Kerneltuning in Linux hosting**: Sysctl parameters in \u00e9\u00e9n oogopslag voor optimale prestaties en **kernel optimalisatie hosting**.<\/p>","protected":false},"author":1,"featured_media":18121,"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-18128","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":"612","_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":"Kernel-Tuning","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":"18121","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/18128","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=18128"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/18128\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/18121"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=18128"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=18128"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=18128"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}