Hva er VM.min_free_kbytes og hvordan du kan stille det inn?

Hva er VM.min_free_kbytes og hvordan du kan stille det inn?
Hva er VM.min_free_kbytes sysctl avstemt for Linux -kjernen og hvilken verdi skal den settes til? Vi vil studere denne parameteren og hvordan den påvirker et løpende Linux -system i denne artikkelen. Vi vil teste dens innvirkning på OS Page Cache og på Mallocs og hva systemets gratis kommando viser når denne parameteren er angitt. Vi vil lage noen utdannede gjetninger om ideelle verdier for denne avstemelige, og vi vil vise hvordan vi kan angi VM.min_free_kbytes permanent for å overleve omstarter. Så la oss gå.

Hvordan VM.min_free_kbytes fungerer

Minnetildelinger kan være nødvendig av systemet for å sikre riktig funksjon av systemet i seg selv. Hvis kjernen lar alt minnet fordeles, kan det slite når du trenger minne for regelmessige operasjoner for å holde OS i gang jevnt. Det er grunnen til at kjernen gir den avstembare VM.min_free_kbytes. Tunable vil tvinge kjerneshjertelsessjefen til å beholde minst x mengde fritt minne. Her er den offisielle definisjonen fra Linux Kernel -dokumentasjonen: “Dette brukes til å tvinge Linux VM til å holde et minimum antall kilobyter gratis. VM bruker dette nummeret for å beregne en vannmerke [wmark_min] -verdi for hver Lowmem -sone i systemet. Hver Lowmem -sone får et antall reserverte gratis sider basert proporsjonalt på størrelsen. Noe minimal mengde minne er nødvendig for å tilfredsstille pf_memalloc -tildelinger; Hvis du setter dette til lavere enn 1024KB, vil systemet ditt bli subtilt ødelagt og utsatt for deadlock under høye belastninger. Å sette dette for høyt vil maskinen din umiddelbart.“

Validering av VM.min_free_kbytes fungerer

For å teste at innstillingen til min_free_kbytes fungerer som designet, har jeg laget en virtuell Linux virtuell forekomst med bare 3.75 GB RAM. Bruk den gratis kommandoen nedenfor for å analysere systemet:

# gratis -m

Ser på det gratis minneverktøyet ovenfor ved hjelp av -m -flagget for å få verdiene trykt i MB. Det totale minnet er 3.5 til 3.75 GB av minne. 121 MB minne brukes, 3.3 GB minne er gratis, 251 MB brukes av bufferbufferen. Og 3.3 GB minne er tilgjengelig.

Nå skal vi endre verdien av VM.min_free_kbytes og se hva innvirkningen er på systemminnet. Vi vil gjenspeile den nye verdien til PROC Virtual Filsystem for å endre kjerneparameterverdien per nedenfor:

# ekko 1500000>/proc/sys/vm/min_free_kbytes
# SYSCTL VM.min_free_kbytes

Du kan se at parameteren ble endret til 1.5 GB omtrent og har trådt i kraft. La oss nå bruke gratis kommando igjen for å se endringer som er anerkjent av systemet.

# gratis -m

Det frie minnet og bufferbufferen er uendret av kommandoen, men mengden minne som vises som tilgjengelig er redusert fra 3327 til 1222 MB. Som er en omtrentlig reduksjon av endringen i parameteren til 1.5 GB min gratis minne.

La oss nå opprette en 2 GB datafil og deretter se hvilken lesing den filen i bufferbufferen 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 inn i en ny data fil produksjon:

# dd if =/dev/tilfeldig av =/root/d1.TXT Count = 1000000
# for jeg i 'seq 1 70'; gjør ekko $ i; katt /rot /d1.txt >> /root /data_file; Ferdig

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

# CAT Data_File> /dev /null

OK, det som har skjedd med systemminnet vårt med dette manøvrene, la oss sjekke det nå:

# gratis -m

