{"id":21283,"date":"2026-09-11T08:33:29","date_gmt":"2026-09-11T06:33:29","guid":{"rendered":"https:\/\/webhosting.de\/linux-hugepages-hosting-mariadb-redis-php-fpm-optimierung-nebula\/"},"modified":"2026-09-11T08:33:29","modified_gmt":"2026-09-11T06:33:29","slug":"linux-hugepages-alojamiento-mariadb-redis-php-fpm-optimizacion-nebula","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/linux-hugepages-hosting-mariadb-redis-php-fpm-optimierung-nebula\/","title":{"rendered":"HugePages de Linux en el alojamiento web: un impulso para MariaDB, Redis y PHP-FPM"},"content":{"rendered":"<p>Ich zeige konkret, wie linux hugepages im Hosting-Stack MariaDB, Redis und PHP-FPM antreiben, wo sie bremsen und wie ich sie gezielt einstelle. So senke ich <strong>Latenz<\/strong>, reduziere TLB-Misses und halte die <strong>Speicherverwaltung<\/strong> berechenbar.<\/p>\n\n<h2>Zentrale Punkte<\/h2>\n\n<p>Die folgenden Stichpunkte fassen die wichtigsten Handgriffe und Effekte zusammen.<\/p>\n<ul>\n  <li><strong>THP-Modus<\/strong> bewusst w\u00e4hlen: \u201emadvise\u201c f\u00fcr breite Workloads, \u201enever\u201c f\u00fcr sensible Dienste wie Redis.<\/li>\n  <li><strong>Statische HugePages<\/strong> f\u00fcr gro\u00dfe MariaDB-Bufferpools einplanen, um Latenz und TLB-Misses zu senken.<\/li>\n  <li><strong>Redis<\/strong> vor Latenzspitzen sch\u00fctzen: THP deaktivieren und Fork-Kosten begrenzen.<\/li>\n  <li><strong>PHP-FPM<\/strong> profitiert indirekt durch geringeren Kernel-Overhead und schnellere Backends.<\/li>\n  <li><strong>Benchmarking<\/strong> und Monitoring vor Go-Live durchf\u00fchren, Effekte messbar machen.<\/li>\n<\/ul>\n\n<h2>HugePages und THP kurz erkl\u00e4rt<\/h2>\n\n<p>Ich nutze <strong>HugePages<\/strong>, um gr\u00f6\u00dfere Speicherseiten zu aktivieren und so die Anzahl der zu verwaltenden Seiten zu verringern. Klassische Seiten sind 4 KB, w\u00e4hrend gro\u00dfe Seiten meist <strong>2 MB<\/strong> gro\u00df sind. Dadurch sinken TLB-Misses deutlich, die CPU verbringt weniger Zeit im Memory-Management und Dienste mit viel RAM-Zugriff reagieren schneller. Transparent Huge Pages (<strong>THP<\/strong>) versucht das automatisch und kann ohne App-Anpassung wirken. Praxisberichte zeigen oft 20\u201340 % schnellere Operationen, wenn Workloads und Einstellungen zusammenpassen.<\/p>\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\/09\/serverraum-hosting-optimierung-4826.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>THP-Modi richtig w\u00e4hlen und testen<\/h2>\n\n<p>Ich unterscheide klar die Modi \u201e<strong>always<\/strong>\u201c, \u201emadvise\u201c und \u201enever\u201c, weil sie Workloads unterschiedlich beeinflussen. \u201ealways\u201c kann \u00fcberraschend viel RAM binden und Kopieraufwand erzeugen, wenn Dienste forken. \u201emadvise\u201c erlaubt Kontrolle: Nur Speicher, den die App explizit markiert, nutzt gro\u00dfe Seiten. \u201enever\u201c bietet maximale Vorhersehbarkeit, gerade bei forking-intensiven Diensten wie Redis. Wer tiefer einsteigen will, findet Hintergr\u00fcnde zu Chancen und Fallstricken hier: <a href=\"https:\/\/webhosting.de\/transparent-huge-pages-linux-performance-booster-oder-problem-optimierung\/\">THP: Booster oder Problem<\/a>. Ich teste jeden Modus gegen echte Last, messe Latenz, CPU-Zeit und RSS, und entscheide dann faktenbasiert.<\/p>\n\n<h2>Praktische Einrichtung auf dem Host<\/h2>\n\n<p>Bevor ich Dienste umstelle, sorge ich f\u00fcr reproduzierbare Host-Defaults und eine sichere R\u00fcckfallebene.<\/p>\n\n<h3>THP gezielt setzen (Boot-Parameter oder systemd)<\/h3>\n<ul>\n  <li>Per Kernel-Boot: In GRUB \u201etransparent_hugepage=madvise\u201c oder \u201etransparent_hugepage=never\u201c anh\u00e4ngen und neu booten.<\/li>\n  <li>Laufend per sysfs \u2013 ideal f\u00fcr Tests oder in einer systemd-Unit:<\/li>\n<\/ul>\n<pre><code># Status pr\u00fcfen\ncat \/sys\/kernel\/mm\/transparent_hugepage\/enabled\ncat \/sys\/kernel\/mm\/transparent_hugepage\/defrag\n\n# Wechsel auf madvise (Beispiel)\necho madvise &gt; \/sys\/kernel\/mm\/transparent_hugepage\/enabled\necho never   &gt; \/sys\/kernel\/mm\/transparent_hugepage\/defrag\n<\/code><\/pre>\n<p>Ich halte diese Befehle in einer kleinen systemd-Unit fest, damit Reboots die Einstellung nicht verlieren.<\/p>\n\n<h3>Statische HugePages reservieren<\/h3>\n<p>F\u00fcr HugeTLB-seitige Reservierung plane ich konservativ und mit Reserve (siehe Checkliste unten):<\/p>\n<pre><code># Gr\u00f6\u00dfe und Z\u00e4hler sichten\ngrep -i huge \/proc\/meminfo\n\n# 32 GB reservieren (2 MB Seiten -&gt; 16384)\nsysctl -w vm.nr_hugepages=16384\necho \"vm.nr_hugepages=16384\" &gt; \/etc\/sysctl.d\/90-hugepages.conf\n\n# Optional: Mountpoint f\u00fcr hugetlbfs (n\u00fctzlich f\u00fcr Diagnose)\nmkdir -p \/dev\/hugepages\necho \"hugetlbfs \/dev\/hugepages hugetlbfs defaults,pagesize=2M 0 0\" &gt;&gt; \/etc\/fstab\nmount -a\n<\/code><\/pre>\n<p>Wenn Dienste HugeTLB nutzen, ben\u00f6tigen sie in der Regel MEMLOCK-Rechte. Ich setze daf\u00fcr Limits und Capabilities in der jeweiligen systemd-Unit:<\/p>\n<pre><code>[Service]\nLimitMEMLOCK=infinity\nCapabilityBoundingSet=CAP_IPC_LOCK\nAmbientCapabilities=CAP_IPC_LOCK\n<\/code><\/pre>\n\n<h3>Kontrolle: Nutzen Prozesse gro\u00dfe Seiten?<\/h3>\n<p>Ich pr\u00fcfe je Prozess die tats\u00e4chliche Nutzung:<\/p>\n<pre><code># Summen \u00fcber AnonHugePages je Prozess\ngrep -i 'AnonHugePages' \/proc\/$PID\/smaps | awk '{s+=$2} END {print s \" kB\"}'\n\n# Systemweite Kennzahlen\ngrep -i huge \/proc\/meminfo\n<\/code><\/pre>\n\n<h2>MariaDB: Gewinn durch statische HugePages<\/h2>\n\n<p>MariaDB lebt vom InnoDB-<strong>Bufferpool<\/strong> und von planbarer RAM-Nutzung. Ich schalte THP f\u00fcr produktive Datenbanken meist auf \u201e<strong>never<\/strong>\u201c oder setze es auf \u201emadvise\u201c, falls ich gezielt teste. Grund: Beim Forken und bei Schreiblasten erzeugen 2-MB-Seiten hohe Copy-on-Write-Kosten, was Abfragen bremst und mariadb performance dr\u00fcckt. Statische HugePages f\u00fcr einen gro\u00dfen, eher leseorientierten Bufferpool machen die Latenz gleichm\u00e4\u00dfiger und reduzieren Verwaltungsoverhead. Erg\u00e4nzend passe ich vm.swappiness und den I\/O-Scheduler an, damit der Kernel den Puffer nicht unn\u00f6tig verdr\u00e4ngt.<\/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\/09\/linux_hugepages_optimierung_8293.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h3>Konfiguration in MariaDB, NUMA und I\/O<\/h3>\n<ul>\n  <li>Bufferpool passend zur Last: <code>innodb_buffer_pool_size<\/code> als Haupthebel, <code>innodb_buffer_pool_instances<\/code> zur Parallelisierung.<\/li>\n  <li>Gro\u00dfe Seiten aktivieren (falls von der Version unterst\u00fctzt): <code>innodb_use_large_pages=ON<\/code> bzw. streng \u201eFORCE\u201c nur nach Test.<\/li>\n  <li>I\/O-Pfad gl\u00e4tten: <code>innodb_flush_method=O_DIRECT<\/code>, saubere Write-Amp-Strategie, kontrollierte Checkpoints.<\/li>\n  <li>NUMA-Fallen vermeiden: mysqld via <code>numactl --interleave=all<\/code> starten, wenn Knotenungleichgewicht droht.<\/li>\n  <li>Systemlimits: MEMLOCK wie oben; ausreichend HugePages im Vorfeld reservieren, damit der Start nicht scheitert.<\/li>\n<\/ul>\n<p>In der Praxis takte ich den Bufferpool in sinnvollen Schritten (z. B. 8 \u2192 16 \u2192 32 GB) hoch, beobachte Page-Fault-Raten und vergleiche 99p-Latenz. Leseorientierte Workloads profitieren am st\u00e4rksten; bei hoher Schreiblast werte ich CoW-Kosten und fsync-Zyklen besonders sorgf\u00e4ltig aus.<\/p>\n\n<h2>Redis: Latenzspitzen vermeiden<\/h2>\n\n<p>Redis reagiert sehr empfindlich auf Speicherverhalten und Fork-Kosten bei <strong>Snapshots<\/strong> und AOF-Rewrites. Mit aktivem THP muss das System beim Kopieren nicht 4 KB, sondern 2 MB verschieben \u2013 das ist eine 512-fache Einheit, die Latenzspitzen provoziert. Ich setze THP daher in der Regel auf \u201e<strong>never<\/strong>\u201c, was redis memory berechenbarer macht. Bei gro\u00dfen, \u00fcberwiegend lesenden Key-Value-S\u00e4tzen kann ich \u201emadvise\u201c testen, aber nur mit strengen Benchmarks. Zus\u00e4tzlich stelle ich vm.overcommit_memory=1 ein und tune die Redis-Defragmentierung, damit ich Fragmentation kontrolliert halte.<\/p>\n\n<h3>Konfigurationsbausteine f\u00fcr geringe Fork-Kosten<\/h3>\n<ul>\n  <li>THP aus: Host-weit \u201enever\u201c setzen, Fork-Last glattziehen.<\/li>\n  <li>AOF\/Snapshot: <code>no-appendfsync-on-rewrite yes<\/code>, <code>aof-rewrite-incremental-fsync yes<\/code>, Zeitpunkte auf Verkehrst\u00e4ler legen.<\/li>\n  <li>Defragmentierung: <code>activedefrag yes<\/code>, Schwellen feinjustieren (<code>active-defrag-threshold-lower<\/code>, Zyklensteuerung).<\/li>\n  <li>Overcommit: <code>vm.overcommit_memory=1<\/code>, damit Forks nicht blockieren.<\/li>\n  <li>Allocator: Redis mit jemalloc betreiben, um Fragmentierung niedrig zu halten.<\/li>\n<\/ul>\n<p>Ich messe die Effekte mit der eingebauten Redis-Latenz\u00fcberwachung und korreliere Peaks mit BGSAVE- oder AOF-Events. F\u00e4llt die 99.9p-Latenz stabil ab, \u00fcbernehme ich die Settings in Produktion.<\/p>\n\n<h2>PHP-FPM: indirekter Schub im Web-Stack<\/h2>\n\n<p>PHP-FPM selbst verschlingt selten riesige Mengen RAM, profitiert aber von weniger <strong>Kernel-Overhead<\/strong> und schnelleren Backends. Wenn MariaDB und Redis flotter antworten, sinken TTFB und Antwortzeit pro Request. Ich justiere die FPM-Workerzahl, max_children und den Prozessmanager (dynamic oder static) passend zur Lastkurve. So nutze ich die Vorteile von HugePages im Gesamtsystem, ohne Blindfl\u00fcge zu riskieren. Einen praktischen Einstieg in das Thema gebe ich hier: <a href=\"https:\/\/webhosting.de\/server-hugepages-speicheroptimierung-hosting-performant\/\">Server-HugePages richtig nutzen<\/a>.<\/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\/09\/linux-hugepages-hosting-boost-7432.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h3>Praxis: Prozessgr\u00f6\u00dfen, Opcache und Sizing<\/h3>\n<ul>\n  <li>pm.max_children rechne ich aus: (RAM f\u00fcr PHP) \/ (durchschnittlicher RSS pro Worker) mit 10\u201320 % Reserve.<\/li>\n  <li>Opcode-Cache stabil halten: ausk\u00f6mmliche <code>opcache.memory_consumption<\/code> und <code>opcache.interned_strings_buffer<\/code>, um Recompiles zu vermeiden.<\/li>\n  <li>Allocator-Konsistenz: Gleiche C-Allocator-Familien (glibc\/jemalloc) \u00fcber Komponenten vermeiden unerwartete Fragmentierung.<\/li>\n  <li>THP \u201emadvise\u201c auf dem Host hilft bei geteilten Bibliotheken moderat, ohne Fork-Kosten in die H\u00f6he zu treiben.<\/li>\n<\/ul>\n\n<h2>Konfiguration: Schritt f\u00fcr Schritt und \u00dcbersichtstabelle<\/h2>\n\n<p>Ich starte jede Umstellung mit einer sauberen <strong>Bestandsaufnahme<\/strong>: RAM, Schreib- und Leseraten, Fork-Verhalten, Spitzenlast. Danach definiere ich Ziele, etwa konstante Latenz unter N Requests\/Sekunde oder weniger CPU-Zeit im Kernel. Ich setze THP je nach Dienst und teste realit\u00e4tsnah. Anschlie\u00dfend halte ich die Ergebnisse fest und rolle die \u00c4nderungen kontrolliert aus. Die folgende Tabelle fasst praxiserprobte Startpunkte zusammen, die ich anschlie\u00dfend feinjustiere:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Dienst<\/th>\n      <th>THP-Modus<\/th>\n      <th>Statische HugePages<\/th>\n      <th>Hinweis<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>MariaDB<\/td>\n      <td><strong>madvise<\/strong> oder never<\/td>\n      <td>Ja, passend zum Bufferpool<\/td>\n      <td>Gro\u00dfe leseorientierte Pools profitieren, Schreiblast sorgf\u00e4ltig testen.<\/td>\n    <\/tr>\n    <tr>\n      <td>Redis<\/td>\n      <td><strong>never<\/strong><\/td>\n      <td>Eher nein<\/td>\n      <td>Fork-Kosten vermeiden, Defragmentierung aktiv halten.<\/td>\n    <\/tr>\n    <tr>\n      <td>PHP-FPM<\/td>\n      <td><strong>madvise<\/strong><\/td>\n      <td>Selten n\u00f6tig<\/td>\n      <td>Nutzen entsteht prim\u00e4r indirekt durch schnellere Backends.<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Hosting-Umgebung: Auswahl trifft Performance<\/h2>\n\n<p>Ich erreiche nur dann dauerhaft <strong>konstante<\/strong> Zeiten, wenn der Anbieter Kernel und Defaults sinnvoll setzt. Dazu z\u00e4hlen aktuelle Kernel, vern\u00fcnftige THP-Voreinstellungen, genug RAM-Reserven und Support mit Tuning-Erfahrung. In Vergleichen von Hosting-Produkten achte ich auf klare Aussagen zu MariaDB-, Redis- und PHP-FPM-Tuning. Wer Unterschiede zwischen HugeTLB und THP verstehen will, profitiert von diesem kompakten Einstieg: <a href=\"https:\/\/webhosting.de\/hugetlb-vs-thp-serververgleich-speicher\/\">HugeTLB vs. THP Vergleich<\/a>. In Tests hat sich webhoster.de mit verl\u00e4sslicher Konfiguration als starker Kandidat f\u00fcr datenintensive Projekte gezeigt.<\/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\/09\/LinuxHugePagesHosting2947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Container, Cgroups und Kubernetes<\/h2>\n<p>In Container-Umgebungen plane ich etwas anders, denn viele Einstellungen sind hostweit und nicht pro Pod\/Docker-Container \u00e4nderbar:<\/p>\n<ul>\n  <li>THP ist eine Host-Entscheidung. Ich setze sie auf dem Node, nicht im Container.<\/li>\n  <li>HugeTLB erfordert reservierte Seiten auf dem Host. In Orchestrierungen weise ich Ressourcen explizit zu (2Mi\/1Gi-Typen pro Node) und terminiere Pods dahin.<\/li>\n  <li>Cgroups: Ich achte auf <em>memory.max<\/em>\/Swap-Limits, damit unvorhergesehene OOM-Kills nicht Messreihen zerst\u00f6ren.<\/li>\n  <li>Image-Konsistenz: Gleiche Allocator-Versionen in allen relevanten Containern, damit Fragmentierung nicht zuf\u00e4llig driftet.<\/li>\n<\/ul>\n<p>Ich teste auf Knotenebene mit identischen Kernel-Parametern und rotiere Deployments rollierend, um Lastdellen und kalte Caches zu vermeiden.<\/p>\n\n<h2>Benchmarking, Monitoring und Kapazit\u00e4tsplanung<\/h2>\n\n<p>Ich verlasse mich nicht auf Gef\u00fchl, ich messe <strong>hart<\/strong>. Vor und nach jeder \u00c4nderung nehme ich identische Lastprofile und erfasse Latenz, Durchsatz, CPU-Zeit im User- und Kernel-Space sowie RSS. Ich pr\u00fcfe auch Spitzen, nicht nur Mittelwerte, damit ich Ausrei\u00dfer fr\u00fch erkenne. F\u00fcr die Planung setze ich Puffer ein, damit Wachstum nicht sofort an Grenzen st\u00f6\u00dft. So halte ich die Performance \u00fcber Wochen konstant und verteile Reserven sinnvoll.<\/p>\n\n<h3>Messgr\u00f6\u00dfen und schnelle Pr\u00fcfkommandos<\/h3>\n<ul>\n  <li>THP-Zustand: <code>cat \/sys\/kernel\/mm\/transparent_hugepage\/enabled<\/code>, <code>...\/defrag<\/code>.<\/li>\n  <li>HugeTLB: <code>grep -i huge \/proc\/meminfo<\/code>, <code>cat \/proc\/sys\/vm\/nr_hugepages<\/code>.<\/li>\n  <li>Prozessseitig: <code>\/proc\/$PID\/smaps<\/code> nach <code>AnonHugePages<\/code> durchsuchen.<\/li>\n  <li>Major\/Minor-Faults und TLB-Indikatoren: <code>perf stat -p $PID -e cycles,task-clock,minor-faults,major-faults,dTLB-load-misses,iTLB-load-misses<\/code>.<\/li>\n  <li>Redis-Latenzen: integrierte Latenz-Tools, Korrelation mit BGSAVE\/AOF.<\/li>\n  <li>MariaDB: <em>SHOW GLOBAL STATUS<\/em> und Performance-Schema f\u00fcr Buffer-Hit-Rates, InnoDB-Checkpoint-Verhalten.<\/li>\n<\/ul>\n<p>Wichtig ist die Konsistenz der Messkampagne: gleiche Datens\u00e4tze, gleiche Testfenster, gleiche Hintergrundlast. Ansonsten vergleiche ich \u00c4pfel mit Birnen.<\/p>\n\n<h2>Fehlerbilder und schnelle Abhilfe<\/h2>\n\n<p>Steigen Antwortzeiten nach einem THP-Switch, pr\u00fcfe ich sofort <strong>Fork<\/strong>-Ereignisse und Copy-on-Write-Verhalten. H\u00e4ufen sich \u201eslow queries\u201c in MariaDB, reduziere ich Schreibamplituden, setze THP konservativer und evaluiere den I\/O-Pfad. Meldet Redis sporadische Latenzspitzen, stelle ich THP auf \u201enever\u201c und kontrolliere Snapshot-Zeitpunkte. Springt die CPU-Last an, beobachte ich TLB-Misses indirekt \u00fcber Perf-Indikatoren und drehe die Anzahl statischer HugePages zur\u00fcck. Ich dokumentiere jede Korrektur, damit ich bei Wiederholung schneller handle.<\/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\/09\/linux_hugepages_optimierung_3572.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h3>Rollback-Strategie<\/h3>\n<ul>\n  <li>THP-Einstellung zur\u00fcck auf den vorherigen Modus, Neustart nur wenn n\u00f6tig.<\/li>\n  <li>Statische HugePages schrittweise reduzieren (<code>vm.nr_hugepages<\/code>), nicht hart abschalten.<\/li>\n  <li>Dienstspezifische Flags r\u00fcckg\u00e4ngig machen (<code>innodb_use_large_pages<\/code>, Defrag-Settings), dann erneut messen.<\/li>\n  <li>Protokolliere Vorher\/Nachher-Werte, damit die n\u00e4chste Iteration schneller wird.<\/li>\n<\/ul>\n\n<h2>Checkliste und Gr\u00f6\u00dfenkalkulation<\/h2>\n\n<p>F\u00fcr die Kalkulation statischer <strong>HugePages<\/strong> greife ich zur einfachen Rechnung: Anzahl = Zielgr\u00f6\u00dfe in Byte geteilt durch Seitengr\u00f6\u00dfe (2 MB). Plane ich beispielsweise 32 GB InnoDB-Bufferpool, brauche ich rund 16384 Seiten \u00e0 2 MB. Ich addiere 5\u201310 % Reserve, damit kleine Schwankungen keine Engp\u00e4sse ausl\u00f6sen. Danach pr\u00fcfe ich beim Start, ob die Instanz tats\u00e4chlich auf gro\u00dfe Seiten zugreift. Erf\u00fcllt die Messung die Erwartungen, rolle ich die Einstellung an weiteren Knoten aus.<\/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\/09\/hosting-serverraum-8796.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h3>Hinweis zu 1-GB-HugePages<\/h3>\n<p>Bei sehr gro\u00dfen, stabilen Bufferpools k\u00f6nnen 1-GB-Seiten (<em>HugeTLB<\/em>, CPU\/Kernel-abh\u00e4ngig) zus\u00e4tzlichen TLB-Druck nehmen. Ich setze sie nur ein, wenn der Speicherbedarf langfristig konstant ist und ausreichend gro\u00dfe, zusammenh\u00e4ngende Reserven bereitstehen. Die Einrichtung folgt dem gleichen Muster wie bei 2 MB, erfordert aber engere Planung und Tests, weil Fragmentation und Startverhalten sensibler sind.<\/p>\n\n<h2>Kurz zusammengefasst<\/h2>\n\n<p>Ich setze <strong>linux<\/strong> hugepages gezielt ein: THP typischerweise \u201emadvise\u201c f\u00fcr Web-Stacks, \u201enever\u201c f\u00fcr Redis, und statische Seiten f\u00fcr gro\u00dfe, leseorientierte MariaDB-Pools. So reduziere ich TLB-Misses, halte Latenzen konstant und verhindere Speicher\u00fcberraschungen. PHP-FPM profitiert indirekt, weil Datenbank und Cache flotter antworten. Mit sauberem Benchmarking und Monitoring belege ich die Effekte und sichere die \u00c4nderungen ab. In Kombination mit einem Anbieter, der moderne Kernel-Defaults und passenden Support liefert, bleibt der Stack auch unter Last verl\u00e4sslich schnell.<\/p>","protected":false},"excerpt":{"rendered":"<p>Descubre c\u00f3mo las HugePages de Linux contribuyen a que MariaDB, Redis y PHP-FPM funcionen de forma m\u00e1s r\u00e1pida y estable en el alojamiento web. Centr\u00e1ndonos en las HugePages de Linux, obtendr\u00e1s consejos pr\u00e1cticos sobre la configuraci\u00f3n de THP, el ajuste del kernel y las configuraciones optimizadas para la memoria.<\/p>","protected":false},"author":1,"featured_media":21276,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21283","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":"68","_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":"linux hugepages","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":"21276","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21283","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/comments?post=21283"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21283\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/21276"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=21283"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=21283"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=21283"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}