Hva er vm.min_free_kbytes og hvordan stiller du det inn?

Hvordan vm.min_free_kbytes fungerer

Minnetildelinger kan være nødvendig av systemet for å sikre at systemet fungerer som det skal. Hvis kjernen tillater all minne å bli allokert, kan det slite med behov for minne for regelmessige operasjoner for å holde operativsystemet jevnt. Det er derfor kjernen gir den avstembare vm.min_free_kbytes. Den avstembare tvinger kjernens minnebehandler til å beholde minst X mengde ledig minne. Her er den offisielle definisjonen fra linux kjernedokumentasjon : Dette brukes til å tvinge Linux VM til å holde et minimum antall kilobyte gratis. VM bruker dette nummeret til å beregne en vannmerke [WMARK_MIN] verdi for hver lavmemsone i systemet. Hver lowmem -sone får et antall reserverte gratis sider som er proporsjonalt basert på størrelsen. Noen minimale mengder minne er nødvendig for å tilfredsstille PF_MEMALLOC -tildelinger; Hvis du setter dette til lavere enn 1024KB, blir systemet ditt subtilt ødelagt og utsatt for fastlåst under høy belastning. Hvis du setter dette for høyt, OOM maskinen din umiddelbart.

Validerer vm.min_free_kbytes Works

For å teste at innstillingen av min_free_kbytes fungerer som designet, har jeg laget en virtuell linux -forekomst med bare 3,75 GB RAM. Bruk gratiskommandoen nedenfor for å analysere systemet:

Ser på gratis minneverktøyet ovenfor ved å bruke -m -flagget for å få verdiene skrevet ut i MB. Det totale minnet er 3,5 til 3,75 GB minne. 121 MB minne brukes, 3,3 GB minne er ledig, 251 MB brukes av bufferen. Og 3,3 GB minne er tilgjengelig.

Nå skal vi endre verdien av vm.min_free_kbytes og se hvilken innvirkning det har på systemminnet. Vi vil ekko den nye verdien til det virtuelle proc -filsystemet for å endre kjerneparameterverdien som beskrevet nedenfor:

Du kan se at parameteren ble endret til omtrent 1,5 GB og har trådt i kraft. La oss nå bruke gratis kommandoen igjen for å se eventuelle endringer som gjenkjennes av systemet.

Det ledige minnet og bufferbufferen er uendret av kommandoen, men mengden minne som vises som tilgjengelig er redusert fra 3327 til 1222 MB. Noe som er en omtrentlig reduksjon av endringen i parameteren til 1,5 GB min ledig minne.

La oss nå lage en 2 GB datafil og se hva som leser den filen i bufferen, gjør med verdiene. Slik lager du en 2 GB datafil i 2 linjer med bash -skript nedenfor. Skriptet vil generere en 35 MB tilfeldig fil ved hjelp av dd -kommandoen og deretter kopiere den 70 ganger til en ny data fil produksjon:

La oss lese filen og ignorere innholdet ved å lese og omdirigere filen til /dev /null i henhold til nedenfor:

Ok, hva har skjedd med systemminnet vårt med dette settet med manøvrer, la oss sjekke det nå:

Analyserer resultatene ovenfor. Vi har fortsatt 1,8 GB ledig minne, så kjernen har beskyttet en stor del av minnet som reservert på grunn av innstillingen min_free_kbytes. Bufferbufferen har brukt 1691 MB, som er mindre enn den totale størrelsen på datafilen vår som er 2,3 GB. Tilsynelatende hele data fil kunne ikke lagres i hurtigbufferen på grunn av mangel på tilgjengelig minne til bufferen. Vi kan bekrefte at hele filen ikke er lagret i hurtigbufferen, men tidsbestemte gjentatte forsøk på å lese filen. Hvis den ble bufret, ville det ta en brøkdel av et sekund å lese filen. La oss prøve det.

Fillesningen tok nesten 20 sekunder, noe som betyr at den nesten ikke er bufret.

Som en siste validering, la oss redusere vm.min_free_kbytes for å la sidebufferen få mer plass til å betjene, og vi kan forvente at hurtigbufferen fungerer og filen blir lest mye raskere.

Med det ekstra minnet som er tilgjengelig for hurtigbufring, falt lesetiden fra 20 sekunder før til .364 sekunder med alt i hurtigbufferen.

Jeg er nysgjerrig på å gjøre et nytt eksperiment. Hva skjer med malloc -anrop for å tildele minne fra et C -program i møte med denne virkelig høye vm.min_free_kbytes -innstillingen. Vil det mislykkes malloc? Vil systemet dø? Tilbakestill først innstillingen vm.min_free_kbytes til den virkelig høye verdien for å gjenoppta eksperimentene våre:

La oss se på vårt ledige minne igjen:

Teoretisk sett har vi 1,9 GB ledig og 515 MB tilgjengelig. La oss bruke et stresstestprogram som kalles stress-ng for å bruke litt minne og se hvor vi feiler. Vi vil bruke vm -testeren og prøve å tildele 1 GB minne. Siden vi bare har reservert 1,5 GB på et 3,75 GB system, antar jeg at dette burde fungere.

La oss prøve det igjen med flere arbeidere, vi kan prøve 1, 2, 3, 4 arbeidere, og på et tidspunkt burde det mislykkes. I testen min besto den med 1 og 2 arbeidere, men mislyktes med 3 arbeidere.

La oss tilbakestille vm.min_free_kbytes til et lavt tall og se om det hjelper oss å kjøre 3 minnestressorer med 1 GB hver på et 3,75 GB system.

Denne gangen kjørte den uten hell, jeg prøvde den to ganger uten problemer. Så jeg kan konkludere med at det er en atferdsforskjell i å ha mer minne tilgjengelig for malloc, når vm.min_free_kbytes -verdien er satt til en lavere verdi.

Standardinnstilling for vm.min_free_kbytes

Standardverdien for innstillingen på systemet mitt er 67584, som er omtrent 1,8% av RAM på systemet eller 64 MB. Av sikkerhetsmessige årsaker på et sterkt ødelagt system vil jeg ha en tendens til å øke det litt til 128 MB for å gi mer reservert ledig minne, men for gjennomsnittlig bruk virker standardverdien fornuftig nok. Den offisielle dokumentasjonen advarer om å gjøre verdien for høy. Å sette den til 5 eller 10% av system -RAM er sannsynligvis ikke den tiltenkte bruken av innstillingen, og er for høy.

Angir vm.min_free_kbytes for å overleve omstart

For å sikre at innstillingen kan overleve omstart og ikke blir gjenopprettet til standardverdiene ved omstart, må du sørge for at sysctl -innstillingen vedvarer ved å sette ønsket ny verdi i filen /etc/sysctl.conf.

Konklusjon

Vi har sett at vm.min_free_kbytes linux -kjernestilleren kan endres og kan reservere minne på systemet for å sikre at systemet er mer stabilt, spesielt under mye bruk og tunge minnetildelinger. Standardinnstillingene kan være litt for lave, spesielt på systemer med høyt minne, og bør vurderes å økes nøye. Vi har sett at minnet som er reservert av denne tunable forhindrer OS -hurtigbufferen i å bruke alt minnet og forhindrer også at noen malloc -operasjoner kan bruke alt minnet.