Oversættelsen af artiklen er forberedt til studerende på kurset .
Tidligere har jeg forklaret, hvordan man tjekker og aktiverer brugen af Hugepages i Linux.
Denne artikel vil være nyttig kun, hvis du virkelig har et sted at bruge Hugepages. Jeg har mødt mange mennesker, der narres af udsigten til, at Hugepages magisk vil forbedre ydeevnen. Ikke desto mindre er hugepaging et komplekst emne, og ved forkert brug kan det faktisk nedsætte ydeevnen.
Del 1: tjekker om hugepages er aktiveret i Linux (original) )
Problemet:
Det er nødvendigt at kontrollere, om HugePages er aktiveret på dit system.
Løsning:
Det er ganske enkelt:
cat /sys/kernel/mm/transparent_hugepage/enabledDu vil få noget som dette:
always [madvise] neverDu vil se en liste over tilgængelige muligheder (always, madvise, never), hvor den aktuelt aktive mulighed vil være omsluttet af parenteser (som standard madvise).
madvise betyder, at transparent hugepages er kun aktiveret for hukommelsesområder, der specifikt anmoder om hugepages ved hjælp af .
always betyder, at transparent hugepages er altid aktiveret for alle processer. Det øger normalt ydeevnen, men hvis du har et brugsscenarie, hvor mange processer bruger en lille mængde hukommelse, kan den samlede hukommelsespres stige dramatisk.
never betyder, at transparent hugepages vil ikke blive aktiveret, selv ikke når der anmodes om det ved hjælp af madvise. For at lære mere, se Linux-kernen.
Hvordan man ændrer standardværdien
Mulighed 1: Ændre direkte sysfs (efter genstart vil parameteren vende tilbage til standardværdien):
echo always > /sys/kernel/mm/transparent_hugepage/enabled
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/enabledMulighed 2: Ændre systemets standardværdi ved at recompilere kernen med ændret konfiguration (denne mulighed anbefales kun, hvis du bruger en tilpasset kerne):
- For at sætte always som standard, brug:
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y # Kommenter CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y ud - For at sætte madvise som standard, brug:
CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y # Kommenter CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y ud
Del 2: Fordele og ulemper ved HugePages
Vi vil forsøge at forklare fordelene, ulemperne og mulige fejl ved brugen af Hugepages. Da teknologien er kompleks og detaljeret, vil artiklen sandsynligvis være svær at forstå for folk, der narres til at tro, at Hugepages er en mirakelkur, vil jeg ofre præcision for enkelhed. Det er værd at huske, at mange emner virkelig er komplekse og derfor ofte er meget forsimplet.
Bemærk, at vi taler om 64-bit x86-systemer, der kører på Linux, og at jeg antager, at systemet understøtter transparent hugepages (da det ikke er en mangel, hvis hugepages ikke bliver udskiftet), som det næsten altid gør i moderne Linux-miljøer.
I de følgende links vil jeg inkludere mere teknisk beskrivelse.
Virtuel hukommelse
Hvis du er C++-programmerer, ved du, at objekter i hukommelsen har specifikke adresser (pegerens værdier).
Men disse adresser afspejler ikke nødvendigvis de fysiske adresser i hukommelsen (adresser i RAM). De repræsenterer adresser i den virtuelle hukommelse. Processoren har en særlig enhed kaldet MMU (memory management unit), som hjælper kernen med at kortlægge virtuel hukommelse til fysiske placeringer.
Denne tilgang har mange fordele, men de mest væsentlige er:
- Ydeevne (af forskellige årsager);
- Isolering af programmer, hvilket betyder, at ingen programmer kan læse fra et andet programs hukommelse.
Hvad er sider?
Den virtuelle hukommelse er delt op i sider. Hver enkelt side peger på en bestemt fysisk hukommelse, den kan pege på et område i RAM eller en adresse, der er tildelt en fysisk enhed, såsom et grafikkort.
De fleste sider, du arbejder med, peger enten på RAM eller er udskiftet (swap), det vil sige, de er gemt på en hård disk eller SSD. Kernen styrer den fysiske placering af hver side. Hvis der forsøges at få adgang til en udskiftet side, stopper kernen den tråd, der forsøger at få adgang til hukommelsen, læser siden fra hårddisken/SSD'en ind i RAM og fortsætter derefter med udførelsen af tråden.
Denne proces er gennemsigtig for tråden, hvilket betyder, at den ikke nødvendigvis læser direkte fra hårddisken/SSD'en. Størrelsen på normale sider er 4096 byte. Størrelsen på Hugepages er 2 megabyte.
Associativt buffer (TLB)
Når et program tilgår en bestemt hukommelsesside, skal CPU'en vide, fra hvilken fysisk side data skal læses (det vil sige have et virtuelt adressekort).
I kernen findes der en datastruktur (sidetabel), som indeholder al information om de anvendte sider. Med denne datastruktur kan man kortlægge en virtuel adresse til en fysisk adresse.
Men tabelen over sider er ret kompleks og fungerer langsomt, så vi kan simpelthen ikke analysere hele dataskarakteren hver gang, en proces får adgang til hukommelsen.
Heldigvis har vores processor en TLB, som cacher kortlægningen af virtuelle og fysiske adresser. Det betyder, at selvom vi skal analysere siden tabellen ved den første adgang, kan alle efterfølgende henvisninger til siden håndteres i TLB, hvilket sikrer hurtig drift.
Da det er implementeret som en fysisk enhed (hvilket gør det hurtigt), er dens kapacitet begrænset. Derfor, hvis du ønsker at få adgang til flere sider, vil TLB ikke kunne gemme kortlægningen for alle disse, hvilket resulterer i, at din applikation vil køre meget langsommere.
Hugepages træder til undsætning
Så hvad kan vi gøre for at undgå TLB-overbelastning? (Vi antager, at applikationen stadig har brug for den samme mængde hukommelse).
Her kommer Hugepages ind i billedet. I stedet for 4096 byte, der kræver kun én post i TLB, kan én post i TLB nu referere til massive 2 megabyte. Lad os antage, at TLB har 512 poster, uden Hugepages kan vi kortlægge:
4096 b⋅512=2 MBMens vi med dem kan kortlægge:
2 MB⋅512=1 GBDet er derfor, Hugepages er fantastiske. De kan forbedre ydelsen uden betydelig indsats. Men der er betydelige forbehold.
Udskiftning af Hugepages
Kernen sporer automatisk brugshyppigheden af hver hukommelsesside. Hvis der ikke er nok fysisk hukommelse (RAM), vil kerne flytte mindre vigtige (sjældnere brugte) sider til harddisken for at frigøre noget RAM til mere vigtige sider.
Generelt gælder det samme for Hugepages. Dog kan kernen kun flytte hele sider og ikke individuelle byte.
Lad os antage, at vi har et program:
char* mymemory = malloc(2*1024*1024); // Lad os tage dette som én Hugepage!
// Fyld mymemory med nogle data
// Foretag mange andre ting,
// som vil resultere i udskiftning af mymemory-siden
// ...
// Anmod om adgang kun til den første byte
putchar(mymemory[0]); I dette tilfælde skal kernen hente (læse) hele 2 megabyte information fra harddisken/SSD, bare for at du kan læse et enkelt byte. Når det gælder normale sider, skal der kun læses 4096 byte fra harddisken/SSD.
Derfor, hvis hugepage bliver anvendt, vil læsningen ske hurtigere, kun hvis du har brug for at få adgang til hele siden. Det betyder, at hvis du forsøger at få adgang til tilfældige dele af hukommelsen og blot læser et par kilobyte, bør du bruge normale sider og ikke bekymre dig yderligere.
På den anden side, hvis du har brug for at få adgang til en stor del af hukommelsen sekventielt, vil hugepages forbedre din ydeevne. Dog skal du selv teste dette (og ikke kun på et hypotetisk software) og se, hvad der vil fungere hurtigere.
Allokering i hukommelse
Hvis du programmerer i C, ved du, at du kan anmode om så små (eller næsten så store) mængder hukommelse fra bunken via malloc(). Lad os sige, at du har brug for 30 byte hukommelse:
char* mymemory = malloc(30);Programmereren kan tænke, at du "anmoder" om 30 byte hukommelse fra operativsystemet og får en pointer til en bestemt virtuel hukommelse. Men i virkeligheden malloc () — er bare en C-funktion, der internt kalder funktionerne for at anmode om eller frigive hukommelse fra operativsystemet.
Men at anmode om mere og mere hukommelse for hver allokering er ineffektivt; det er sandsynligt, at et segment af hukommelsen allerede er blevet frigivet (free()), og vi kan genbruge det. malloc() implementerer ret komplekse algoritmer til genbrug af frigivet hukommelse.
For dig sker alt dette uset, så hvorfor skulle det bekymre dig? Jo, fordi kaldet free() ikke nødvendigvis betyder, at .
Der findes et fænomen kaldet fragmentering af hukommelse. I ekstreme tilfælde er der hukommelsessegmenter, hvor kun få byte bruges, mens alt imellem dem er blevet frigivet. (free()).
Vær opmærksom på, at hukommelsesfragementering er et ekstremt komplekst emne, og selv små ændringer i programmet kan have en stor indvirkning på det. I de fleste tilfælde forårsager programmer ikke betydelig hukommelsesfragementering, men du bør huske på, at hvis der er opstået problemer med fragementering i et bestemt område af hukommelsen, kan hugepages kun forværre situationen.
Selektiv brug af hugepages
Efter at have læst artiklen, har du identificeret, hvilke dele af dit program der kan drage fordel af brugen af hugepages, og hvilke der ikke kan. Så bør hugepages overhovedet aktiveres?
Heldigvis kan du bruge madvise(), for kun at aktivere hugepaging for de hukommelsesområder, hvor det vil være nyttigt.
For at starte, tjek at hugepages fungerer i madvise() mode, ved hjælp af i starten af artiklen.
Derefter skal du bruge madvise(), for at angive til kernen, hvor præcist hugepages skal bruges.
#include <sys/mman.h>
// Аллоцируйте большое количество памяти, которую будете использовать
size_t size = 256*1024*1024;
char* mymemory = malloc(size);
// Просто включите hugepages…
madvise(mymemory, size, MADV_HUGEPAGE);
// … и задайте следующее
madvise(mymemory, size, MADV_HUGEPAGE | MADV_SEQUENTIAL)Bemærk, at denne metode blot er anbefalinger til kernen om hukommelsesstyring. Det betyder ikke, at kernen automatisk vil bruge hugepages for den angivne hukommelse.
Se dokumentationen , for at lære mere om hukommelsesstyring og madvise(), emnet har en utrolig stejl læringskurve. Så hvis du faktisk vil forstå det godt, skal du forberede dig på at læse og teste i flere uger, før du forventer nogen positive resultater.
Hvad skal man læse?
Har du spørgsmål? Skriv i kommentarerne!
Kilde: habr.com
