Avanceret Linux-hukommelsesstyring: En komplet og praktisk guide

Informatic Digital » Recursos » Avanceret Linux-hukommelsesstyring: En komplet og praktisk guide

Hvis du administrerer systemer, arbejder med containere eller vedligeholder produktionsservere, er en grundig forståelse af hukommelsesstyring i Linux ikke længere valgfri. Det er forskellen på en server, der håndterer belastningsstigninger uden at vige, og en, der kæmper, går i spændingstilstand eller ender med at aktivere den frygtede OOM-killer på det værst tænkelige tidspunkt.

Linux er designet til at bruge RAM så effektivt som muligt: ​​det cacher filer, komprimerer sider, flytter data til swap og prioriterer processer i henhold til meget præcise politikker. Udefra set kan det virke som om, det "forbruger en masse hukommelse" eller at "der aldrig er ledig RAM", men i virkeligheden forsøger det at levere maksimal ydeevne og stabilitet . Lad os se, trin for trin og med en smule "lavteknologisk" forklaring, hvordan alt dette fungerer, og hvordan du kan finjustere det på avancerede måder.

Grundlæggende koncepter og myter om hukommelse i Linux

Før man roder med kerneparametre eller monterer zram, som om der ikke er nogen morgendag, er det en god idé at have et par klare ideer om hukommelsestyper, arkitektur og hvordan systemet ser RAM.

Den maksimale mængde fysisk hukommelse, en computer kan håndtere, bestemmes af operativsystemet og processorarkitekturen. Et 32-bit system er typisk begrænset til 4 GB RAM, mens et 64-bit system nemt kan håndtere ti eller hundredvis af gigabyte (teoretisk set meget mere, selvom den faktiske grænse er pålagt af hardwaren).

I Linux administreres al hukommelse som virtuel hukommelse . Dette inkluderer både fysisk RAM og swap-plads. RAM kan ikke "strækkes" undtagen ved at tilføje fysiske moduler, men virtuel hukommelse kan udvides ved hjælp af disk (partitioner eller swap-filer) og avancerede mekanismer som zram eller zswap.

La fysisk hukommelse (RAM) Det er den hurtige og dyre ressource: det er der, processer, biblioteker, filcacher, I/O-buffere, delt hukommelse osv. indlæses. Linux har en meget klar filosofi: hvis der er ledig RAM, er det bedre at bruge den som cache og fremskynde adgangen end at lade den være tom. Derfor ser man kun lidt "ledig" hukommelse i værktøjer som free Det betyder ikke, at du har et problem.

Diskhukommelse ( persistent lagring) er meget langsommere. Mens RAM reagerer på nanosekunder, reagerer selv en SSD på mikrosekunder eller millisekunder. Derfor forsøger systemet at gemme ofte brugte data i RAM og tyr kun til disken, når det er absolut nødvendigt: indlæsning af eksekverbare filer, læsning af kolde data eller udskiftning af sider.

Virtuel hukommelse, sider og interne kernestrukturer

Virtuel hukommelse er den mekanisme, hvormed Linux forsyner hver proces med sit eget isolerede og beskyttede adresserum . Hardwaren og kernen oversætter virtuelle adresser til fysiske adresser gennem strukturer kaldet sidetabeller.

Den mindste enhed, der bruges til at administrere hukommelse, er siden , typisk 4 KB. Hele det virtuelle hukommelsessystem drejer sig om sider: de allokeres, frigøres, byttes, caches og markeres med forskellige tilladelser (skrivebeskyttet, udførelse osv.).

Sidetabeller er hierarkiske strukturer , der vedligeholdes af kernen. De gemmer, for hver virtuel side i hver proces, placeringen af ​​den faktiske fysiske side (hvis den findes), dens tilladelser og dens aktuelle tilstand. Denne oversættelse gør det muligt at isolere processer, dele sider mellem dem og kortlægge filer direkte i hukommelsen.

Når en proces tilgår en gyldig adresse, men siden ikke er klar til adgang, opstår der en sidefejl . Denne kan være let (siden er i RAM, men i en tilstand, der kræver opdatering) eller dyr (siden er på disk, i swap eller i en fil og skal overføres til RAM). Hvis sidefejl bliver hyppige, bliver systemet langsommere, fordi det bruger for meget tid på at læse fra disk.

