Phenquestions
Hvordan vm.min_free_kbytes fungerer
Det kan være behov for minnetildeling av systemet for å sikre at systemet fungerer riktig. Hvis kjernen tillater at alt minne blir tildelt, kan det slite når det er behov for minne for regelmessige operasjoner for å holde operativsystemet i orden. Det er derfor kjernen gir den avstembare vm.min_free_kbytes. Den innstillbare enheten vil tvinge 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 ledig. VM bruker dette tallet til å beregne en vannmerke [WMARK_MIN] -verdi for hver lavmemnsone i systemet. Hver lowmem-sone får et antall reserverte gratis sider basert proporsjonalt på størrelsen. Noen minimale mengder minne er nødvendig for å tilfredsstille PF_MEMALLOC-tildelinger; Hvis du setter dette til lavere enn 1024 KB, vil systemet ditt bli subtilt ødelagt og utsatt for låsing under høye belastninger. Hvis du setter dette for høyt, vil maskinen OOM umiddelbart.“
Validerer vm.min_free_kbytes Fungerer
For å teste at innstillingen av min_free_kbytes fungerer som designet, har jeg opprettet en virtuell Linux-forekomst med bare 3.75 GB RAM. Bruk gratis kommandoen nedenfor for å analysere systemet:
# gratis -m
Ser på gratisminneverktøyet ovenfor ved hjelp av -m-flagget for å få verdiene skrevet ut i MB. Det totale minnet er 3.5 til 3.75 GB minne. Det brukes 121 MB minne, 3.3 GB minne er ledig, 251 MB brukes av bufferbufferen. Og 3.3 GB minne er tilgjengelig.
Nå skal vi endre verdien på 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 nedenfor:
# echo 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 kommandoen igjen for å se eventuelle endringer som systemet gjenkjenner.
# gratis -m
Ledig minne og buffercache er uendret av kommandoen, men mengden minne som vises tilgjengelig er redusert fra 3327 til 1222 MB. 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 deretter se hva det å lese den filen i bufferbufferen gjør med verdiene. Slik lager du en 2 GB datafil i to 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:
# dd if = / dev / random of = / root / d1.txt-antall = 1000000# for i 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 som nedenfor:
# cat data_file> / dev / nullOk, hva har skjedd med systemminnet vårt med dette settet med manøvrer, la oss sjekke det nå:
# gratis -m
Analysere resultatene ovenfor. Vi har fortsatt 1.8 GB ledig minne slik at kjernen har beskyttet en stor mengde minne som reservert på grunn av min_free_kbytes-innstillingen. 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 som kan brukes til bufferbufferen. Vi kan validere at hele filen ikke er lagret i hurtigbufferen, men tidsbestemte gjentatte forsøk på å lese filen. Hvis den ble bufret, ville det ta et brøkdel av et sekund å lese filen. La oss prøve det.
# time cat data_file> / dev / null# time cat data_file> / dev / null
Filen som ble lest, tok nesten 20 sekunder, noe som betyr at den nesten ikke er hurtigbufret.
Som en siste validering, la oss redusere vm.min_free_kbytes slik at sidebufferen får mer plass til å fungere, og vi kan forvente å se hurtigbufferen fungere og filen leses blir mye raskere.
# echo 67584> / proc / sys / vm / min_free_kbytes# time cat data_file> / dev / null
# time cat data_file> / dev / null
Med ekstra minne tilgjengelig for hurtigbufring falt filens lesetid fra 20 sekunder før til .364 sekunder med alt i hurtigbuffer.
Jeg er nysgjerrig på å gjøre et nytt eksperiment. Hva skjer med malloc-samtaler 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 virkelig høy verdi for å gjenoppta eksperimentene våre:
# echo 1500000> / proc / sys / vm / min_free_kbytesLa oss se igjen på vårt ledige minne:
Teoretisk har vi 1.9 GB gratis og 515 MB tilgjengelig. La oss bruke et stresstestprogram kalt 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å en 3.75 GB system, jeg antar at dette skal fungere.
# stress-ng --vm 1 --vm-bytes 1G - timeout 60sstress-ng: info: [17537] utsendelse av svin: 1 vm
stress-ng: info: [17537] cache allocate: standard cache size: 46080K
stress-ng: info: [17537] vellykket løp fullført i 60.09s (1 min, 0.09 sekunder)
# 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 burde det mislykkes. I testen min gikk den med 1 og 2 arbeidere, men mislyktes med 3 arbeidere.
La oss nullstille vm.min_free_kbytes til et lavt tall 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 den vellykket uten feil, jeg prøvde det to ganger uten problemer. Så jeg kan konkludere med at det er en atferdsforskjell ved å 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 thrashed system, vil jeg gjerne ø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 systemets RAM er sannsynligvis ikke den tiltenkte bruken av innstillingen, og er for høy.
Innstilling vm.min_free_kbytes for å overleve omstarter
For å sikre at innstillingen kan overleve starter på nytt og ikke gjenopprettes til standardverdiene når du starter på nytt, må du sørge for å 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 endres og kan reservere minne på systemet for å sikre at systemet er mer stabilt, spesielt under tung bruk og tung minnetildeling. Standardinnstillingene kan være litt for lave, spesielt på systemer med høyt minne, og bør betraktes som økt nøye. Vi har sett at minnet som er reservert av denne tuneren, forhindrer OS-cachen i å bruke alt minnet og forhindrer også at noen malloc-operasjoner bruker alt minnet også.
