{"id":15863,"date":"2025-12-07T11:51:26","date_gmt":"2025-12-07T10:51:26","guid":{"rendered":"https:\/\/webhosting.de\/memory-fragmentation-webhosting-php-mysql-optimierung-bytefluss\/"},"modified":"2025-12-07T11:51:26","modified_gmt":"2025-12-07T10:51:26","slug":"hukommelsesfragmentering-webhosting-php-mysql-optimering-byteflow","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/memory-fragmentation-webhosting-php-mysql-optimierung-bytefluss\/","title":{"rendered":"Memory Fragmentation i webhosting: Ydelsesf\u00e6lde for PHP &amp; MySQL"},"content":{"rendered":"<p><strong>Hukommelsesfragmentering<\/strong> I webhosting bremser PHP\u2011FPM og MySQL, selvom der tilsyneladende er nok RAM til r\u00e5dighed, fordi hukommelsen opdeles i mange sm\u00e5 blokke, og st\u00f8rre allokeringer mislykkes. Jeg viser i praksis, hvordan fragmentering g\u00f8r foresp\u00f8rgsler dyrere, udl\u00f8ser swap, og hvorfor m\u00e5lrettet tuning af PHP og MySQL \u00f8ger indl\u00e6sningstider, p\u00e5lidelighed og skalering markant.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<ul>\n  <li><strong>PHP-FPM<\/strong> Genbrug: Genstart processer regelm\u00e6ssigt via pm.max_requests<\/li>\n  <li><strong>Buffer<\/strong> dosering: Hold MySQL-Per-Connection-Buffer konservativ<\/li>\n  <li><strong>Bytte<\/strong> Undg\u00e5: S\u00e6nk swappiness, v\u00e6r opm\u00e6rksom p\u00e5 NUMA<\/li>\n  <li><strong>Tabeller<\/strong> Vedligeholdelse: Kontroller Data_free, optimer m\u00e5lrettet<\/li>\n  <li><strong>Overv\u00e5gning<\/strong> Udnyt: Se tendenser tidligt og handle<\/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\/2025\/12\/php-mysql-fragmentierung-7243.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvad betyder hukommelsesfragmentering i den daglige hosting?<\/h2>\n\n<p>I hosting m\u00f8des <strong>Fragmentering<\/strong> langvarige processer, der konstant anmoder om og frigiver hukommelse, hvilket skaber huller i adresserummet. Selvom den samlede m\u00e6ngde ledig RAM virker stor, mangler der sammenh\u00e6ngende blokke til st\u00f8rre allokeringer, hvilket forsinker allokeringsfors\u00f8g. Jeg ser dette i PHP\u2011FPM-arbejdere og i mysqld, som efter flere timer altid virker mere \u201eoppustede\u201c. Effekten g\u00f8r hver anmodning minimalt dyrere og \u00f8ger svarstiderne m\u00e6rkbart under belastning. Dette g\u00f8r, at spidsbelastninger som salgsaktioner eller sikkerhedskopieringer bliver en bremseklods, selvom CPU og netv\u00e6rk forbliver up\u00e5virkede.<\/p>\n\n<h2>Hvorfor PHP-FPM skaber fragmentering<\/h2>\n\n<p>Hver PHP\u2011FPM\u2011Worker indl\u00e6ser kode, plugins og data i sin egen <strong>Adresserum<\/strong>, behandler forskellige anmodninger og efterlader spredte huller, n\u00e5r de frigives. Over tid vokser processer og frigiver intern hukommelse, men ikke n\u00f8dvendigvis til operativsystemet, hvilket \u00f8ger fragmenteringen. Forskellige scripts, importjob og billedbehandling forst\u00e6rker denne blanding og f\u00f8rer til skiftende allokeringsm\u00f8nstre. Jeg observerer dette som en snigende stigning i RAM, selvom belastningen og trafikken virker konstant. Uden genbrug forsinker denne interne fragmentering allokeringen og g\u00f8r det vanskeligt at planl\u00e6gge ved h\u00f8je bes\u00f8gsantal.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/memoryfragmentierung_meeting_7421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>M\u00e6rkbare konsekvenser for opladningstider og p\u00e5lidelighed<\/h2>\n\n<p>Fragmenterede processer skaber mere <strong>Overhead<\/strong> i hukommelsesadministrationen, hvilket udm\u00f8nter sig i langsommere admin-backends og t\u00f8vende checkouts. Is\u00e6r WordPress-butikker eller store CMS-instanser reagerer tr\u00e6gt, n\u00e5r mange samtidige anmodninger m\u00f8der fragmenterede arbejdere. Dette resulterer i timeouts, 502\/504-fejl og \u00f8gede gentagelser p\u00e5 NGINX- eller Apache-siden. Jeg afl\u00e6ser s\u00e5danne situationer i m\u00e5linger som spidsbelastninger i responstiden, stigende RAM-baselinje og pludselig stigende swap-brug. Hvis man ignorerer dette, g\u00e5r man glip af ydeevne, forringer brugeroplevelsen og \u00f8ger afbrydelsesraten i kritiske funnels.<\/p>\n\n<h2>Indstil PHP-FPM korrekt: Begr\u00e6nsninger, puljer, genbrug<\/h2>\n\n<p>Jeg satser p\u00e5 realistiske <strong>Gr\u00e6nser<\/strong>, separate puljer og konsekvent genbrug for at begr\u00e6nse fragmentering. pm.max_requests afslutter jeg, s\u00e5 arbejdere regelm\u00e6ssigt starter forfra uden at forstyrre bes\u00f8gende. For trafikprofiler med belastningsspidser passer pm = dynamic ofte bedre, mens pm = ondemand sparer RAM p\u00e5 rolige websteder. Jeg holder memory_limit pr. websted bevidst moderat og tilpasser det med henblik p\u00e5 reelle scripts; emnet giver en indgang til dette. <a href=\"https:\/\/webhosting.de\/da\/php-memory-limit-increase-undga-fejl-performant\/\">PHP-hukommelsesgr\u00e6nse<\/a>. Derudover opdeler jeg projekter med stor belastning i separate puljer, s\u00e5 en hukommelsessluger ikke p\u00e5virker alle websteder.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/memory-fragmentierung-php-mysql-7348.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>OPcache, preloading og PHP-allocator i fokus<\/h2>\n\n<p>For at mindske fragmentering i PHP-processen satser jeg p\u00e5 en korrekt dimensioneret <strong>OPcache<\/strong>. En gener\u00f8s, men ikke overdreven opcache.memory_consumption og tilstr\u00e6kkelige interne strenge reducerer gentagne allokeringer pr. anmodning. Jeg overv\u00e5ger hitrate, spild og restkapacitet; hvis spildet stiger over tid, er en planlagt genindl\u00e6sning bedre end at lade arbejdere vokse ukontrolleret. Preloading kan holde hot-code stabilt i hukommelsen og dermed udj\u00e6vne allokeringsm\u00f8nstre, forudsat at kodebasen er forberedt i overensstemmelse hermed. Derudover holder jeg \u00f8je med <strong>Allocator-valg<\/strong>: Afh\u00e6ngigt af distributionen fungerer PHP\u2011FPM og udvidelser med forskellige Malloc\u2011implementeringer. Alternative Allocator som jemalloc reducerer i nogle ops\u00e6tninger fragmenteringen m\u00e6rkbart. Jeg implementerer dog kun s\u00e5danne \u00e6ndringer efter at have testet dem, da debugging, DTrace\/eBPF\u2011profilering og hukommelsesdumps reagerer forskelligt afh\u00e6ngigt af Allocator.<\/p>\n\n<p>Til hukommelseskr\u00e6vende opgaver som billedbehandling eller eksport foretr\u00e6kker jeg separate puljer med sn\u00e6vrere gr\u00e6nser. P\u00e5 den m\u00e5de vokser hovedpuljen ikke ukontrolleret, og fragmentering forbliver isoleret. Desuden begr\u00e6nser jeg hukommelseskr\u00e6vende udvidelser (f.eks. via milj\u00f8variabler) og bruger backpressure: Anmodninger, der kr\u00e6ver store buffere, begr\u00e6nses eller flyttes til asynkrone k\u00f8er i stedet for at overbelaste alle arbejdere p\u00e5 samme tid.<\/p>\n\n<h2>Forst\u00e5 MySQL-hukommelse: Buffer, forbindelser, tabeller<\/h2>\n\n<p>I MySQL skelner jeg mellem globale <strong>Buffer<\/strong> som InnoDB-bufferpoolen, bufferen pr. forbindelse og midlertidige strukturer, der kan vokse for hver operation. For store v\u00e6rdier f\u00f8rer til eksplosiv RAM-behov og mere fragmentering p\u00e5 OS-niveau ved h\u00f8j forbindelsesbelastning. Derudover bliver tabeller \u00f8delagt af opdateringer\/sletninger og efterlader Data_free-andele, som g\u00f8r det sv\u00e6rere at udnytte bufferpoolen. Derfor kontrollerer jeg regelm\u00e6ssigt st\u00f8rrelse, hit-ratios og antallet af midlertidige disktabeller. F\u00f8lgende oversigt hj\u00e6lper mig med at identificere typiske symptomer og afveje mulige foranstaltninger.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Symptom<\/th>\n      <th>Sandsynlig \u00e5rsag<\/th>\n      <th>M\u00e5l<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>RAM stiger konstant, swap begynder<\/td>\n      <td>For stor bufferpool eller mange buffere pr. forbindelse<\/td>\n      <td>Begr\u00e6ns pool til passende st\u00f8rrelse, s\u00e6nk via forbindelsesbuffer<\/td>\n    <\/tr>\n    <tr>\n      <td>Mange langsomme sorteringer\/sammenf\u00f8jninger<\/td>\n      <td>Manglende indekser, overdrevne sort\/join-buffere<\/td>\n      <td>Kontroller indekser, hold sort\/join konservativt<\/td>\n    <\/tr>\n    <tr>\n      <td>Stor Data_free i tabeller<\/td>\n      <td>Store opdateringer\/sletninger, sider splittet<\/td>\n      <td>M\u00e5lrettet OPTIMIZE, arkivering, str\u00f8mlinjeformning af skemaer<\/td>\n    <\/tr>\n    <tr>\n      <td>Spidsbelastninger ved midlertidige disktabeller<\/td>\n      <td>For lille tmp_table_size eller uegnede foresp\u00f8rgsler<\/td>\n      <td>H\u00e6v v\u00e6rdierne moderat, omstruktur\u00e9r foresp\u00f8rgsler<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>MySQL Memory Tuning: V\u00e6lg st\u00f8rrelser i stedet for at overdrive<\/h2>\n\n<p>Jeg v\u00e6lger InnoDB-bufferpuljen, s\u00e5 <strong>Operativsystem<\/strong> har tilstr\u00e6kkelig kapacitet til filsystemcache og tjenester, is\u00e6r p\u00e5 kombiservere med web og DB. Per-forbindelsesbuffer som sort_buffer_size, join_buffer_size og read-buffer skalerer jeg konservativt, s\u00e5 mange samtidige forbindelser ikke f\u00f8rer til RAM-storm. tmp_table_size og max_heap_table_size indstiller jeg, s\u00e5 uvigtige operationer ikke kr\u00e6ver enorme in-memory-tabeller. For yderligere justeringsmuligheder finder jeg under <a href=\"https:\/\/webhosting.de\/da\/optimer-mysql-ydeevne-problemer-tips-hardware-skalering-cache-hastighed\/\">MySQL-ydeevne<\/a> Hj\u00e6lpsomme tanker. Det afg\u00f8rende er stadig: Jeg foretr\u00e6kker at indstille lidt mere sparsomt og m\u00e5le, frem for at skrue op i blinde og risikere fragmentering og swap.<\/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\/2025\/12\/memoryfragmentation_office_4217.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>InnoDB i detaljer: Genopbygningsstrategier og poolinstanser<\/h2>\n\n<p>For at holde MySQL internt \u201emere kompakt\u201c planl\u00e6gger jeg regelm\u00e6ssige <strong>Genopbygninger<\/strong> til tabeller med stor skriveandel. En m\u00e5lrettet OPTIMIZE TABLE (eller en online-genopbygning via ALTER) samler data og indekser og reducerer <em>Data_free<\/em>. Jeg v\u00e6lger tidsvinduer med lav belastning, da genopbygninger er I\/O-intensive. Indstillingen <em>innodb_file_per_table<\/em> Jeg holder den aktiv, fordi den tillader tabelstyrede genopbygninger og mindsker risikoen for, at enkelte \u201eproblemb\u00f8rn\u201c fragmenterer hele tablespace-filen.<\/p>\n\n<p>Jeg bruger flere <strong>Bufferpool-instanser<\/strong> (innodb_buffer_pool_instances) i forhold til poolst\u00f8rrelse og CPU-kerner for at aflaste interne latches og fordele adgangen. Dette forbedrer ikke kun paralleliteten, men udj\u00e6vner ogs\u00e5 allokeringsm\u00f8nstrene i poolen. Derudover kontrollerer jeg st\u00f8rrelsen af redo-logfilerne og aktiviteten af purge-tr\u00e5dene, da opbygget historik kan binde hukommelse og I\/O, hvilket \u00f8ger fragmenteringen p\u00e5 OS-niveau. Det er vigtigt at \u00e6ndre indstillingerne gradvist, m\u00e5le dem og kun beholde dem, hvis latenstider og fejlrater faktisk falder.<\/p>\n\n<h2>Undg\u00e5 swap: Kernel-indstillinger og NUMA<\/h2>\n\n<p>S\u00e5 snart Linux begynder at swappe aktivt, stiger responstiderne med <strong>St\u00f8rrelsesordener<\/strong>, fordi RAM-adgang bliver til langsom I\/O. Jeg s\u00e6nker vm.swappiness betydeligt, s\u00e5 kernen bruger fysisk RAM l\u00e6ngere. P\u00e5 multi-CPU-v\u00e6rter kontrollerer jeg NUMA-topologi og aktiverer interleaving efter behov for at reducere uj\u00e6vn hukommelsesudnyttelse. For baggrundsinformation og hardwarep\u00e5virkning hj\u00e6lper perspektivet p\u00e5 <a href=\"https:\/\/webhosting.de\/da\/blog-numa-arkitektur-server-ydeevne-hosting-hardware-optimering-infrastruktur\/\">NUMA-arkitektur<\/a>. Derudover planl\u00e6gger jeg sikkerhedsreserver til pagecache, da en udt\u00f8mt cache fremskynder fragmenteringen af hele maskinen.<\/p>\n\n<h2>Transparente store sider, overforpligtelse og valg af allokator<\/h2>\n\n<p><strong>Gennemsigtige store sider<\/strong> (THP) kan f\u00f8re til latenstoppe i databaser, fordi sammenl\u00e6gning\/opdeling af store sider sker p\u00e5 et uheldigt tidspunkt. Jeg indstiller THP til \u201emadvise\u201c eller deaktiverer det, hvis MySQL reagerer for langsomt under belastning. Samtidig bem\u00e6rker jeg <strong>Overforpligtelse<\/strong>: Med en for gener\u00f8s vm.overcommit_memory-konfiguration risikerer man OOM-kills netop n\u00e5r fragmentering g\u00f8r store sammenh\u00e6ngende blokke sj\u00e6ldne. Jeg foretr\u00e6kker konservative overcommit-indstillinger og tjekker regelm\u00e6ssigt kernel-logs for tegn p\u00e5 memory pressure.<\/p>\n\n<p>Den <strong>Allocator-valg<\/strong> p\u00e5 systemniveau er v\u00e6rd at kigge p\u00e5. glibc\u2011malloc, jemalloc eller tcmalloc opf\u00f8rer sig forskelligt med hensyn til fragmentering. Jeg tester altid alternativer isoleret, m\u00e5ler RSS\u2011forl\u00f8b og latenstider og implementerer kun \u00e6ndringer, hvis m\u00e5lingerne forbliver stabile under reel trafik. Fordelen varierer meget afh\u00e6ngigt af arbejdsbyrde, udvidelsesmix og OS\u2011version.<\/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\/2025\/12\/memoryfragmentationdev3452.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Genkende fragmentering: Metrikker og tip<\/h2>\n\n<p>Jeg holder \u00f8je med langsomt stigende <strong>basislinjer<\/strong> ved RAM, flere 5xx-svar under belastning og forsinkelser ved administratorhandlinger. Et kig p\u00e5 PM-statistikker fra PHP-FPM viser, om b\u00f8rn st\u00f8der p\u00e5 begr\u00e6nsninger eller lever for l\u00e6nge. I MySQL tjekker jeg hit-ratios, midlertidige tabeller p\u00e5 disken og Data_free pr. tabel. Parallelt hj\u00e6lper OS-metrikker som Page Faults, Swap-In\/Out og Memory-Fragmentation-indikatorer afh\u00e6ngigt af kernelversionen. Hvis man samler disse signaler, kan man tidligt genkende m\u00f8nstre og planl\u00e6gge foranstaltninger.<\/p>\n\n<h2>Uddyb overv\u00e5gningen: Hvordan jeg samler signaler<\/h2>\n\n<p>Jeg korrelerer <strong>Applikationsm\u00e5linger<\/strong> (p95\/p99-latenser, fejlprocenter) med <strong>procesmetrikker<\/strong> (RSS pr. FPM-arbejder, mysqld-hukommelse) og <strong>OS-v\u00e6rdier<\/strong> (Pagecache, Slab, Major Faults). I PHP\u2011FPM bruger jeg statusgr\u00e6nsefladen til k\u00f8-l\u00e6ngder, aktive\/spawned Children og arbejdstagernes levetid. I MySQL observerer jeg Created_tmp_disk_tables, Handler_write\/Handler_tmp_write samt Buffer\u2011Pool\u2011Misses. Derudover ser jeg p\u00e5 proceskort (pmap\/smaps) for at finde ud af, om der er opst\u00e5et mange sm\u00e5 arenaer. Det er vigtigt for mig at <strong>trendorientering<\/strong>: Det er ikke den enkelte spidsbelastning, men den langsomme forskydning over timer\/dage, der afg\u00f8r, om fragmentering bliver en reel fare.<\/p>\n\n<h2>Praktisk rutine: Vedligeholdelse og datapleje<\/h2>\n\n<p>Jeg rydder regelm\u00e6ssigt op <strong>Data<\/strong> p\u00e5: udl\u00f8bne sessioner, gamle logfiler, un\u00f8dvendige revisioner og for\u00e6ldede caches. For tabeller, der \u00e6ndrer sig meget, planl\u00e6gger jeg m\u00e5lrettede OPTIMIZE-vinduer for at samle fragmenterede sider. Store importopgaver eller cron-b\u00f8lger fordeler jeg tidsm\u00e6ssigt, s\u00e5 ikke alle processer kr\u00e6ver maksimal buffer p\u00e5 samme tid. Ved voksende projekter adskiller jeg web og DB tidligt for at isolere m\u00f8nstre, der kr\u00e6ver meget hukommelse. Denne disciplin holder arbejdshukommelsen mere sammenh\u00e6ngende og reducerer risikoen for burst-latenser.<\/p>\n\n<h2>Beregn st\u00f8rrelser korrekt: Dimensioner gr\u00e6nser og puljer<\/h2>\n\n<p>Jeg bestemmer pm.max_children ud fra den faktisk tilg\u00e6ngelige RAM til PHP. Til det m\u00e5ler jeg <strong>gennemsnitlig RSS<\/strong> af en worker under reel belastning (inklusive udvidelser og OPcache) og tilf\u00f8jer sikkerhedsmargener for spidsbelastninger. Eksempel: P\u00e5 en 16 GB-host reserverer jeg 4-6 GB til OS, pagecache og MySQL. Der er 10 GB tilbage til PHP; med 150 MB pr. worker giver det teoretisk 66 b\u00f8rn. I praksis s\u00e6tter jeg pm.max_children til ~80-90% af denne v\u00e6rdi for at give plads til spidsbelastninger, alts\u00e5 ca. 52-58. <strong>pm.max_anmodninger<\/strong> Jeg v\u00e6lger, at arbejdere genbruges, f\u00f8r der opst\u00e5r m\u00e6rkbar fragmentering (ofte i omr\u00e5det 500-2.000, afh\u00e6ngigt af kodeblandingen). <\/p>\n\n<p>For MySQL beregner jeg <strong>Bufferpulje<\/strong> fra den aktive datast\u00f8rrelse, ikke fra den samlede DB-st\u00f8rrelse. Vigtige tabeller og indekser skal kunne v\u00e6re der, men OS-cachen har brug for plads til binlogs, sockets og statiske aktiver. Per-connection-buffer beregner jeg med den maksimale realistiske parallelitet. Hvis 200 forbindelser er mulige, dimensionerer jeg ikke, s\u00e5 der i alt eksploderer flere gigabyte pr. forbindelse, men s\u00e6tter h\u00e5rde gr\u00e6nser, der heller ikke under peak er farlige for swap.<\/p>\n\n<h2>Afkobling af k\u00f8er, billedbehandling og sideopgaver<\/h2>\n\n<p>Mange fragmenteringsproblemer opst\u00e5r, n\u00e5r <strong>bijob<\/strong> de samme puljer som frontend-anmodninger. Til eksport, crawling, billedkonvertering eller opdatering af s\u00f8geindeks bruger jeg separate FPM-puljer eller CLI-jobs med klare <em>ulimit<\/em>-gr\u00e6nser. Jeg begr\u00e6nser billedoperationer med GD\/Imagick yderligere ved hj\u00e6lp af passende ressourcebegr\u00e6nsninger, s\u00e5 enkelte store konverteringer ikke \u201ehakker\u201c hele adresserummet. Jeg planl\u00e6gger job med tidsforskydning og giver dem deres egne samtidighedsbegr\u00e6nsninger, s\u00e5 de ikke overbelaster frontend-stien.<\/p>\n\n<h2>Containere og virtualisering: Cgroups, OOM og balloneffekter<\/h2>\n\n<p>I containere observerer jeg <strong>Hukommelsesgr\u00e6nser<\/strong> og OOM-killeren s\u00e6rligt n\u00f8je. Fragmentering f\u00e5r processer til at k\u00f8re tidligere ved Cgroup-gr\u00e6nser, selvom der stadig er ledig RAM p\u00e5 v\u00e6rten. Jeg tilpasser pm.max_children strengt til containergr\u00e6nsen og holder nok reserve til at afb\u00f8de spidsbelastninger. Jeg undg\u00e5r swapping inden for containere (eller p\u00e5 v\u00e6rten), fordi den ekstra indirektion forst\u00e6rker latenstoppe. I VM'er tjekker jeg balloning og KSM\/UKSM; aggressiv deduplikering sparer RAM, men kan for\u00e5rsage ekstra latenstid og forvr\u00e6nge fragmenteringsbilledet. <\/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\/2025\/12\/hosting-speicherproblem-7392.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kort tjekliste uden punktopstilling<\/h2>\n\n<p>Jeg s\u00e6tter f\u00f8rst et realistisk <strong>memory_limit<\/strong> pr. websted og observerer, hvordan spidsbelastningen udvikler sig over flere dage. Derefter tilpasser jeg PHP-FPM med passende pm-v\u00e6rdier og en fornuftig pm.max_requests, s\u00e5 fragmenterede arbejdere k\u00f8rer som planlagt. For MySQL fokuserer jeg p\u00e5 en passende bufferpoolst\u00f8rrelse og konservative per-connection-buffere i stedet for generelle for\u00f8gelser. P\u00e5 kernelsiden s\u00e6nker jeg swappiness, tjekker NUMA-indstillinger og holder reserver til pagecache fri. Til sidst evaluerer jeg tabeller med Data_free-afvigelser og planl\u00e6gger optimeringer uden for den daglige drift.<\/p>\n\n<h2>Kort sagt: Hvad t\u00e6ller i virksomheden<\/h2>\n\n<p>Jeg opn\u00e5r den st\u00f8rste effekt mod hukommelsesfragmentering ved konsekvent at <strong>genanvendelse<\/strong> PHP-FPM-arbejderen, moderate gr\u00e6nser og rene puljer. MySQL drager fordel af fornuftige st\u00f8rrelser for bufferpuljen og per-forbindelsesbufferen samt ryddelige tabeller. Jeg undg\u00e5r proaktivt swap ved at v\u00e6re opm\u00e6rksom p\u00e5 swappiness og NUMA og reservere ledig RAM til filcachen. Overv\u00e5gning afsl\u00f8rer snigende m\u00f8nstre, f\u00f8r brugerne bem\u00e6rker det, og muligg\u00f8r rolige, planlagte indgreb. Hvis man bruger disse h\u00e5ndtag disciplineret, kan man holde PHP og MySQL hurtigere, mere p\u00e5lidelige og omkostningseffektive uden \u00f8jeblikkelige hardwareopgraderinger.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e6r, hvordan hukommelsesfragmentering bremser PHP og MySQL i webhosting, og hvordan m\u00e5lrettet mysql-hukommelsestuning forbedrer din ydeevne p\u00e5 lang sigt. Fokus: Hukommelsesfragmentering.<\/p>","protected":false},"author":1,"featured_media":15856,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-15863","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"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":"1729","_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":null,"_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":"Memory Fragmentation","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":"15856","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/15863","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=15863"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/15863\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/15856"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=15863"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=15863"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=15863"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}