Cum funcționează vm.min_free_kbytes
Sistemul poate avea nevoie de alocări de memorie pentru a asigura buna funcționare a sistemului în sine. Dacă nucleul permite alocarea întregii memorii, s-ar putea să se întâmple dificultăți atunci când este nevoie de memorie pentru operațiuni regulate, pentru a menține sistemul de operare funcțional. De aceea, nucleul furnizează vm.min_free_kbytes reglabil. Reglabilul va forța managerul de memorie al nucleului să păstreze cel puțin X cantitate de memorie liberă. Iată definiția oficială din documentația kernel-ului Linux : Aceasta este utilizată pentru a forța mașina virtuală Linux să păstreze un număr minim de kilobyți liber. VM utilizează acest număr pentru a calcula o valoare de filigran [WMARK_MIN] pentru fiecare zonă lowmem din sistem. Fiecare zonă lowmem primește un număr de pagini gratuite rezervate în funcție de dimensiunea sa. Este necesară o cantitate minimă de memorie pentru a satisface alocațiile PF_MEMALLOC; dacă setați această valoare la mai puțin de 1024 KB, sistemul dvs. va deveni subtil spart și va fi predispus la blocare la sarcini mari. Setarea acestei valori prea mari va face OOM aparatul instantaneu.
Validarea funcționării vm.min_free_kbytes
Pentru a testa dacă setarea min_free_kbytes funcționează așa cum a fost proiectat, am creat o instanță virtuală Linux cu doar 3,75 GB RAM. Utilizați comanda gratuită de mai jos pentru a analiza sistemul:
#liber -m
Uitându-vă la utilitarul de memorie gratuit de mai sus folosind steagul -m pentru a avea valorile tipărite în MB. Memoria totală este de 3,5 până la 3,75 GB de memorie. Se folosesc 121 MB de memorie, 3,3 GB de memorie sunt liberi, 251 MB sunt folosiți de memoria cache a bufferului. Și 3,3 GB de memorie sunt disponibile.
Acum vom schimba valoarea vm.min_free_kbytes și vom vedea care este impactul asupra memoriei de sistem. Vom reda noua valoare sistemului de fișiere virtual proc pentru a schimba valoarea parametrului kernelului așa cum se arată mai jos:
# echo 1500000> / proc / sys / vm / min_free_kbytes# sysctl vm.min_free_kbytes
Puteți vedea că parametrul a fost schimbat la 1,5 GB aproximativ și a intrat în vigoare. Acum să folosim liber comandați din nou pentru a vedea orice schimbări recunoscute de sistem.
#liber -m 
Memoria gratuită și memoria tampon sunt neschimbate de comandă, dar cantitatea de memorie afișată ca disponibil a fost redus de la 3327 la 1222 MB. Ceea ce reprezintă o reducere aproximativă a modificării parametrului la 1,5 GB min memorie liberă.
Acum să creăm un fișier de date de 2 GB și apoi să vedem ce face citirea acelui fișier în memoria cache a valorilor. Iată cum puteți crea un fișier de date de 2 GB în 2 linii de script bash de mai jos. Scriptul va genera un fișier aleatoriu de 35 MB utilizând comanda dd și apoi îl va copia de 70 de ori într-un nou fișier de date ieșire:
# dd if = / dev / random of = / root / d1.txt count = 1000000# pentru i în `seq 1 70`; face ecou $ i; cat /root/d1.txt >> / root / data_file; Terminat
Să citim fișierul și să ignorăm conținutul citind și redirecționând fișierul către / dev / null conform celor de mai jos:
#pisicăfișier de date> /dev/nulOk, ce s-a întâmplat cu memoria noastră de sistem cu acest set de manevre, să verificăm acum:
#liber -m 
Analizând rezultatele de mai sus. Mai avem încă 1,8 GB de memorie liberă, astfel încât nucleul a protejat o mare parte din memorie, așa cum este rezervată din cauza setării noastre min_free_kbytes. Cache-ul tampon a folosit 1691 MB, care este mai mică decât dimensiunea totală a fișierului nostru de date, care este de 2,3 GB. Aparent întregul fișier de date nu a putut fi stocat în cache din cauza lipsei de memorie disponibilă de utilizat pentru cache-ul tampon. Putem valida faptul că întregul fișier nu este stocat în cache, ci sincronizarea încercărilor repetate de a citi fișierul. Dacă ar fi stocat în cache, ar fi nevoie de o fracțiune de secundă pentru a citi fișierul. Hai sa incercam.
# time cat_fichier date> / dev / null# time cat_fichier date> / dev / null
Fișierul citit a durat aproape 20 de secunde, ceea ce implică aproape sigur că nu toate sunt stocate în cache.
Ca o validare finală, să reducem vm.min_free_kbytes pentru a permite cache-ului paginii să aibă mai mult spațiu de funcționare și ne putem aștepta să vedem cum cache-ul funcționează și citirea fișierului devine mult mai rapidă.
# echo 67584> / proc / sys / vm / min_free_kbytes# time cat_fichier date> / dev / null
# time cat_fichier date> / dev / null
Cu memoria suplimentară disponibilă pentru stocarea în cache a timpului de citire a fișierului a scăzut de la 20 de secunde înainte la .364 secunde, cu totul în cache.
Sunt curios să mai fac un experiment. Ce se întâmplă cu apelurile malloc pentru a aloca memorie dintr-un program C în fața acestei setări foarte mari vm.min_free_kbytes. Va eșua mallocul? Va muri sistemul? Mai întâi resetați setarea vm.min_free_kbytes la valoarea cu adevărat ridicată pentru a relua experimentele noastre:
#aruncat 1500000 > /la sută/sys/vm/min_free_kbytesSă ne uităm din nou la memoria noastră gratuită:
Teoretic avem 1.9 GB gratuit și 515 MB disponibili. Să folosim un program de testare a stresului numit stress-ng pentru a folosi un pic de memorie și a vedea unde eșuăm. Vom folosi testerul vm și vom încerca să alocăm 1 GB de memorie. Deoarece am rezervat doar 1,5 GB pe un sistem de 3,75 GB, cred că acest lucru ar trebui să funcționeze.
# stress-ng --vm 1 --vm-bytes 1G - timeout 60sstres: informații:[17537]expedierea porcilor:1vm
stres: informații:[17537]alocare cache: dimensiune implicită cache: 46080K
stres: informații:[17537]alergare de succes finalizatăîn60.09s(1min,0,09uscat)
# stress-ng --vm 2 --vm-bytes 1G - timeout 60s
# stress-ng --vm 3 --vm-bytes 1G - timeout 60s
Să încercăm din nou cu mai mulți muncitori, putem încerca 1, 2, 3, 4 muncitori și la un moment dat ar trebui să eșueze. În testul meu a trecut cu 1 și 2 muncitori, dar a eșuat cu 3 muncitori.
Să resetăm vm.min_free_kbytes la un număr redus și să vedem dacă asta ne ajută să rulăm 3 factori de stres de memorie cu câte 1 GB pe un sistem de 3,75 GB.
# echo 67584> / proc / sys / vm / min_free_kbytes# stress-ng --vm 3 --vm-bytes 1G - timeout 60s
De data aceasta a funcționat cu succes fără erori, l-am încercat de două ori fără probleme. Așadar, pot concluziona că există o diferență de comportament de a avea mai multă memorie disponibilă pentru malloc, atunci când valoarea vm.min_free_kbytes este setată la o valoare mai mică.
Setare implicită pentru vm.min_free_kbytes
Valoarea implicită pentru setarea din sistemul meu este 67584, care reprezintă aproximativ 1,8% din RAM pe sistem sau 64 MB. Din motive de siguranță pe un sistem puternic afectat, aș tinde să-l măresc puțin, probabil, la 128 MB pentru a permite o memorie liberă mai rezervată, cu toate acestea, pentru utilizarea medie, valoarea implicită pare suficient de sensibilă. Documentația oficială avertizează cu privire la creșterea valorii. Setarea la 5 sau 10% din RAM-ul sistemului nu este probabil folosirea intenționată a setării și este prea mare.
Setarea vm.min_free_kbytes pentru a supraviețui repornirilor
Pentru a vă asigura că setarea poate supraviețui repornirilor și nu este restabilită la valorile implicite la repornire, asigurați-vă că faceți setarea sysctl persistentă punând noua valoare dorită în fișierul /etc/sysctl.conf.
Concluzie
Am văzut că reglabilul kernel linux vm.min_free_kbytes poate fi modificat și poate rezerva memorie pe sistem, pentru a se asigura că sistemul este mai stabil, în special în timpul utilizărilor grele și alocărilor de memorie grele. Setările implicite ar putea fi puțin prea mici, în special pe sistemele cu memorie mare și ar trebui considerate a fi mărite cu atenție. Am văzut că memoria rezervată de acest reglabil împiedică memoria cache a sistemului de operare să utilizeze toată memoria și, de asemenea, împiedică unele operații malloc să folosească și toată memoria.