Phenquestions
Hur vm.min_free_kbytes fungerar
Minnesallokering kan behövas av systemet för att säkerställa att systemet fungerar korrekt. Om kärnan tillåter att allt minne tilldelas kan det kämpa när det behövs minne för regelbundna operationer för att OS ska fungera smidigt. Det är därför kärnan tillhandahåller den avstämbara vm.min_free_kbytes. Den inställbara enheten tvingar kärnans minneshanterare att hålla minst X-minne ledigt minne. Här är den officiella definitionen från dokumentation för Linux-kärnan: “Detta används för att tvinga Linux-VM att hålla ett minimum antal kilobytes gratis. Den virtuella datorn använder detta nummer för att beräkna ett vattenstämpelvärde [WMARK_MIN] för varje lowmem-zon i systemet. Varje lowmem-zon får ett antal reserverade fria sidor baserat på dess storlek. Någon minimal mängd minne behövs för att tillfredsställa PF_MEMALLOC-tilldelningar; om du ställer in detta till lägre än 1024 kB, kommer ditt system att bli subtilt trasigt och utsatt för dödläge under höga belastningar. Om du ställer in detta för högt kommer OOM din maskin att gå direkt.“
Validerar vm.min_free_kbytes Fungerar
För att testa att inställningen av min_free_kbytes fungerar som designad har jag skapat en virtuell Linux-instans med endast 3.75 GB RAM-minne. Använd det fria kommandot nedan för att analysera systemet:
# gratis -m
Tittar på det fria minnesverktyget ovan med flaggan -m för att skriva värdena i MB. Det totala minnet är 3.5 till 3.75 GB minne. 121 MB minne används, 3.3 GB minne är ledigt, 251 MB används av buffertcachen. Och 3.3 GB minne finns tillgängligt.
Nu ska vi ändra värdet på vm.min_free_kbytes och se vilken inverkan det har på systemminnet. Vi kommer att upprepa det nya värdet till proc virtuella filsystemet för att ändra kärnparametervärdet enligt nedan:
# echo 1500000> / proc / sys / vm / min_free_kbytes# sysctl vm.min_free_kbytes
Du kan se att parametern ändrades till 1.5 GB ungefär och har trätt i kraft. Låt oss nu använda fri kommandot igen för att se alla ändringar som systemet känner igen.
# gratis -m
Ledigt minne och buffertcache ändras inte av kommandot, men mängden minne visas som tillgängligt har minskats från 3327 till 1222 MB. Vilket är en ungefärlig minskning av ändringen av parametern till 1.5 GB min ledigt minne.
Låt oss nu skapa en 2 GB-datafil och sedan se vad som läser den filen i buffertcachen gör värdena. Så här skapar du en 2 GB datafil i två rader med bash-skript nedan. Skriptet genererar en 35 MB slumpmässig fil med kommandot dd och kopierar sedan 70 gånger till en ny data fil produktion:
# dd if = / dev / random of = / root / d1.txtantal = 1000000# för i i 'seq 1 70'; gör echo $ i; katt / rot / d1.txt >> / root / data_file; Gjort
Låt oss läsa filen och ignorera innehållet genom att läsa och omdirigera filen till / dev / null enligt nedan:
# cat data_file> / dev / nullOk, vad har hänt med vårt systemminne med denna uppsättning manövrer, låt oss kontrollera det nu:
# gratis -m
Analysera resultaten ovan. Vi har fortfarande 1.8 GB ledigt minne så att kärnan har skyddat en stor bit minne som reserverat på grund av vår min_free_kbytes-inställning. Buffertcache har använt 1691 MB, vilket är mindre än den totala storleken på vår datafil som är 2.3 GB. Tydligen hela data fil kunde inte lagras i cache på grund av brist på tillgängligt minne att använda för buffertcache. Vi kan verifiera att hela filen inte är lagrad i cache utan tidsinställning för upprepade försök att läsa filen. Om den cachades skulle det ta en bråkdel av en sekund att läsa filen. Låt oss testa det.
# time cat data_file> / dev / null# time cat data_file> / dev / null
Filen som lästes tog nästan 20 sekunder, vilket innebär att den nästan inte är cachad.
Som en slutlig validering, låt oss minska vm.min_free_kbytes så att sidans cache får mer utrymme att fungera och vi kan förvänta oss att cachen fungerar och filen läses blir mycket snabbare.
# echo 67584> / proc / sys / vm / min_free_kbytes# time cat data_file> / dev / null
# time cat data_file> / dev / null
Med det extra minne som finns tillgängligt för cachning minskade lästiden från 20 sekunder innan till .364 sekunder med allt i cache.
Jag är nyfiken på att göra ett nytt experiment. Vad händer med malloc-samtal för att fördela minne från ett C-program inför denna riktigt höga vm.min_free_kbytes inställning. Kommer det att misslyckas med malloc? Kommer systemet att dö? Återställ först vm.min_free_kbytes inställning till det riktigt höga värdet för att återuppta våra experiment:
# echo 1500000> / proc / sys / vm / min_free_kbytesLåt oss titta igen på vårt lediga minne:
Teoretiskt har vi 1.9 GB gratis och 515 MB tillgängligt. Låt oss använda ett stresstestprogram som heter stress-ng för att använda lite minne och se var vi misslyckas. Vi kommer att använda vm-testaren och försöka tilldela 1 GB minne. Eftersom vi bara har reserverat 1.5 GB på en 3.75 GB-system, jag antar att detta borde fungera.
# stress-ng --vm 1 --vm-bytes 1G - timeout 60sstress-ng: info: [17537] skickar svin: 1 vm
stress-ng: info: [17537] cache allocate: standard cache size: 46080K
stress-ng: info: [17537] lyckad körning avslutad 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
Låt oss prova det igen med fler arbetare, vi kan prova 1, 2, 3, 4 arbetare och någon gång skulle det misslyckas. I mitt test passerade det med 1 och 2 arbetare men misslyckades med 3 arbetare.
Låt oss återställa vm.min_free_kbytes till ett lågt antal och se om det hjälper oss att köra 3 minnesstressorer med 1 GB vardera på en 3.75 GB-system.
# echo 67584> / proc / sys / vm / min_free_kbytes# stress-ng --vm 3 --vm-bytes 1G - timeout 60s
Den här gången körde det utan problem, jag försökte det två gånger utan problem. Så jag kan dra slutsatsen att det finns en beteendemässig skillnad att ha mer minne tillgängligt för malloc, när vm.min_free_kbytes-värdet är inställt på ett lägre värde.
Standardinställning för vm.min_free_kbytes
Standardvärdet för inställningen på mitt system är 67584 vilket är ungefär 1.8% av RAM-minnet på systemet eller 64 MB. Av säkerhetsskäl på ett kraftigt trasigt system skulle jag kunna öka det kanske till 128 MB för att möjliggöra mer reserverat ledigt minne, men för genomsnittlig användning verkar standardvärdet förnuftigt nog. Den officiella dokumentationen varnar för att göra värdet för högt. Att ställa in den på 5 eller 10% av systemets RAM är förmodligen inte den avsedda användningen av inställningen och är för hög.
Ställa in vm.min_free_kbytes för att överleva omstart
För att säkerställa att inställningen kan överleva omstart och inte återställs till standardvärdena vid omstart, var noga med att göra sysctl-inställningen bestående genom att sätta det önskade nya värdet i / etc / sysctl.conf-fil.
Slutsats
Vi har sett att vm.min_free_kbytes Linux-kärnan kan anpassas och kan reservera minne i systemet för att säkerställa att systemet är mer stabilt, särskilt vid tung användning och tung minnestilldelning. Standardinställningarna kan vara lite för låga, särskilt på system med högt minne och bör betraktas som ökade noggrant. Vi har sett att minnet som reserverats av denna tunable hindrar OS-cache från att använda allt minne och förhindrar också att vissa malloc-operationer använder allt minne också.