Analysere resultatene ovenfor. Vi har fortsatt 1.8 GB med gratis minne slik at kjernen har beskyttet en stor del av minne som reservert på grunn av vår_free_kbytes -innstilling. 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 mangelen på tilgjengelig minne som skal brukes til bufferbufferen. Vi kan validere at hele filen ikke er lagret i hurtigbufferen, men tidspunktet for de gjentatte forsøkene på å lese filen. Hvis det ble hurtigbufret, ville det ta en brøkdel av et sekund å lese filen. La oss prøve det.

# TID CAT DATA_FILE> /DEV /NULL
# TID CAT DATA_FILE> /DEV /NULL

Filen leste tok nesten 20 sekunder, noe som innebærer at det nesten ikke er hurtigbufret.

Som en endelig validering, la oss redusere VM.min_free_kbytes for å la sidebufferen ha mer rom til å betjene, og vi kan forvente å se cachen fungere og filen leser blir mye raskere.

# ECHO 67584>/proc/sys/vm/min_free_kbytes
# TID CAT DATA_FILE> /DEV /NULL
# TID CAT DATA_FILE> /DEV /NULL

Med det ekstra minnet tilgjengelig for å hurtig .364 sekunder med det hele 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 innstilling. Vil det mislykkes Malloc? Vil systemet dø? Tilbakestill først VM.min_free_kbytes innstilling til den virkelig høye verdien for å gjenoppta eksperimentene våre:

# ekko 1500000>/proc/sys/vm/min_free_kbytes

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

Teoretisk sett har vi 1.9 GB gratis og 515 MB tilgjengelig. La oss bruke et stresstestprogram som heter Stress-ng for å bruke litt minne og se hvor vi mislykkes. Vi vil bruke VM -testeren og prøve å tildele 1 GB minne. Siden vi bare har reservert 1.5 GB på en 3.75 GB -system, antar jeg at dette skal fungere.

# Stress-ng --vm 1 --vm-Bytes 1G-Timeout 60s
Stress-ng: Info: [17537] Sending av Hogs: 1 VM
Stress-ng: Info: [17537] Cache Tildel: Standard Cache Størrelse: 46080K
Stress-ng: Info: [17537] Vellykket løp fullført i 60.09s (1 min, 0.09 sek)
# Stress-ng --vm 2 --vm-Bytes 1G-Timeout 60s
# Stress-ng --vm 3 --vm-Bytes 1G-Timeout 60s

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

La oss tilbakestille VM.min_free_kbytes til et lavt antall og se om det hjelper oss å kjøre 3 minnestressorer med 1 GB hver på en 3.75 GB system.

# ECHO 67584>/proc/sys/vm/min_free_kbytes
# Stress-ng --vm 3 --vm-Bytes 1G-Timeout 60s

Denne gangen kjørte det med suksess uten feil, jeg prøvde det to ganger uten problemer. Så jeg kan konkludere med at det er en atferdsforskjell av å 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 sikkerhetsgrunner på et sterkt kastet system vil jeg ha en tendens til å øke det litt til 128 MB for å gi mer reservert gratis 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.

Innstilling av VM.min_free_kbytes for å overleve omstarter

For å sikre at innstillingen kan overleve omstarter og ikke blir gjenopprettet til standardverdiene når du starter på nytt, må du huske å gjøre SYSCTL -innstillingen vedvarende ved å sette den ønskede nye verdien i /etc /sysctl.Conf -fil.

Konklusjon

Vi har sett at VM.min_free_kbytes Linux Kernel Tunable kan modifiseres og kan reservere minne på systemet for å sikre at systemet er mer stabilt, spesielt under tung bruk og tunge minnetildeling. Standardinnstillingene kan være litt for lave, spesielt på høye minnesystemer og bør anses å bli økt nøye. Vi har sett at minnet reservert av denne avstembare forhindrer OS -cachen i å bruke alt minnet og også forhindrer noen Malloc -operasjoner i å bruke alt minnet også.