Sidecachen er cachen af ​​filsider, der vedligeholdes af kernen. Den gemmer data og metadata for filer og mapper for at reducere diskadgang. Dette er en af ​​grundene til , at Linux "ser ud til" at bruge al RAM'en: i virkeligheden udnytter den hukommelse, som applikationer ikke aktivt bruger, til at fremskynde diskadgangen.

Hukommelsestyper: filbaseret, anonym, og hvordan de relaterer sig til swap

I Linux skelner man normalt mellem filhukommelse og anonym hukommelse . Begge findes i RAM, men deres oprindelse og mulige backup til disk er forskellig.

Opkaldet filhukommelse Det er den, der sikkerhedskopieres af systemfiler: eksekverbare binære filer, delte biblioteker, kortlagte data med mmap fra en fil osv. Den hukommelse kan kasseres og genindlæses fra den originale fil, hvis der er behov for plads.

La anonym hukommelse Det er alt, hvad processen reserverer, som ikke er bundet til en fil: den dynamiske heap, stakken, private regioner med MAP_ANONYMOUSog de områder, der er kopieret af kopi-ved-skrivning, når du gør det fork()Denne hukommelse findes kun i RAM (eller i swap, hvis den flyttes), og dens eneste mulige backup er netop i den swap-plads.

Når kernen har brug for at frigøre RAM, vil den først forsøge at frigive sider, som den kan samle igen: typisk sider fra sidecachen eller filbaserede områder. Først når der ikke er mere plads, eller hukommelsestrykket er meget højt, begynder den at skubbe anonym hukommelse ind i swap , hvilket er meget dyrere, men giver systemet en pause.

Hukommelsestryk, thrashing og OOM-dræber

Hukommelsestryk opstår, når antallet af ledige sider falder til under bestemte interne tærskler. Kernen tvinges derefter til konstant at arbejde på at frigøre hukommelse: rydde cacher, skrive snavsede sider til disken, fjerne sjældent brugte sider og så videre.

Højt hukommelsestryk kan give meget tydelige symptomer: høj latenstid i webtjenester , langsomme grafiske grænseflader, forsinkede svar fra fjernsessioner (SSH, VNC, RDP), hakkende mus, vinduer der tager sekunder om at reagere osv. På det tidspunkt er systemet mere fokuseret på at overleve end på at udføre nyttigt arbejde.

Thrashing opstår , når RAM ikke er tilstrækkelig til at indeholde de sider, som processer konstant bruger. Kernen begynder at bytte sider kontinuerligt: ​​den fjerner én for at indsætte en anden, men har derefter straks brug for den, den lige har fjernet. Resultatet er en cyklus af sidefejl og diskadgang, der forringer ydeevnen.

Med swap aktiveret betyder thrashing, at anonyme sider flytter frem og tilbage mellem RAM og swap-pladsen, hvilket mætter disken. Uden swap skifter problemet til filsider: de kasseres og genindlæses gentagne gange fra filsystemet, hvilket også kan gøre maskinen praktisk talt ubrugelig.

