{"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":"minnesfragmentering-webbhotell-php-mysql-optimering-bytefloede","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/memory-fragmentation-webhosting-php-mysql-optimierung-bytefluss\/","title":{"rendered":"Minnesfragmentering i webbhotell: Prestandaf\u00e4lla f\u00f6r PHP och MySQL"},"content":{"rendered":"<p><strong>Minnesfragmentering<\/strong> I webbhotell saktar PHP-FPM och MySQL ner, \u00e4ven om det verkar finnas tillr\u00e4ckligt med RAM-minne, eftersom minnet delas upp i m\u00e5nga sm\u00e5 block och st\u00f6rre allokeringar misslyckas. Jag visar i praktiken hur fragmentering f\u00f6rdyrar f\u00f6rfr\u00e5gningar, utl\u00f6ser swap och varf\u00f6r m\u00e5linriktad tuning av PHP och MySQL synligt f\u00f6rb\u00e4ttrar laddningstider, tillf\u00f6rlitlighet och skalbarhet.<\/p>\n\n<h2>Centrala punkter<\/h2>\n<ul>\n  <li><strong>PHP-FPM<\/strong> \u00e5tervinna: Starta om processer regelbundet via pm.max_requests<\/li>\n  <li><strong>Buffert<\/strong> dosera: H\u00e5ll MySQL-Per-Connection-Buffer konservativ<\/li>\n  <li><strong>Byta<\/strong> Undvik: Minska swappiness, beakta NUMA<\/li>\n  <li><strong>tabeller<\/strong> Underh\u00e5ll: Kontrollera Data_free, optimera m\u00e5linriktat<\/li>\n  <li><strong>\u00d6vervakning<\/strong> Utnyttja: Se trender tidigt och agera<\/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>Vad betyder minnesfragmentering i det dagliga arbetet med webbhotell?<\/h2>\n\n<p>I hosting tr\u00e4ffar <strong>Fragmentering<\/strong> p\u00e5 l\u00e5ngvariga processer som st\u00e4ndigt beg\u00e4r och frig\u00f6r minne, vilket skapar luckor i adressutrymmet. \u00c4ven om summan av ledigt RAM-minne verkar stor saknas sammanh\u00e4ngande block f\u00f6r st\u00f6rre allokeringar, vilket saktar ner allokeringsf\u00f6rs\u00f6k. Jag ser detta i PHP-FPM-arbetare och i mysqld, som efter n\u00e5gra timmar alltid verkar mer \u201euppbl\u00e5sta\u201c. Effekten g\u00f6r varje f\u00f6rfr\u00e5gan minimalt dyrare och f\u00f6rl\u00e4nger svarstiderna m\u00e4rkbart under belastning. Detta g\u00f6r att toppar som f\u00f6rs\u00e4ljningskampanjer eller s\u00e4kerhetskopieringar blir en bromskloss, \u00e4ven om CPU och n\u00e4tverk f\u00f6rblir op\u00e5verkade.<\/p>\n\n<h2>Varf\u00f6r PHP-FPM skapar fragmentering<\/h2>\n\n<p>Varje PHP-FPM-arbetare laddar kod, plugins och data i en egen <strong>Adressutrymme<\/strong>, hanterar olika f\u00f6rfr\u00e5gningar och l\u00e4mnar efter sig spridda luckor vid frig\u00f6randet. Med tiden v\u00e4xer processerna och frig\u00f6r minne internt, men inte n\u00f6dv\u00e4ndigtvis till operativsystemet, vilket \u00f6kar fragmenteringen. Olika skript, importjobb och bildbearbetning f\u00f6rst\u00e4rker denna blandning och leder till varierande allokeringsm\u00f6nster. Jag observerar detta som en smygande RAM-\u00f6kning, \u00e4ven om belastningen och trafiken verkar konstant. Utan \u00e5tervinning saktar denna interna fragmentering ner allokeringen och f\u00f6rsv\u00e5rar planeringen vid h\u00f6ga bes\u00f6ksantal.<\/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\u00e4rkbara konsekvenser f\u00f6r laddningstider och tillf\u00f6rlitlighet<\/h2>\n\n<p>Fragmenterade processer genererar mer <strong>Overhead<\/strong> i minneshanteringen, vilket yttrar sig i l\u00e5ngsammare admin-backends och trevande utcheckningar. S\u00e4rskilt WordPress-butiker eller stora CMS-instanser reagerar tr\u00f6gt n\u00e4r m\u00e5nga samtidiga f\u00f6rfr\u00e5gningar m\u00f6ter fragmenterade arbetare. Detta resulterar i timeouts, 502\/504-fel och \u00f6kade f\u00f6rs\u00f6k p\u00e5 NGINX- eller Apache-sidan. Jag l\u00e4ser s\u00e5dana situationer i m\u00e4tv\u00e4rden som toppar i svarstiden, stigande RAM-baslinje och pl\u00f6tsligt \u00f6kande swap-anv\u00e4ndning. Den som ignorerar detta f\u00f6rlorar prestanda, f\u00f6rs\u00e4mrar anv\u00e4ndarupplevelsen och \u00f6kar avbrottsfrekvensen i kritiska funnels.<\/p>\n\n<h2>St\u00e4lla in PHP-FPM korrekt: gr\u00e4nser, pooler, \u00e5tervinning<\/h2>\n\n<p>Jag satsar p\u00e5 realistiska <strong>Gr\u00e4nser<\/strong>, separata pooler och konsekvent \u00e5tervinning f\u00f6r att begr\u00e4nsa fragmentering. pm.max_requests avslutar jag s\u00e5 att arbetarna startar om regelbundet utan att st\u00f6ra bes\u00f6kare som \u00e4r online. F\u00f6r trafikprofiler med belastningstoppar passar pm = dynamic ofta b\u00e4ttre, medan pm = ondemand sparar RAM p\u00e5 lugna webbplatser. Jag h\u00e5ller memory_limit per webbplats medvetet m\u00e5ttligt och anpassar det med tanke p\u00e5 verkliga skript; en introduktion finns i \u00e4mnet <a href=\"https:\/\/webhosting.de\/sv\/php-minnesgraens-oeka-undvika-fel-performant\/\">PHP-minnesgr\u00e4ns<\/a>. Dessutom separerar jag projekt med h\u00f6g belastning i egna pooler s\u00e5 att en minneskr\u00e4vande applikation inte p\u00e5verkar alla webbplatser.<\/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, f\u00f6rladdning och PHP-allokator i fokus<\/h2>\n\n<p>F\u00f6r att minska fragmenteringen i PHP-processen satsar jag p\u00e5 en v\u00e4l dimensionerad <strong>OPcache<\/strong>. En gener\u00f6s, men inte \u00f6verdriven opcache.memory_consumption och tillr\u00e4ckligt m\u00e5nga interna str\u00e4ngar minskar upprepade allokeringar per f\u00f6rfr\u00e5gan. Jag observerar tr\u00e4fffrekvens, sl\u00f6seri och restkapacitet; om sl\u00f6seriet \u00f6kar \u00f6ver tid \u00e4r det b\u00e4ttre att planera en omladdning \u00e4n att l\u00e5ta arbetarna v\u00e4xa okontrollerat. F\u00f6rladdning kan h\u00e5lla hot-code stabilt i minnet och d\u00e4rmed j\u00e4mna ut allokeringsm\u00f6nster, f\u00f6rutsatt att kodbasen \u00e4r f\u00f6rberedd f\u00f6r detta. Dessutom \u00e4r jag uppm\u00e4rksam p\u00e5 <strong>Allocator-val<\/strong>: Beroende p\u00e5 distributionen fungerar PHP\u2011FPM och till\u00e4gg med olika Malloc\u2011implementeringar. Alternativa allokatorer som jemalloc minskar fragmenteringen m\u00e4rkbart i vissa inst\u00e4llningar. Jag rullar dock endast ut s\u00e5dana \u00e4ndringar efter att ha testat dem, eftersom fels\u00f6kning, DTrace\/eBPF\u2011profilering och minnesdumps reagerar olika beroende p\u00e5 allokator.<\/p>\n\n<p>F\u00f6r minneskr\u00e4vande uppgifter som bildbearbetning eller export f\u00f6redrar jag separata pooler med sn\u00e4vare gr\u00e4nser. P\u00e5 s\u00e5 s\u00e4tt v\u00e4xer huvudpoolen inte okontrollerat och fragmenteringen f\u00f6rblir isolerad. Dessutom begr\u00e4nsar jag minneskr\u00e4vande till\u00e4gg (t.ex. via milj\u00f6variabler) och anv\u00e4nder backpressure: f\u00f6rfr\u00e5gningar som kr\u00e4ver stora buffertar begr\u00e4nsas eller flyttas till asynkrona k\u00f6er ist\u00e4llet f\u00f6r att \u00f6verbelasta alla arbetare samtidigt.<\/p>\n\n<h2>F\u00f6rst\u00e5 MySQL-minnet: buffertar, anslutningar, tabeller<\/h2>\n\n<p>I MySQL skiljer jag mellan globala <strong>Buffert<\/strong> som InnoDB-buffertpoolen, buffert per anslutning och tillf\u00e4lliga strukturer som kan v\u00e4xa f\u00f6r varje operation. F\u00f6r stora v\u00e4rden leder till exploderande RAM-behov och mer fragmentering p\u00e5 OS-niv\u00e5 vid h\u00f6g anslutningsbelastning. Dessutom splittras tabeller genom uppdateringar\/raderingar och l\u00e4mnar efter sig Data_free-andelar som f\u00f6rs\u00e4mrar utnyttjandet av buffertpoolen. Jag kontrollerar d\u00e4rf\u00f6r regelbundet storlek, tr\u00e4ffkvoter och antalet tillf\u00e4lliga disktabeller. F\u00f6ljande \u00f6versikt hj\u00e4lper mig att korrekt identifiera typiska symptom och v\u00e4ga in \u00e5tg\u00e4rder.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Symptom<\/th>\n      <th>Sannolik orsak<\/th>\n      <th>M\u00e5tt<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>RAM \u00f6kar stadigt, swap b\u00f6rjar<\/td>\n      <td>F\u00f6r stor buffertpool eller m\u00e5nga buffertar per anslutning<\/td>\n      <td>Begr\u00e4nsa poolens storlek, minska per-anslutningsbuffert<\/td>\n    <\/tr>\n    <tr>\n      <td>M\u00e5nga l\u00e5ngsamma sorter\/sammanfogningar<\/td>\n      <td>Saknade index, \u00f6verbelastade sort\/join-buffertar<\/td>\n      <td>Kontrollera index, h\u00e5ll sort\/join konservativt<\/td>\n    <\/tr>\n    <tr>\n      <td>Stor Data_free i tabeller<\/td>\n      <td>Stora uppdateringar\/raderingar, sidor splittrade<\/td>\n      <td>M\u00e5lmedvetet OPTIMIZE, arkivering, schemabantning<\/td>\n    <\/tr>\n    <tr>\n      <td>Toppar i tempor\u00e4ra disk-tabeller<\/td>\n      <td>F\u00f6r liten tmp_table_size eller ol\u00e4mpliga fr\u00e5gor<\/td>\n      <td>H\u00f6j v\u00e4rdena m\u00e5ttligt, omstrukturera fr\u00e5gorna<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>MySQL Memory Tuning: V\u00e4lj storlek ist\u00e4llet f\u00f6r att \u00f6verdriva<\/h2>\n\n<p>Jag v\u00e4ljer InnoDB-buffertpoolen s\u00e5 att <strong>Operativsystem<\/strong> tillr\u00e4ckligt med utrymme f\u00f6r filsystemets cache och tj\u00e4nster, s\u00e4rskilt f\u00f6r kombiserverar med webb och databas. Per-anslutningsbuffert som sort_buffer_size, join_buffer_size och read-Buffer skalar jag konservativt s\u00e5 att m\u00e5nga samtidiga anslutningar inte leder till RAM-stormar. tmp_table_size och max_heap_table_size st\u00e4ller jag in s\u00e5 att oviktiga operationer inte kr\u00e4ver enorma tabeller i minnet. F\u00f6r ytterligare justeringsm\u00f6jligheter hittar jag under <a href=\"https:\/\/webhosting.de\/sv\/optimera-mysql-prestanda-problem-tips-hardvaruskalering-cachehastighet\/\">MySQL-prestanda<\/a> Hj\u00e4lpsamma tankest\u00e4llare. Det avg\u00f6rande \u00e4r fortfarande: Jag st\u00e4ller hellre in n\u00e5got knappare och m\u00e4ter \u00e4n att blint skruva upp och riskera fragmentering plus 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 detalj: Strategier f\u00f6r \u00e5teruppbyggnad och poolinstanser<\/h2>\n\n<p>F\u00f6r att h\u00e5lla MySQL internt \u201ekompakter\u201c planerar jag regelbundna <strong>Ombyggnader<\/strong> f\u00f6r tabeller med stor andel skrivningar. En m\u00e5linriktad OPTIMIZE TABLE (eller en online-ombyggnad med ALTER) sammanf\u00f6r data och index och minskar <em>Data_free<\/em>. Jag v\u00e4ljer tidsf\u00f6nster med l\u00e5g belastning, eftersom \u00e5teruppbyggnader \u00e4r I\/O-intensiva. Alternativet <em>innodb_file_per_table<\/em> Jag h\u00e5ller den aktiv eftersom den till\u00e5ter tabellkontrollerade \u00e5teruppbyggnader och minskar risken f\u00f6r att enskilda \u201eproblembarn\u201c fragmenterar hela tabellutrymmesfilen.<\/p>\n\n<p>Jag anv\u00e4nder flera <strong>Buffertpoolinstanser<\/strong> (innodb_buffer_pool_instances) i f\u00f6rh\u00e5llande till poolstorlek och CPU-k\u00e4rnor f\u00f6r att avlasta interna l\u00e5sningar och f\u00f6rdela \u00e5tkomster. Detta f\u00f6rb\u00e4ttrar inte bara parallelliteten, utan j\u00e4mnar ocks\u00e5 ut allokeringsm\u00f6nstren i poolen. Dessutom kontrollerar jag storleken p\u00e5 redo-loggarna och aktiviteten hos purge-tr\u00e5darna, eftersom uppbyggd historik kan binda minne och I\/O, vilket f\u00f6rst\u00e4rker fragmenteringen p\u00e5 OS-niv\u00e5. Det \u00e4r viktigt att \u00e4ndra inst\u00e4llningarna stegvis, m\u00e4ta och endast beh\u00e5lla dem om latenser och felfrekvenser faktiskt minskar.<\/p>\n\n<h2>Undvika swap: Kernel-inst\u00e4llningar och NUMA<\/h2>\n\n<p>S\u00e5 snart Linux aktiverar swap \u00f6kar svarstiderna med <strong>storleksordningar<\/strong>, eftersom RAM-\u00e5tkomst blir l\u00e5ngsam I\/O. Jag s\u00e4nker vm.swappiness avsev\u00e4rt s\u00e5 att k\u00e4rnan anv\u00e4nder fysiskt RAM l\u00e4ngre. P\u00e5 v\u00e4rdar med flera processorer kontrollerar jag NUMA-topologin och aktiverar interleaving vid behov f\u00f6r att minska oj\u00e4mn minnesanv\u00e4ndning. F\u00f6r bakgrundsinformation och information om h\u00e5rdvarans p\u00e5verkan hj\u00e4lper mig perspektivet p\u00e5 <a href=\"https:\/\/webhosting.de\/sv\/blogg-numa-arkitektur-serverprestanda-hosting-hardvara-optimering-infrastruktur\/\">NUMA-arkitektur<\/a>. Dessutom planerar jag s\u00e4kerhetsreserver f\u00f6r sidcache, eftersom en utt\u00f6md cache p\u00e5skyndar fragmenteringen av hela maskinen.<\/p>\n\n<h2>Transparenta stora sidor, \u00f6verf\u00f6rpliktelse och val av allokator<\/h2>\n\n<p><strong>Transparenta stora sidor<\/strong> (THP) kan leda till latensspikar i databaser eftersom sammanfogning\/delning av stora sidor sker vid ol\u00e4mpliga tidpunkter. Jag st\u00e4ller in THP p\u00e5 \u201emadvise\u201c eller inaktiverar det om MySQL reagerar f\u00f6r l\u00e5ngsamt under belastning. Samtidigt noterar jag <strong>\u00d6verengagemang<\/strong>: Med en f\u00f6r gener\u00f6s vm.overcommit_memory-konfiguration riskerar man OOM-kills just n\u00e4r fragmentering g\u00f6r stora sammanh\u00e4ngande block s\u00e4llsynta. Jag f\u00f6redrar konservativa \u00f6verf\u00f6rbindningsinst\u00e4llningar och kontrollerar regelbundet kernel-loggar f\u00f6r tecken p\u00e5 minnespress.<\/p>\n\n<p>Den <strong>Allocator-val<\/strong> p\u00e5 systemniv\u00e5 \u00e4r v\u00e4rt att titta p\u00e5. glibc\u2011malloc, jemalloc eller tcmalloc beter sig olika n\u00e4r det g\u00e4ller fragmentering. Jag testar alltid alternativ isolerat, m\u00e4ter RSS\u2011f\u00f6rlopp och latenser och rullar endast ut \u00e4ndringar om m\u00e4tv\u00e4rdena f\u00f6rblir stabila under verklig trafik. Nyttan varierar kraftigt beroende p\u00e5 arbetsbelastning, f\u00f6rl\u00e4ngningsmix och 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>Identifiera fragmentering: m\u00e4tv\u00e4rden och tips<\/h2>\n\n<p>Jag uppm\u00e4rksammar l\u00e5ngsamt stigande <strong>baslinjer<\/strong> vid RAM, fler 5xx-svar under belastning och f\u00f6rdr\u00f6jningar vid administrat\u00f6rs\u00e5tg\u00e4rder. En titt p\u00e5 PM-statistik fr\u00e5n PHP-FPM visar om barnprocesser n\u00e5r gr\u00e4nserna eller lever f\u00f6r l\u00e4nge. I MySQL kontrollerar jag tr\u00e4ffkvoter, tempor\u00e4ra tabeller p\u00e5 disk och Data_free per tabell. Parallellt hj\u00e4lper OS-metriker som Page Faults, Swap-In\/Out och Memory-Fragmentation-indikatorer beroende p\u00e5 k\u00e4rnversion. Den som sammanf\u00f6r dessa signaler kan tidigt uppt\u00e4cka m\u00f6nster och planera \u00e5tg\u00e4rder.<\/p>\n\n<h2>F\u00f6rdjupa \u00f6vervakningen: Hur jag sammanf\u00f6r signaler<\/h2>\n\n<p>Jag korrelerar <strong>Applikationsm\u00e4tningar<\/strong> (p95\/p99-latenser, felfrekvenser) med <strong>processm\u00e5tt<\/strong> (RSS per FPM-arbetare, mysqld-minne) och <strong>OS-v\u00e4rden<\/strong> (Pagecache, Slab, Major Faults). I PHP\u2011FPM anv\u00e4nder jag statusgr\u00e4nssnittet f\u00f6r k\u00f6er, aktiva\/spawned Children och arbetarnas livsl\u00e4ngd. I MySQL observerar jag Created_tmp_disk_tables, Handler_write\/Handler_tmp_write samt Buffer\u2011Pool\u2011Misses. Dessutom tittar jag p\u00e5 processkartor (pmap\/smaps) f\u00f6r att ta reda p\u00e5 om m\u00e5nga sm\u00e5 arenor har skapats. Viktigt f\u00f6r mig \u00e4r <strong>trendorientering<\/strong>: Det \u00e4r inte den enskilda toppen, utan den gradvisa f\u00f6rskjutningen \u00f6ver timmar\/dagar som avg\u00f6r om fragmenteringen blir ett verkligt hot.<\/p>\n\n<h2>Praktisk rutin: underh\u00e5ll och datahantering<\/h2>\n\n<p>Jag st\u00e4dar regelbundet <strong>Uppgifter<\/strong> p\u00e5: utg\u00e5ngna sessioner, gamla loggar, on\u00f6diga revisioner och \u00f6vergivna cacher. F\u00f6r tabeller som f\u00f6r\u00e4ndras mycket planerar jag specifika OPTIMIZE-f\u00f6nster f\u00f6r att sammanfoga fragmenterade sidor. Jag f\u00f6rdelar stora importjobb eller cron-v\u00e5gor \u00f6ver tid s\u00e5 att inte alla processer beg\u00e4r maximal buffert samtidigt. Vid v\u00e4xande projekt separerar jag webb och databas i ett tidigt skede f\u00f6r att isolera minneskr\u00e4vande m\u00f6nster. Denna disciplin h\u00e5ller arbetsminnet mer sammanh\u00e4ngande och minskar risken f\u00f6r burst-latenser.<\/p>\n\n<h2>Ber\u00e4kna storlekar korrekt: dimensionera gr\u00e4nser och pooler<\/h2>\n\n<p>Jag best\u00e4mmer pm.max_children utifr\u00e5n det faktiskt tillg\u00e4ngliga RAM-minnet f\u00f6r PHP. F\u00f6r detta m\u00e4ter jag <strong>genomsnittlig RSS<\/strong> av en arbetare under verklig belastning (inklusive ut\u00f6kningar och OPcache) och l\u00e4gger till s\u00e4kerhetsmarginaler f\u00f6r toppar. Exempel: P\u00e5 en 16 GB-v\u00e4rd reserverar jag 4\u20136 GB f\u00f6r OS, sidcache och MySQL. D\u00e5 \u00e5terst\u00e5r 10 GB f\u00f6r PHP; vid 150 MB per arbetare blir det teoretiskt 66 barn. I praktiken s\u00e4tter jag pm.max_children till ~80\u201390% av detta v\u00e4rde f\u00f6r att l\u00e4mna utrymme f\u00f6r toppar, allts\u00e5 ungef\u00e4r 52\u201358. <strong>pm.max_f\u00f6rfr\u00e5gningar<\/strong> Jag v\u00e4ljer s\u00e5 att arbetare \u00e5tervinns innan m\u00e4rkbar fragmentering uppst\u00e5r (ofta i intervallet 500\u20132 000, beroende p\u00e5 kodmixen). <\/p>\n\n<p>F\u00f6r MySQL ber\u00e4knar jag <strong>Buffertpool<\/strong> fr\u00e5n den aktiva datastorleken, inte fr\u00e5n den totala DB-storleken. Viktiga tabeller och index b\u00f6r rymmas, men OS-cachen beh\u00f6ver utrymme f\u00f6r binloggar, socklar och statiska tillg\u00e5ngar. Per anslutningsbuffert r\u00e4knar jag med maximal realistisk parallellitet. Om 200 anslutningar \u00e4r m\u00f6jliga dimensionerar jag inte s\u00e5 att det totalt exploderar flera gigabyte per anslutning, utan s\u00e4tter h\u00e5rda gr\u00e4nser som inte \u00e4r farliga f\u00f6r swap \u00e4ven under toppbelastning.<\/p>\n\n<h2>Koppla bort k\u00f6er, bildbehandling och sidouppgifter<\/h2>\n\n<p>M\u00e5nga fragmenteringsproblem uppst\u00e5r n\u00e4r <strong>extrajobb<\/strong> samma pooler som frontend-f\u00f6rfr\u00e5gningar. F\u00f6r exporter, crawling, bildkonverteringar eller uppdateringar av s\u00f6kindex anv\u00e4nder jag separata FPM-pooler eller CLI-jobb med tydliga <em>ulimit<\/em>-gr\u00e4nser. Bildoperationer med GD\/Imagick begr\u00e4nsar jag dessutom med l\u00e4mpliga resursbegr\u00e4nsningar, s\u00e5 att enskilda stora konverteringar inte \u201ehackar s\u00f6nder\u201c hela adressutrymmet. Jag planerar jobben tidsf\u00f6rskjutna och ger dem egna samtidighetsbegr\u00e4nsningar, s\u00e5 att de inte kraschar frontend-v\u00e4gen.<\/p>\n\n<h2>Containrar och virtualisering: Cgroups, OOM och ballongeffekter<\/h2>\n\n<p>I containrar observerar jag <strong>Minnesbegr\u00e4nsningar<\/strong> och OOM-Killer s\u00e4rskilt noggrant. Fragmentering g\u00f6r att processer k\u00f6rs tidigare vid Cgroup-gr\u00e4nser, \u00e4ven om det fortfarande finns ledigt RAM-minne i v\u00e4rden. Jag anpassar pm.max_children strikt efter containergr\u00e4nsen och h\u00e5ller tillr\u00e4ckligt med reserv f\u00f6r att d\u00e4mpa toppar. Jag undviker swapping inom containrar (eller p\u00e5 v\u00e4rden) eftersom den extra indirektionen f\u00f6rst\u00e4rker latensspikar. I virtuella maskiner kontrollerar jag ballongning och KSM\/UKSM. Aggressiv deduplicering sparar visserligen RAM, men kan orsaka ytterligare latens och f\u00f6rvr\u00e4nga fragmenteringsbilden. <\/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 checklista utan punktlistor<\/h2>\n\n<p>Jag s\u00e4tter f\u00f6rst upp ett realistiskt m\u00e5l. <strong>memory_limit<\/strong> per webbplats och observerar hur toppanv\u00e4ndningen utvecklas \u00f6ver flera dagar. D\u00e4refter justerar jag PHP-FPM med l\u00e4mpliga pm-v\u00e4rden och ett rimligt pm.max_requests s\u00e5 att fragmenterade arbetare fungerar som planerat. F\u00f6r MySQL fokuserar jag p\u00e5 en l\u00e4mplig buffertpoolstorlek och konservativa buffertar per anslutning ist\u00e4llet f\u00f6r generella f\u00f6rstoringar. P\u00e5 kernelns sida s\u00e4nker jag swappiness, kontrollerar NUMA-inst\u00e4llningar och h\u00e5ller reserver f\u00f6r sidcachen fria. Slutligen utv\u00e4rderar jag tabeller med Data_free-avvikelser och planerar optimeringar utanf\u00f6r den dagliga verksamheten.<\/p>\n\n<h2>Kort sammanfattat: Vad som \u00e4r viktigt i verksamheten<\/h2>\n\n<p>Jag uppn\u00e5r b\u00e4sta effekt mot minnesfragmentering genom konsekvent <strong>\u00e5tervinning<\/strong> PHP-FPM-arbetare, m\u00e5ttliga gr\u00e4nser och rena pooler. MySQL drar nytta av rimliga storlekar f\u00f6r buffertpool och buffert per anslutning samt av rensade tabeller. Jag undviker proaktivt swap genom att beakta swappiness och NUMA och reservera ledigt RAM-minne f\u00f6r filcachen. \u00d6vervakning avsl\u00f6jar smygande m\u00f6nster innan anv\u00e4ndarna m\u00e4rker det och m\u00f6jligg\u00f6r lugna, planerade ingrepp. Den som anv\u00e4nder dessa verktyg p\u00e5 ett disciplinerat s\u00e4tt h\u00e5ller PHP och MySQL snabbare, mer tillf\u00f6rlitliga och kostnadseffektiva utan omedelbara h\u00e5rdvaruuppgraderingar.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e4r dig hur minnesfragmentering bromsar PHP och MySQL i webbhotell och hur m\u00e5linriktad mysql-minnesoptimering f\u00f6rb\u00e4ttrar din prestanda p\u00e5 l\u00e5ng sikt. Fokus: minnesfragmentering.<\/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":"1787","_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\/sv\/wp-json\/wp\/v2\/posts\/15863","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=15863"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/15863\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/15856"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=15863"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=15863"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=15863"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}