Hvad er vm.min_free_kbytes, og hvordan indstilles det?

Sådan fungerer vm.min_free_kbytes

Hukommelsesallokeringer kan være nødvendige af systemet for at sikre korrekt funktion af selve systemet. Hvis kernen tillader, at al hukommelse tildeles, kan det være svært, når der er brug for hukommelse til regelmæssige operationer, for at OS kan fungere gnidningsløst. Derfor giver kernen den afstemmbare vm.min_free_kbytes. Den tunable vil tvinge kernens hukommelsesadministrator til at beholde mindst X mængde ledig hukommelse. Her er den officielle definition fra linux kernel dokumentation : Dette bruges til at tvinge Linux VM til at holde et minimum antal kilobytes gratis. VM'en bruger dette nummer til at beregne en vandmærke [WMARK_MIN] værdi for hver lavmem -zone i systemet. Hver lowmem -zone får et antal reserverede gratis sider baseret proportionelt på dens størrelse. En minimal mængde hukommelse er nødvendig for at tilfredsstille PF_MEMALLOC -allokeringer; hvis du indstiller dette til lavere end 1024KB, bliver dit system subtilt brudt og tilbøjeligt til at gå i stå under store belastninger. Hvis du indstiller dette for højt, OOM din maskine øjeblikkeligt.

Validering af vm.min_free_kbytes Works

For at teste, at indstillingen af ​​min_free_kbytes fungerer som designet, har jeg oprettet en virtuel linux -forekomst med kun 3,75 GB RAM. Brug den gratis kommando herunder til at analysere systemet:

Ser man på det gratis hukommelsesværktøj ovenfor ved hjælp af -m -flag for at få værdierne udskrevet i MB. Den samlede hukommelse er 3,5 til 3,75 GB hukommelse. 121 MB hukommelse bruges, 3,3 GB hukommelse er ledig, 251 MB bruges af buffercachen. Og 3,3 GB hukommelse er tilgængelig.

Nu skal vi ændre værdien af ​​vm.min_free_kbytes og se, hvad indvirkningen er på systemhukommelsen. Vi vil ekko den nye værdi til det virtuelle proc -filsystem for at ændre kerneparameterværdien som følger:

Du kan se, at parameteren blev ændret til cirka 1,5 GB og har trådt i kraft. Lad os nu bruge gratis kommando igen for at se eventuelle ændringer, der genkendes af systemet.

Den ledige hukommelse og buffercachen ændres ikke af kommandoen, men mængden af ​​hukommelse vises som ledig er reduceret fra 3327 til 1222 MB. Hvilket er en omtrentlig reduktion af ændringen i parameteren til 1,5 GB min ledig hukommelse.

Lad os nu oprette en 2 GB datafil og derefter se, hvad læsning af filen i buffercachen gør med værdierne. Sådan oprettes en 2 GB datafil i 2 linjer med bash script nedenfor. Scriptet vil generere en tilfældig fil på 35 MB ved hjælp af kommandoen dd og derefter kopiere den 70 gange til en ny data_fil produktion:

Lad os læse filen og ignorere indholdet ved at læse og omdirigere filen til /dev /null som vist nedenfor:

Okay, hvad der er sket med vores systemhukommelse med dette sæt manøvrer, lad os kontrollere det nu:

Analyse af resultaterne ovenfor. Vi har stadig 1,8 GB ledig hukommelse, så kernen har beskyttet en stor del af hukommelsen som reserveret på grund af vores min_free_kbytes -indstilling. Buffercachen har brugt 1691 MB, hvilket er mindre end den samlede størrelse på vores datafil, som er 2,3 GB. Tilsyneladende det hele data_fil kunne ikke gemmes i cachen på grund af mangel på tilgængelig hukommelse til buffercachen. Vi kan validere, at hele filen ikke er gemt i cachen, men tidsmæssigt gentagne forsøg på at læse filen. Hvis den blev gemt i cachen, ville det tage en brøkdel af et sekund at læse filen. Lad os prøve det.

Filen læste tog næsten 20 sekunder, hvilket betyder, at det næsten ikke er alt cachelagret.

Som en sidste validering lad os reducere vm.min_free_kbytes for at give sidens cache mere plads til at fungere, og vi kan forvente at se cachen fungere og filen læses meget hurtigere.

Med den ekstra hukommelse til rådighed til cachelagring faldt filtiden fra 20 sekunder før til .364 sekunder med det hele i cachen.

Jeg er nysgerrig efter at lave et andet eksperiment. Hvad sker der med malloc -opkald for at allokere hukommelse fra et C -program i lyset af denne virkelig høje vm.min_free_kbytes -indstilling. Vil det svigte malloc? Vil systemet dø? Nulstil først indstillingen vm.min_free_kbytes til den virkelig høje værdi for at genoptage vores eksperimenter:

Lad os se på vores ledige hukommelse igen:

Teoretisk set har vi 1,9 GB gratis og 515 MB til rådighed. Lad os bruge et stresstestprogram kaldet stress-ng for at bruge noget hukommelse og se, hvor vi fejler. Vi vil bruge vm -testeren og prøve at allokere 1 GB hukommelse. Da vi kun har reserveret 1,5 GB på et 3,75 GB system, gætter jeg på, at dette burde fungere.

Lad os prøve det igen med flere arbejdere, vi kan prøve 1, 2, 3, 4 arbejdere, og på et tidspunkt skulle det mislykkes. I min test bestod den med 1 og 2 arbejdere, men mislykkedes med 3 arbejdere.

Lad os nulstille vm.min_free_kbytes til et lavt tal og se om det hjælper os med at køre 3 hukommelsesstressorer med 1 GB hver på et 3,75 GB system.

Denne gang kørte det uden fejl, jeg prøvede det to gange uden problemer. Så jeg kan konkludere, at der er en adfærdsforskel ved at have mere hukommelse til rådighed for malloc, når værdien vm.min_free_kbytes er indstillet til en lavere værdi.

Standardindstilling for vm.min_free_kbytes

Standardværdien for indstillingen på mit system er 67584, hvilket er cirka 1,8% af RAM på systemet eller 64 MB. Af sikkerhedsmæssige årsager på et stærkt nedslidt system ville jeg have en tendens til at øge det lidt til 128MB for at give mulighed for mere reserveret ledig hukommelse, men for gennemsnitlig brug synes standardværdien fornuftig nok. Den officielle dokumentation advarer om at gøre værdien for høj. Indstilling af den til 5 eller 10% af system -RAM er sandsynligvis ikke den tilsigtede brug af indstillingen og er for høj.

Indstilling af vm.min_free_kbytes for at overleve genstart

For at sikre, at indstillingen kan overleve genstart og ikke gendannes til standardværdierne ved genstart, skal du sørge for, at sysctl -indstillingen vedvarer ved at sætte den ønskede nye værdi i filen /etc/sysctl.conf.

Konklusion

Vi har set, at vm.min_free_kbytes linux kernel tunel kan ændres og kan reservere hukommelse på systemet for at sikre, at systemet er mere stabilt, især under kraftig brug og tunge hukommelsestildelinger. Standardindstillingerne kan være lidt for lave, især på systemer med høj hukommelse og bør betragtes som øget omhyggeligt. Vi har set, at den hukommelse, der er reserveret af denne tunable, forhindrer OS -cachen i at bruge al hukommelse og forhindrer også, at nogle malloc -operationer også bruger al hukommelsen.