Hvis kernen stadig ikke kan finde ledig hukommelse, kommer følgende i spil: Mekanisme for manglende hukommelse (OOM)Når alt, hvad der kan droppes, komprimeres eller byttes, er opbrugt, beregner kernen en score for hver proces (oom_scoreog beslutter, hvilken der skal ofres. Den proces fuldføres af OOM-morder for at frigøre en betydelig mængde RAM og undgå et totalt nedbrud.

Byt: hvad det er, hvor meget skal man lægge i, og hvorfor det ikke er "djævlen"

Swap-hukommelse har et dårligt ry, delvist på grund af forældede råd og overforenklinger som "hvis du har meget RAM, behøver du ikke swap." I virkeligheden er swap-plads en nøglekomponent i Linux-hukommelsesdesign, selv på systemer med masser af RAM.

Swap er et område på disken (partition eller fil), som kernen bruger til at gemme inaktive hukommelsessider . Dette gør det muligt at frigøre RAM til processer, der rent faktisk har brug for det. Det er ikke virtuel hukommelse i sig selv, men en af ​​de mekanismer, der gør det muligt.

Uden swap har anonyme sider ingen steder at gå hen, når hukommelsestrykket stiger. Kernen kan stadig være afhængig af cacher og filbaserede sider, men så snart anonym hukommelse bliver kritisk høj, er den praktisk talt tvunget til at aktivere OOM-killeren meget hurtigere. Teknisk set kan Linux fungere uden swap, men i praksis er det en unødvendig risiko i de fleste scenarier.

Når det kommer til dimensionering af swap-pladsen, er der ingen enkelt opskrift, men der er nogle ret rimelige moderne kriterier afhængigt af maskinens rolle:

• Servere uden dvaletilstand4-8 GB swap-plads er normalt tilstrækkelig som buffer, selv med masser af RAM. For hukommelsesintensive tjenester (databaser, virtualisering) kan du øge den til 1,5 gange RAM'en, men prioriteten bør være at øge den fysiske RAM.
• Stationære computere uden dvaletilstandMed 16 GB eller mere RAM er 2-4 GB swap mere end nok som et sikkerhedsnet.
• Dvaletilstandsaktiverede enhederSwap-pladsen skal være lig med eller lidt større end RAM'en, fordi systemet gemmer alt indholdet af hukommelsen i den, når det går i dvaletilstand.

Det er meget fleksibelt at oprette et swap-område. Du kan bruge en dedikeret partition eller en swap-fil . En swap-fil er ideel, når din disk allerede er partitioneret, eller du vil justere størrelsen uden at skulle omkonfigurere hele systemet.

Hukommelsesmålinger: free, vmstat, ps, RSS, PSS og mere

Klassiske Linux-hukommelsesstyringsværktøjer kan føre til misfortolkninger, hvis du ikke ved, hvad hver kolonne betyder. Kommandoen free -h Det er den enkleste måde at se et hurtigt overblik over den samlede hukommelse, brugt hukommelse, ledig hukommelse, cache og swap.

Ved udgangen af free Det er vigtigt at se på den linje, der fratrækker buffere og cache, fordi den kolonne angiver hukommelse, der faktisk er optaget af processer, uden at medregne hvad kernen bruger som cache, og som den hurtigt kan frigive, hvis det er nødvendigt.

med vmstat -s -S M Du får en mere detaljeret oversigt: samlet hukommelse, brugt hukommelse, ledig hukommelse, aktiv hukommelse, inaktiv hukommelse, swap-cache osv. Du kan også se /proc/meminfo for at se hver metrik i detaljer, selvom outputtet er mere tørt og mindre brugervenligt.

For at finde ud af hvilke processer der påvirker RAM mest, ps aux viser kolonner som VSZ (total virtuel hukommelse, som processen kunne bruge, hvis den indlæste alt) og RSS (Resident Set Size, den faktiske hukommelse, der aktuelt er i RAM). Bemærk: RSS inkluderer også delt bibliotekshukommelse, som tælles flere gange, hvis den bruges af flere processer.

Her kommer i spil PSS (Proportionel sætstørrelse)som fordeler omkostningerne ved delte biblioteker mellem de processer, der bruger dem. For nemt at få fat i PSS findes der værktøjer som f.eks. smem, meget nyttigt til at se, hvilke applikationer der virkelig er "datasvin" uden at forvrænge dataene på grund af delte biblioteker.

Hukommelsesfragmentering, stak, heap og ulimit

Et andet mindre synligt aspekt af hukommelsesstyring er fragmentering . Vi kan tale om intern fragmentering (når afrundede blokke allokeres i multipla af 4, 8 eller 16 bytes, hvilket efterlader et ubrugeligt stykke) og ekstern fragmentering (når der er ledig hukommelse, men den er opdelt i små stykker, der forhindrer brugen af ​​en stor sammenhængende allokering).

I applikationer som Redis vil du nogle gange se forskelle mellem den hukommelse, der rapporteres af systemet (RSS), og den hukommelse, som appen selv anser for nyttig (used_memory). Denne afstand skyldes normalt i høj grad ekstern fragmentering, huller som systemet tæller som optaget, men som processen faktisk ikke bruger.

En process hukommelse er konceptuelt opdelt i stak og heapStakken bruges til lokale variabler og funktionskald, mens heapen bruges til dynamiske allokeringer. malloc() og lignende. Når datastrukturer vokser ud over, hvad stakken kan indeholde, trækkes de fra heapen og håndteres ved hjælp af pointere.

Den maksimale stakstørrelse pr. proces kan justeres med ulimit -a og systemkonfigurationer. At reducere den begrænser antallet af store lokale variabler, mens at øge den muliggør flere variabler eller dyb rekursion. Justering af denne parameter kan hjælpe med bedre at kontrollere hukommelsesforbruget og reducere visse typer fragmentering, selvom det ikke er en universalløsning.

Avanceret overvågning og diagnosticering: top, htop, vmstat, sar og mere

For at finde processer, der bruger RAM, kan du starte med top Og hvis du ønsker noget mere brugervenligt, f.eks. htopSidstnævnte viser CPU-, hukommelses- og swap-forbrugsbjælker og giver mulighed for interaktiv sortering og filtrering af processer.

I Debian og derivater, installer htop med sudo apt install htopI AlmaLinux og andre Red Hat-lignende systemer, med sudo dnf install htopNår du er inde, kan du sortere efter hukommelse, søge efter specifikke processer og afslutte problematiske opgaver direkte fra brugerfladen.

For dybere analyse og batchtilstand, vmstat 5 Den giver regelmæssige oplysninger om processer, hukommelse, paging, blok-I/O, afbrydelser og CPU-planlægning. Den er ideel til at se, hvordan hukommelsesbelastningen udvikler sig over tid.

Fortsættelsen sysstat Den inkorporerer værktøjer som f.eks. sarsom giver dig mulighed for at registrere og analysere brugen af ​​hukommelse og andre ressourcer. For eksempel, sar -r 1 5 Den viser hukommelses- og swap-forbrug hvert sekund, fem gange. På Debian installeres den med sudo apt install sysstatog i AlmaLinux med sudo dnf install sysstat.

Hvis du har brug for dyb debugging på kernelniveau, bpftrace Det er et kraftfuldt værktøj baseret på eBPF. Det giver dig mulighed for at instrumentere systemkald, observere hukommelsesadgang og detektere flaskehalse uden at skulle rekompilere eller genstarte. Det installeres typisk med sudo apt install bpftrace på Debian-lignende systemer.

Praktisk hukommelsesstyring: swap, swappiness og cache-rensning

En grundlæggende opgave på mange servere er at kontrollere den nuværende status for byttet. Med swapon --show Du har en liste over aktive swap-enheder og filer, deres størrelse, type og prioritet. Hvis du har brug for at tilføje swap på farten, kan du oprette en fil med fallocate, sikre tilladelser med chmod 600formatér den med mkswap og aktiver den med swaponFor at gøre den permanent skal du blot tilføje den tilsvarende post til /etc/fstab.

Parameter vm.swappiness Dette styrer, hvor hurtigt kernen prioriterer at bruge swap frem for at fortsætte med at fylde RAM. Det går fra 0 til 100. Lave værdier (10-20) får systemet til at undgå swap, indtil det er absolut nødvendigt, mens høje værdier (60 eller mere) opfordrer systemet til at flytte sider til swap hurtigere for at opretholde ledig RAM.

På servere med langsomme diske eller store databaser er det ofte interessant sænk bytteforholdetFor eksempel til 10 eller 20, med sudo sysctl vm.swappiness=10For stationære computere med hurtig zram eller SSD'er kan mellemværdier som 30-60 give en god balance mellem latenstid og hukommelsesudnyttelse.

I situationer med god hukommelse er det nogle gange nødvendigt at fremtvinge cache-frigivelse med sudo sync && sudo sysctl -w vm.drop_caches=3Dette tømmer en stor del af sidens cache og hukommelse. Det er nyttigt lejlighedsvis til test eller frigørelse af hukommelse på meget begrænsede systemer, men det bør ikke bruges rutinemæssigt, da du også mister den forbedring af ydeevnen, som caching giver.

Avancerede kontrolværktøjer: cgroup v2, memory.pressure og OOM i brugerområdet

I moderne systemer, der bruger systemd og cgroup v2 , kan hukommelsesstyring finjusteres af procesgrupper. cgroup v2 organiserer opgaver i hierarkier og anvender ressourcegrænser og prioriteter (CPU, hukommelse, I/O) på gruppeniveau, ikke kun på det individuelle procesniveau.

Inden for hukommelseshierarkiet er parametre som f.eks. memory.low De giver dig mulighed for at angive, at hukommelsen for visse c-grupper bør beskyttes bedre mod globalt pres, mens andre kan være mere udtømmelige, hvis RAM skal frigøres.

Filen memory.pressure Den afslører meget nyttige målinger: hvor længe opgaver i den pågældende c-gruppe har været blokeret på grund af manglende hukommelse, i intervaller på 10, 60 og 300 sekunder. Varianten nogle Det angiver, om mindst én opgave er blevet forsinket, og fuld Det afspejler øjeblikke, hvor alle gruppens opgaver blev påvirket samtidigt.

Ud over kernens OOM-killer er der dukket brugerpladsløsninger op, såsom tidlig morgen, ingen hænge o systemd-oomdEarlyOOM overvåger RAM og swap, og når de falder under bestemte tærskler, afslutter den proaktivt processer. oom_score højere, hvilket genopretter brugervenligheden, før maskinen fryser.

NoHang går et skridt videre: det understøtter flere udvælgelseskriterier , kan tage højde for hukommelsestryk og integrerer godt med avancerede konfigurationer, selvom dets udvikling har haft sine op- og nedture. I mellemtiden integrerer systemd-oomd direkte med systemd og cgroup v2 og er i øjeblikket den foretrukne mulighed i mange distributioner til at håndtere situationer med lav hukommelse mere intelligent og detaljeret.

Modern Swap: zram, zswap og enhedsprioriteter

Udover "klassisk" diskbytte tilbyder Linux moderne mekanismer, der forbedrer ydeevnen betydeligt ved at kombinere RAM-komprimering og selektiv diskbrug.

zram er et kernemodul, der opretter blokenheder i selve RAM'en, hvor sider gemmes i komprimeret tilstand. Disse bruges typisk som ultrahurtige swap-enheder: komprimering og dekomprimering bruger noget CPU, men du får logisk hukommelseskapacitet og reducerer diskforbruget drastisk.

I mange distributioner er det nok at installere zram-værktøjer o zram-generator og aktivere dens tjeneste. For eksempel kan du i Debian bruge sudo apt install zram-tools og aktivere zramswap med systemd. I AlmaLinux, med sudo dnf install zram-generator og den tilhørende tjeneste.

zswap fungerer derimod som en komprimeret cache foran disk-swap'en . Den forsøger først at gemme de byttede sider i komprimeret RAM; først når denne cache er fuld, eller sider bliver inaktive, skriver den til det faktiske swap-område. Dette reducerer disk-I/O og forlænger levetiden for SSD'er, på bekostning af noget CPU-forbrug.

Når man kombinerer flere swap-enheder (f.eks. zram og en diskfil), er det vigtigt at justere prioriteter. Med swapon -p eller muligheden pri= en /etc/fstab Du angiver, hvilken enhed der skal bruges først. Den sædvanlige praksis er at give høj prioritet (for eksempel 100) til zram og lavere prioritet (10) til disk swap, så kernen udnytter den komprimerede swap-plads i RAM fuldt ud, før den tilgår disken.

Hukommelsesstyring anvendt på servere: swap, tjenester og sikkerhed

I webservere (Apache, Nginx), databaser (MySQL, MariaDB, MongoDB) eller ressourcekrævende applikationer er hukommelse den kritiske ressource. RAM og swap-konfiguration bestemmer direkte, hvor mange samtidige anmodninger du kan håndtere, før systemet begynder at have problemer.

I tilfælde af databasemotorer som MongoDB er det afgørende, at den fysiske RAM overstiger databasens krav ; ellers vil den begynde at bruge swap-plads, og ydeevnen vil falde drastisk på grund af den betydelige forskel mellem RAM-adgang og diskadgang. Det samme gælder for MySQL/MariaDB, hvor værktøjer som MySQLTuner anbefaler hukommelsesparametre baseret på tilgængelig RAM.

For at undgå at spilde hukommelse anbefales det at stoppe ubrugte tjenester og rydde op i containere, billeder og Docker-volumener, der ikke længere er nødvendige. I udviklings- og QA-miljøer er det meget nemt at akkumulere glemte ressourcer, der stjæler gigabyte RAM og diskplads, uden at nogen bemærker det.

Sikkerhed spiller også en rolle: unødvendige porte åbne De øger angrebsfladen. Malware, der formår at infiltrere et system, kan for eksempel starte miningprocesser, der bruger CPU og hukommelse, planlægge opgaver i crontab og få systemet til at gå ned. Kontrol af indgående og udgående porte, lukning af alt, der ikke er essentielt, og oprydning af mistænkelige cron-job er en del af den grundlæggende systemhygiejne, der også beskytter hukommelsesressourcer.

Hukommelse og filsystemer: ext4, XFS, Btrfs og journalføring

Selvom det kan virke som et separat problem, påvirker valget af filsystem og dets konfiguration også hukommelsesadfærd og I/O-belastning. Ext4 bruger for eksempel en journal, som, afhængigt af belastningen, kan lægge ekstra pres på disken og dermed på cachestyringen.

I krævende servermiljøer vælger mange administratorer XFS eller endda Btrfs . XFS fungerer typisk rigtig godt med store filer og højtydende systemer. Btrfs tilbyder avancerede funktioner såsom snapshots, transparent komprimering og undervolumener, på bekostning af en vis kompleksitet og, afhængigt af version og distribution, et modenhedsniveau, der stadig debatteres for alle arbejdsbelastninger.

Kernen tilpasser sin caching- og write-off-politik til filsystemets egenskaber, så skift fra ext4 til XFS eller Btrfs påvirker ikke kun rå I/O, men også hvordan RAM og sidecache bruges til at buffere læse- og skriveoperationer.

Vigtige grafiske værktøjer og hjælpeprogrammer til administratorer

Selvom terminalen stadig er enhver administrators schweizerkniv, findes der værktøjer, der gør det meget nemmere at administrere hukommelse og ressourcer . Et af dem er Glances , en realtidsskærm, der viser CPU, hukommelse, disk, netværk og processer på en enkelt skærm med en valgfri webgrænseflade til overvågning af flere servere fra en browser.

For hurtig installation på Debian, skal du blot... sudo apt install glancesGlances komplementerer rigtig godt med htop, vmstat y sar, hvilket giver et mere visuelt overblik over, hvordan systemet opfører sig under belastning.

Inden for grafisk serveradministration tilbyder Cockpit en brugervenlig webgrænseflade til overvågning af hukommelse, processer og tjenester . Det giver dig mulighed for at administrere flere servere fra en enkelt konsol, starte og stoppe systemd-enheder, overvåge swap- og zram-brug og gennemgå logs uden at forlade din browser.

På desktop-systemer integrerer mange distributioner deres egen ressourceovervågning, men i miljøer uden en GUI, eller hvor du ønsker noget let, giver kombinationen af ​​disse konsolværktøjer med brugerdefinerede scripts dig et fremragende overblik over, hvad der sker med hukommelsen på et givet tidspunkt.

Korrekt hukommelsesstyring i Linux involverer forståelse af, hvordan kernen bruger RAM, rollerne for swap, zram og zswap, hvordan cgroup v2 og de forskellige OOM'er reagerer på pres, og hvilke værktøjer du har til at overvåge og finjustere systemet. Når du sætter alle disse dele sammen - fra free, vmstat, PSS og memory.pressure til zram, swappiness og systemd-oomd - holder du op med at kæmpe med "Linux, der forbruger RAM", og begynder at have et finjusteret, stabilt system, der er i stand til at maksimere hardwareydelsen i enhver rolle: server, desktop eller miljø med høj belastning.