Videre til indhold 
En Memory Paging Server kan miste betydelig responstid og gennemstrømning under belastning, hvis for mange sider flyttes fra RAM til swap. I denne artikel vil jeg vise dig årsagerne, de målte værdier og de specifikke justeringer, jeg kan foretage for at bremse personsøgningen og øge serverens ydeevne mærkbart.
Centrale punkter
For at give en klar orientering vil jeg kort opsummere de vigtigste budskaber og vise dig, hvor de typiske flaskehalse ligger, og hvordan du kan løse dem. Høje personsøgningshastigheder koster meget Ydelse, fordi adgangen til databærere er meget langsommere end RAM. Målte værdier som Available MBytes, Accessed Bytes og Pages/Second giver mig pålidelige oplysninger. Signaler for nært forestående thrashing. Virtualisering forværrer swapping-effekter gennem ballooning og hypervisor swap, når hosts er overbookede. Jeg reducerer sidefejl med RAM-opgraderinger, THP/huge pages, NUMA-tuning og rene allokeringsmønstre. Regelmæssig overvågning holder Risici og gør belastningstoppe beregnelige.
- Swap vs RAMNanosekunder i RAM vs. mikro-/millisekunder på databærere
- Smadrer: Flere sideoverførsler end nyttigt arbejde, ventetiderne eksploderer
- Fragmentering: Store allokeringer mislykkes trods „fri“ hukommelse
- IndikatorerTilgængelige MBytes, Tilgåede Bytes, Sider/Sek.
- IndstillingTHP/Huge Pages, vm.min_free_kbytes, NUMA, RAM
Sådan fungerer personsøgning på servere
Jeg adskiller virtuel og fysisk hukommelse i faste sider, typisk 4 KB, som er den MMU via sidetabeller. Hvis der bliver mangel på RAM, flytter operativsystemet inaktive sider til swap- eller bytteområder. Hver sidefejl tvinger kernen til at hente data fra databæreren og koster værdifuld RAM. Tid. Store sider som Transparent Huge Pages (THP) reducerer den administrative indsats og minimerer TLB-misses. For begyndere er det værd at tage et kig på virtuel hukommelse, for bedre at forstå forholdet mellem processer, siderammer og swap.
Swap vs. RAM: Forsinkelser og thrashing
RAM reagerer på nanosekunder, mens SSD/HDD reagerer på mikro- til millisekunder og derfor er størrelsesordener hurtigere. langsommere er. Hvis belastningen overstiger den fysiske arbejdshukommelse, øges paging-hastigheden, og CPU'en venter på I/O. Denne effekt kan let føre til thrashing, hvor der bruges mere tid på swapping end på produktivt arbejde. Arbejde går tabt. Især ved brug af 80-90% forringes interaktiviteten og fjernsessionerne. Jeg tjekker Udnyttelse af swaps og trække grænser, før systemet vælter.
Indikatorer og tærskelværdier
Rene målte værdier træffer beslutninger RAM og tuning. På Windows er jeg opmærksom på Available MBytes, cessed Bytes, Pages/Second og Pool paged/nonpaged bytes. På Linux-siden tjekker jeg vmstat, free, sar, ps meminfo og dmesg for out-of-memory events. Stigende sideproblemer med faldende frie MBytes indikerer forestående flaskehalse. Jeg planlægger kritiske tærskler konservativt, så jeg kan undgå belastningstoppe uden at Indbrud afskærmning.
| Præstationsindikator | Sund og rask | Advarsel | Kritisk |
|---|---|---|---|
| \Memory\Pool paged bytes / nonpaged bytes | 0-50% | 60-80% | 80-100% |
| Tilgængelige MBytes | >10% eller 4 GB | <10% | <1% eller <500 MB |
| % Gemte bytes | 0-50% | 60-80% | 80-100% |
Linux: Swappiness, Zswap/ZRAM og tilbageskrivningsparametre
Ud over THP/Huge Pages reducerer jeg mærkbart paging ved at kontrollere aggressiviteten af swapping og writeback. vm.swappiness styrer, hvor tidligt kernen skubber sider ind i swap'en. På servere med meget RAM bruger jeg normalt 1-10, så sidecachen forbliver stor, og inaktive heaps ikke migrerer for tidligt. På meget knappe systemer kan en lidt højere værdi redde interaktiviteten, fordi cachen ikke tørrer helt ud - den afgørende faktor er målingen under reel belastning.
Med Zswap (komprimeret swap i RAM) reducerer jeg I/O-trykket, hvis der er mange kolde sider i kort tid. Det koster CPU-cyklusser, men er ofte billigere end blok-I/O. Til edge- eller laboratoriesystemer bruger jeg nogle gange ZRAM som et primært swap for at gøre små hosts mere robuste; jeg bruger det målrettet i produktionen, når der er CPU-headroom til rådighed.
Jeg styrer skrivestierne via vm.dirty_*-parametre. I stedet for procentværdier foretrækker jeg at arbejde med absolutte bytes for at undgå writeback-storme med store RAM-kapaciteter. Baggrundsskylningen starter tidligt nok, mens beskidte_bytes sætter hårde øvre grænser for dovne arbejdsbelastninger. Eksempler på værdier, som jeg bruger som udgangspunkt:
# begrænset swapping
sysctl -w vm.swappiness=10
# Tjek writeback (bytes i stedet for procent)
sysctl -w vm.dirty_background_bytes=67108864 # 64 MB
sysctl -w vm.dirty_bytes=268435456 # 256 MB
# Kassér ikke VFS-cachen for aggressivt
sysctl -w vm.vfs_cache_pressure=50
På Byt design Jeg foretrækker hurtige NVMe-enheder og sætter prioriteter, så kernen bruger den hurtigste swap først. En dedikeret swap-enhed forhindrer fragmentering af swap-filer.
# Tjek swap-prioriteter
swapon --show
# Aktiver swap på hurtig enhed med høj prioritet
swapon -p 100 /dev/nvme0n1p3
Vigtigt: Jeg overholder større/mindre fejl og I/O-køens dybde parallelt - det er den eneste måde, jeg kan se, om reduceret swappiness eller Zswap udjævner de faktiske latenstidstoppe.
Årsager til høje personsøgningsrater
Hvis der ikke er nogen fysisk arbejdshukommelse, øges adgangsbytes via den indbyggede hukommelse. RAM og systemet skifter til swap. Fragmenteret hukommelse gør store allokeringer sværere, så programmer blokerer på trods af „ledig“ RAM. Dårlige forespørgsler eller manglende indekser øger dataadgangen unødigt og øger arbejdsbyrden. Spidsbelastninger fra backups, implementeringer, ETL eller cron-jobs samler hukommelseskravene i korte tidsvinduer. Virtuelle maskiner kommer under yderligere pres, når værter overbooker RAM og i hemmelighed udfører hypervisor-swaps. Aktiver.
Virtualisering, ballooning og overengagement
I virtualiserede miljøer skjuler hypervisoren den reelle RAM-situation og sætter sin lid til ballooning og swapping inden for RAM. Gæster. Hvis værten løber ind i flaskehalse, mister VM'erne ydeevne på samme tid, selv om de hver især er „grønne“ på egen hånd. Smart paging under opstart skjuler koldstarter, men flytter omkostningerne til I/O-pipelinen. Jeg tjekker værts- og gæstemetrikker sammen og reducerer overcommitment, før brugerne opdager det. Jeg skitserer detaljer om effekten af overcommit i afsnittet om Overengagement i hukommelsen, så kapacitetsplanlægningen forbliver robust.
Containere og Kubernetes: cgroups, grænser og udsættelser
Containere flytter hukommelsesgrænserne fra VM'en til cgroups. Den afgørende faktor er, at anmodninger og grænser er sat realistisk: Grænser, der er for stramme, forårsager tidlige out-of-memory-dødsfald, anmodninger, der er for generøse, forværrer udnyttelsen og foregiver reserver. Jeg holder heaps fra JVM/Node/.NET konsekvent bundet til containergrænser (f.eks. procentvis heuristik), så runtime GC ikke støder på cgroup.
I Kubernetes er jeg opmærksom på QoS-klasser (Guaranteed, Burstable, BestEffort) og Tærskler for udsmidning på node-niveau. Under hukommelsespres favoriserer Kubelet BestEffort-pods - hvis du vil beholde SLO'er, er du nødt til at budgettere ressourcerne korrekt. PSI (Pressure Stall Information) gør cgroup-lokalt pres synligt; jeg bruger disse signaler til proaktivt at skalere eller omplanlægge pods. For workloads med store sider definerer jeg eksplicitte HugePage-anmodninger pr. pod, så planlæggeren vælger passende noder.
Optimeringsstrategier: Hardware og operativsystem
Jeg begynder med den mest nøgterne justeringsskrue: mere RAM fjerner ofte de største forsinkelser med det samme. Sideløbende reducerer jeg sidefejl via THP i „on“- eller „madvise“-tilstand, hvis latency-profilerne tillader det. Reserverede store sider giver forudsigelighed for in-memory-motorer, men kræver præcis kapacitetsplanlægning. Med vm.min_free_kbytes skaber jeg fornuftige reserver til at klare allokeringstoppe uden kompenserende komprimering. Firmware- og kerneopdateringer eliminerer kantfejl, hukommelsesstyring og NUMA-balance.
| Indstilling | Mål | Fordel | Hint |
|---|---|---|---|
| vm.min_fri_kbytes | Reserve til allokeringsspidser | Mindre OOM/komprimering | 5-10% af RAM'en |
| THP (på/rådgiver) | Brug større sider | Mindre fragmentering | Overhold ventetider |
| Store sider | Kontinuerlige blokke | Forudsigelige tildelinger | Fast reservekapacitet |
Databaser og hosting af arbejdsbyrder
Databaser lider hurtigt, når buffer-cachen skrumper, og forespørgsler udføres på grund af swap i I/O drukne. En hårdt begrænset maksimal hukommelsesindstilling beskytter SQL/NoSQL mod gensidig forskydning med filsystemets cache. Indekser, sargability og tilpassede join-strategier reducerer arbejdsbyrden og dermed RAM-presset. I hosting-opsætninger planlægger jeg søgeindekser, cacher og PHP FPM-arbejdere på spidsbelastningstidspunkter, så belastningsprofiler ikke kolliderer. Overvågning af den forventede buffer- og sidelevetid advarer mig tidligt om Nedadgående tendenser.
Øvelse: Måleplan og tuningsplan
Jeg starter med en baseline på 24-72 timer, så de daglige mønstre og opgaver bliver synlige. blive. Derefter indstiller jeg en målprofil for RAM head free, acceptable sider/sekund og maksimale I/O-ventetider. Derefter indfører jeg ændringer trinvist: først grænser, så THP/kæmpe sider, til sidst kapacitet. Jeg måler hver ændring over mindst én belastningscyklus ved hjælp af samme metode. Jeg planlægger aflysninger og dekonstruktioner på forhånd, så jeg kan reagere hurtigt i tilfælde af negative effekter. til at omdirigere.
Reproducerbare belastningstests og kapacitetsprognoser
For at kunne træffe pålidelige beslutninger gengiver jeg typiske arbejdssæt: Varme/kolde cacher, batch-vinduer, spidsbelastninger ved login/checkout. Jeg bruger syntetiske værktøjer (f.eks. stress-ng til hukommelsesstier, fio til I/O og memcached/Redis-benchmarks til cachetyper) til specifikt at simulere hukommelsespres. Jeg kører tests i tre varianter i hvert tilfælde: kun app, app+co-runners (backup, AV-scanning), app+I/O peaks. Det giver mig mulighed for at genkende forstyrrelser, som forbliver skjulte i test, der kun omfatter appen.
Jeg indsamler identiske metrikpaneler (hukommelse, PSI, I/O wait, CPU steal/ready, faults) for hver ændring. En kanariefugl-udrulning med 5-10%-trafik afslører risici tidligt, før jeg ruller konfigurationen bredt ud. Når det gælder kapacitet, planlægger jeg med worst case-arbejdssæt plus reserve - ikke med udjævnede gennemsnit.
Fejlfinding: Værktøjer og signaturer
På Linux giver vmstat, sar, iostat, perf og strace mig de vigtigste oplysninger. Noter for sidefejl, ventetider og heaps. På Windows-siden er jeg afhængig af Performance Monitor, Resource Monitor og ETW-traces. Meddelelser som „compaction stalls“, „kswapd high CPU“ eller OOM kills indikerer alvorlige flaskehalse. Svingende interaktivitet, lange GC-pauser og voksende beskidte sider bekræfter mistanken. Jeg bruger heap-dumps og hukommelsesprofiler til at finde lækager og uhensigtsmæssig Tildelinger.
Windows-specifik praksis: Pagefile, Working Set og Paged Pools
På Windows-servere sikrer jeg en tilstrækkelig dimensioneret Byt fil på hurtige SSD'er og undgå „ingen sidefil“-opsætninger. Faste minimumsstørrelser forhindrer systemet i at krympe og trimme uventet i spidsbelastningsperioder. Jeg fordeler sidefiler på flere diske, hvis det er nødvendigt, og observerer Hårde fejl/sek. og udnyttelsen af paged/nonpaged-pools.
For hukommelsesintensive tjenester aktiverer jeg specifikt Lås sider i hukommelsen (f.eks. til SQL-servere), så kernen ikke skubber workloads ud af arbejdssættet. Samtidig begrænser jeg rent app-caches, så systemet ikke tørrer ud på andre måder. Jeg identificerer driver- eller pool-lækager med PoolMon/RAMMap; i tilfælde af fejl hjælper en kontrolleret trimning af standby-listen med at genoprette interaktiviteten på kort sigt - kun som en diagnose, ikke som en permanent løsning.
Også vigtigt: strømbesparende planer om „maksimal ydelse“, opdaterede NIC/storage-drivere og firmware. Skemalægningsfejl eller forældede filterdrivere fører overraskende ofte til hukommelses- og I/O-spidsbelastninger, som jeg kan misforstå som ren RAM-mangel.
Brug THP, NUMA og sidestørrelser med omtanke
Transparente Huge Pages reducerer TLB-pres, men sporadiske promoveringer kan give ventetidsspidser producer. Til arbejdsopgaver med strenge SLO'er er jeg derfor ofte afhængig af „madvise“ eller faste store sider. NUMA-balancering betaler sig på multi-socket-systemer, hvis tråde og hukommelse forbliver lokale. Jeg knytter tjenester til NUMA-noder og overvåger lokale miss rates. Store sider øger gennemstrømningen, men jeg kontrollerer intern fragmentering, så jeg ikke har give væk.
Filsystemets cache, mmap og I/O-stier
En stor del af den „frie“ hukommelse ligger i Side-cache. Jeg træffer en bevidst beslutning om, hvorvidt en motor bruger OS-cachen (buffered I/O) eller cacher sig selv (direkte I/O). Dobbelte cacher spilder RAM; hvis OS-cachen mangler readahead-forsinkelser. For stream-arbejdsbelastninger kan jeg øge readahead pr. enhed; tilfældigt tunge databaser fungerer bedre med direkte I/O.
# Eksempel: Øg readahead til 256 sektorer
blockdev --setra 256 /dev/nvme0n1
Hukommelsestilpasset I/O (mmap) sparer kopier, men flytter presset til sidecachen. I undtagelsestilfælde fastgør jeg kritiske sider med mlock (eller memlock ulimits) for at undgå jitter på grund af reclaim - altid med et øje på systemreserver.
Hurtige nødforanstaltninger ved hukommelsestryk
- Identificer de største forbrugere (ps/top/procdump), og genstart eller omplanlæg om nødvendigt.
- Begræns midlertidigt samtidigheden (workers/threads) for at reducere fejlraten og tilbageskrivningen.
- Reducer dirty limits på kort sigt, så nedskrivningen træder i kraft tidligere, og der frigøres reserver.
- Evakuer specifikke pods ved container-overcommit; hæv midlertidigt ressourcerne i VM'er eller slap af med ballooning.
- Tjek OOM-strategi: aktiver systemd-oomd/earlyoom og cgroup-kørsler, så de „rigtige“ processer kommer først.
Kapacitetsplanlægning og omkostninger
RAM koster penge, men gentagne fejl koster omsætning og Omdømme. Til web- og databaseservere beregner jeg normalt en reserve på 20-30% til at dække sjældne spidsbelastninger. Et ekstra 64 GB-modul til 180-280 euro afskrives ofte hurtigere end konstant brandslukning. I cloud-miljøer undgår jeg overbooking og booker buffere i etaper, der matcher belastningsmønstre. Nøgterne TCO-beregninger slår pæne diagrammer, fordi de tager højde for latency-skader og operatørtid. pris i.
Kort opsummeret
En Memory Paging Server har mest gavn af tilstrækkelig RAM, en ren THP/huge page-opsætning og realistisk overcommit. Jeg stoler på klare indikatorer som Available MBytes, Accessed Bytes og Pages/Second. Jeg dobbelttjekker virtualiserede miljøer, så ballooning og host swap ikke stjæler skjult performance. Jeg holder databaser væk fra swap med definerede cacher og grænser. Hvis du implementerer disse trin konsekvent, reducerer du latenstider, forhindrer thrashing og holder Strøm stabil over belastningsspidser.
