Hoe vm.min_free_kbytes werkt
Geheugentoewijzingen kunnen door het systeem nodig zijn om een goede werking van het systeem zelf te garanderen. Als de kernel toestaat dat al het geheugen wordt toegewezen, kan het moeilijk zijn om geheugen nodig te hebben voor normale bewerkingen om het besturingssysteem soepel te laten werken. Daarom biedt de kernel de afstembare vm.min_free_kbytes. De afstembare zal de geheugenbeheerder van de kernel dwingen om ten minste X hoeveelheid vrij geheugen te behouden. Hier is de officiële definitie van de linux kernel documentatie : Dit wordt gebruikt om de Linux-VM te dwingen een minimum aantal kilobytes vrij te houden. De VM gebruikt dit nummer om een watermerk [WMARK_MIN]-waarde te berekenen voor elke lowmem-zone in het systeem. Elke lowmem-zone krijgt een aantal gereserveerde gratis pagina's, proportioneel op basis van de grootte. Er is een minimale hoeveelheid geheugen nodig om te voldoen aan PF_MEMALLOC-toewijzingen; als u dit instelt op minder dan 1024 KB, zal uw systeem op subtiele wijze kapot gaan en bij hoge belasting vatbaar zijn voor een impasse. Als u dit te hoog instelt, wordt uw machine onmiddellijk OOM.
Validatie van vm.min_free_kbytes Works
Om te testen of de instelling van min_free_kbytes werkt zoals bedoeld, heb ik een virtuele Linux-instantie gemaakt met slechts 3,75 GB RAM. Gebruik de onderstaande gratis opdracht om het systeem te analyseren:
#vrij -m
Kijkend naar het gratis geheugenhulpprogramma hierboven met behulp van de vlag -m om de waarden in MB te laten afdrukken. Het totale geheugen is 3,5 tot 3,75 GB geheugen. Er wordt 121 MB geheugen gebruikt, 3,3 GB geheugen is vrij, 251 MB wordt gebruikt door de buffercache. En er is 3,3 GB geheugen beschikbaar.
Nu gaan we de waarde van vm.min_free_kbytes wijzigen en kijken wat de impact is op het systeemgeheugen. We zullen de nieuwe waarde naar het virtuele bestandssysteem proc herhalen om de waarde van de kernelparameter als volgt te wijzigen:
# echo 1500000 > /proc/sys/vm/min_free_kbytes# sysctl vm.min_free_kbytes
U kunt zien dat de parameter is gewijzigd in ongeveer 1,5 GB en van kracht is geworden. Laten we nu de . gebruiken vrij commando opnieuw om eventuele wijzigingen te zien die door het systeem worden herkend.
#vrij -m 
Het vrije geheugen en de buffercache blijven ongewijzigd door de opdracht, maar de hoeveelheid geheugen wordt weergegeven als beschikbaar is teruggebracht van 3327 naar 1222 MB. Dat is een geschatte vermindering van de wijziging in de parameter tot 1,5 GB min vrij geheugen.
Laten we nu een gegevensbestand van 2 GB maken en dan kijken wat het lezen van dat bestand in de buffercache doet met de waarden. Hier leest u hoe u een gegevensbestand van 2 GB kunt maken in 2 regels bash-script hieronder. Het script genereert een willekeurig bestand van 35 MB met de opdracht dd en kopieert het 70 keer naar een nieuwe data bestand uitgang:
# dd if=/dev/random of=/root/d1.txt count=1000000# voor i in `seq 1 70`; doe echo $i; cat /root/d1.txt >> /root/data_file; gedaan
Laten we het bestand lezen en de inhoud negeren door het bestand te lezen en om te leiden naar /dev/null zoals hieronder:
#katdata bestand> /dev/nulOké, wat is er met ons systeemgeheugen gebeurd met deze reeks manoeuvres, laten we het nu controleren:
#vrij -m 
Analyse van de resultaten hierboven. We hebben nog steeds 1,8 GB vrij geheugen, dus de kernel heeft een groot deel van het geheugen beschermd als gereserveerd vanwege onze min_free_kbytes-instelling. De buffercache heeft 1691 MB gebruikt, wat minder is dan de totale grootte van ons gegevensbestand dat 2,3 GB is. Blijkbaar de hele data bestand kon niet in de cache worden opgeslagen vanwege het gebrek aan beschikbaar geheugen om te gebruiken voor de buffercache. We kunnen valideren dat het hele bestand niet in de cache is opgeslagen, maar de herhaalde pogingen om het bestand te lezen te timen. Als het in de cache was opgeslagen, zou het een fractie van een seconde duren om het bestand te lezen. Laten we het proberen.
# time cat data_file > /dev/null# time cat data_file > /dev/null
Het lezen van het bestand duurde bijna 20 seconden, wat inhoudt dat het vrijwel zeker niet allemaal in de cache is opgeslagen.
Laten we als laatste validatie de vm.min_free_kbytes verminderen om de paginacache meer ruimte te geven om te werken en we kunnen verwachten dat de cache werkt en het lezen van het bestand veel sneller gaat.
# echo 67584 > /proc/sys/vm/min_free_kbytes# time cat data_file > /dev/null
# time cat data_file > /dev/null
Met het extra geheugen dat beschikbaar was voor caching, daalde de leestijd van het bestand van 20 seconden eerder naar 0,364 seconden met alles in de cache.
Ik ben benieuwd om nog een experiment te doen. Wat gebeurt er met malloc-aanroepen om geheugen toe te wijzen vanuit een C-programma in het licht van deze echt hoge vm.min_free_kbytes-instelling. Zal het de malloc niet lukken? Gaat het systeem dood? Reset eerst de instelling vm.min_free_kbytes naar de echt hoge waarde om onze experimenten te hervatten:
#gooide uit 1500000 > /procent/sys/vm/min_free_kbytesLaten we nog eens kijken naar ons gratis geheugen:
Theoretisch hebben we 1,9 GB gratis en 515 MB beschikbaar. Laten we een stresstestprogramma gebruiken, stress-ng genaamd, om wat geheugen te gebruiken en te zien waar we falen. We zullen de vm-tester gebruiken en proberen 1 GB geheugen toe te wijzen. Aangezien we slechts 1,5 GB hebben gereserveerd op een systeem van 3,75 GB, denk ik dat dit zou moeten werken.
# stress-ng --vm 1 --vm-bytes 1G --time-out 60sspanning: info:[17537]varkens verzenden:1vm
spanning: info:[17537]cache toewijzen: standaard cachegrootte: 46080K
spanning: info:[17537]succesvolle run voltooidin60.09s(1min,0,09droog)
# stress-ng --vm 2 --vm-bytes 1G --time-out 60s
# stress-ng --vm 3 --vm-bytes 1G --time-out 60s
Laten we het opnieuw proberen met meer werkers, we kunnen 1, 2, 3, 4 werkers proberen en op een gegeven moment zou het moeten mislukken. In mijn test slaagde het met 1 en 2 arbeiders, maar faalde met 3 arbeiders.
Laten we de vm.min_free_kbytes terugzetten naar een laag aantal en kijken of dat ons helpt om 3 geheugenstressoren met elk 1 GB op een systeem van 3,75 GB uit te voeren.
# echo 67584 > /proc/sys/vm/min_free_kbytes# stress-ng --vm 3 --vm-bytes 1G --time-out 60s
Deze keer liep het zonder fouten, ik probeerde het twee keer zonder problemen. Dus ik kan concluderen dat er een gedragsverschil is om meer geheugen beschikbaar te hebben voor malloc, wanneer de waarde vm.min_free_kbytes is ingesteld op een lagere waarde.
Standaardinstelling voor vm.min_free_kbytes
De standaardwaarde voor de instelling op mijn systeem is 67584, wat ongeveer 1,8% RAM op het systeem of 64 MB is. Om veiligheidsredenen op een zwaar afgeranseld systeem zou ik de neiging hebben om het een beetje te verhogen, misschien tot 128 MB om meer gereserveerd vrij geheugen mogelijk te maken, maar voor gemiddeld gebruik lijkt de standaardwaarde redelijk genoeg. De officiële documentatie waarschuwt voor het te hoog maken van de waarde. Het instellen op 5 of 10% van het systeem-RAM is waarschijnlijk niet het beoogde gebruik van de instelling en is te hoog.
vm.min_free_kbytes instellen om reboots te overleven
Om ervoor te zorgen dat de instelling een herstart overleeft en niet wordt hersteld naar de standaardwaarden bij het herstarten, moet u ervoor zorgen dat de sysctl-instelling blijvend is door de gewenste nieuwe waarde in het bestand /etc/sysctl.conf te plaatsen.
Conclusie
We hebben gezien dat de afstembare vm.min_free_kbytes linux-kernel kan worden gewijzigd en geheugen op het systeem kan reserveren om ervoor te zorgen dat het systeem stabieler is, vooral tijdens intensief gebruik en zware geheugentoewijzingen. De standaardinstellingen zijn misschien iets te laag, vooral op systemen met veel geheugen, en moeten worden overwogen om voorzichtig te worden verhoogd. We hebben gezien dat het geheugen dat door deze tunable is gereserveerd, voorkomt dat de OS-cache al het geheugen gebruikt en ook voorkomt dat sommige malloc-bewerkingen ook al het geheugen gebruiken.