Com funciona vm.min_free_kbytes
És possible que el sistema necessiti assignacions de memòria per garantir un funcionament adequat del propi sistema. Si el nucli permet assignar tota la memòria, pot tenir dificultats quan es necessiti memòria per a operacions regulars per mantenir el sistema operatiu sense problemes. És per això que el nucli proporciona el sintonitzable vm.min_free_kbytes. El sintonitzador obligarà el gestor de memòria del nucli a conservar almenys X quantitat de memòria lliure. Aquí teniu la definició oficial de documentació del nucli linux : S'utilitza per obligar la màquina virtual Linux a mantenir lliure un nombre mínim de kilobytes. La màquina virtual utilitza aquest número per calcular un valor de filigrana [WMARK_MIN] per a cada zona lowmem del sistema. Cada zona lowmem obté un nombre de pàgines lliures reservades proporcionalment a la seva mida. Es necessita una quantitat mínima de memòria per satisfer les assignacions PF_MEMALLOC; si ho definiu per sota de 1024 KB, el vostre sistema quedarà subtilment trencat i propens a bloquejar-se amb càrregues elevades. Si configureu aquest valor massa alt, la vostra màquina serà OOM instantània.
Validació de vm.min_free_kbytes Works
Per tal de comprovar que la configuració de min_free_kbytes funciona tal com s'ha dissenyat, he creat una instància virtual de Linux amb només 3,75 GB de RAM. Utilitzeu l'ordre lliure següent per analitzar el sistema:
#gratuït -m
Consulteu la utilitat de memòria gratuïta anterior utilitzant el senyalador -m per imprimir els valors en MB. La memòria total és de 3,5 a 3,75 GB de memòria. S’utilitzen 121 MB de memòria, 3,3 GB de memòria són lliures, 251 MB s’utilitzen a la memòria cau de memòria intermèdia. I hi ha 3,3 GB de memòria disponibles.
Ara canviarem el valor de vm.min_free_kbytes i veurem quin impacte té sobre la memòria del sistema. Ens farem ressò del nou valor al sistema de fitxers virtual proc per canviar el valor del paràmetre del nucli tal i com es mostra a continuació:
# echo 1500000> / proc / sys / vm / min_free_kbytes# sysctl vm.min_free_kbytes
Podeu veure que el paràmetre s’ha canviat a 1,5 GB aproximadament i ha tingut efecte. Ara fem servir el gratuït torneu a ordenar per veure els canvis reconeguts pel sistema.
#gratuït -m 
La memòria lliure i la memòria cau de memòria intermèdia no canvien per l'ordre, però la quantitat de memòria que es mostra com a disponible s'ha reduït de 3327 a 1222 MB. Que suposa una reducció aproximada del canvi del paràmetre a 1,5 GB de memòria lliure mínima.
Ara creem un fitxer de dades de 2 GB i, a continuació, vegem què fa els valors la lectura d’aquest fitxer a la memòria cau de memòria intermèdia. A continuació s’explica com es crea un fitxer de dades de 2 GB en 2 línies de script bash a continuació. L'script generarà un fitxer aleatori de 35 MB amb l'ordre dd i, a continuació, el copiarà 70 vegades en un de nou fitxer_dades sortida:
# dd if = / dev / random of = / root / d1.txt count = 1000000# per a i a la 'seq 1 70'; feu ressò de $ i; cat /arrel/d1.txt >> / root / fitxer_dades; fet
Llegim el fitxer i ignorem el contingut llegint i redirigint el fitxer a / dev / null tal com es mostra a continuació:
#gatfitxer_dades> /dev/nulD’acord, què ha passat amb la memòria del nostre sistema amb aquest conjunt de maniobres, comprovem-ho ara:
#gratuït -m 
Analitzant els resultats anteriors. Encara tenim 1,8 GB de memòria lliure, de manera que el nucli ha protegit una gran quantitat de memòria reservada a causa del nostre paràmetre min_free_kbytes. La memòria cau de memòria intermèdia ha utilitzat 1691 MB, que és inferior a la mida total del nostre fitxer de dades, que és de 2,3 GB. Aparentment la totalitat fitxer_dades no s'ha pogut emmagatzemar a la memòria cau a causa de la manca de memòria disponible per utilitzar a la memòria cau de memòria intermèdia. Podem validar que tot l’arxiu no s’emmagatzema a la memòria cau, sinó temporitzar els intents repetits de llegir-lo. Si es guardava a la memòria cau, trigaria una fracció de segon a llegir el fitxer. Provem-ho.
# time cat fitxer_dades> / dev / null# time cat fitxer_dades> / dev / null
El fitxer llegit va trigar gairebé 20 segons, la qual cosa implica que gairebé segur que no tot és a la memòria cau.
Com a validació final, reduïm els vm.min_free_kbytes per permetre que la memòria cau de la pàgina tingui més espai per funcionar i podem esperar que la memòria cau funcioni i que el fitxer llegit sigui molt més ràpid.
# echo 67584> / proc / sys / vm / min_free_kbytes# time cat fitxer_dades> / dev / null
# time cat fitxer_dades> / dev / null
Amb la memòria addicional disponible per emmagatzemar a la memòria cau, el temps de lectura del fitxer ha caigut de 20 segons abans a .364 segons amb tot a la memòria cau.
Tinc curiositat per fer un altre experiment. Què passa amb les trucades malloc per assignar memòria d'un programa C davant d'aquesta configuració de vm.min_free_kbytes realment alta. Fallarà el malloc? El sistema morirà? Primer restableix el paràmetre vm.min_free_kbytes al valor realment alt per reprendre els nostres experiments:
#trobo 1500000 > /per cent/sys/vm/min_free_kbytesVegem de nou la nostra memòria lliure:
Teòricament tenim 1,9 GB gratuïts i 515 MB disponibles. Utilitzem un programa de proves d’estrès anomenat stress-ng per tal d’utilitzar una mica de memòria i veure on fallem. Utilitzarem el provador de vm i intentarem assignar 1 GB de memòria. Com que només hem reservat 1,5 GB en un sistema de 3,75 GB, suposo que hauria de funcionar.
# stress-ng --vm 1 --vm-bytes 1G - timeout 60sestrès: informació:[17537]despatx de porcs:1vm
estrès: informació:[17537]assignació de memòria cau: mida de memòria cau per defecte: 46080K
estrès: informació:[17537]s'ha completat amb èxitdins60,09 s(1min,0.09sec)
# stress-ng --vm 2 --vm-bytes 1G - timeout 60s
# stress-ng --vm 3 --vm-bytes 1G - timeout 60s
Torneu-ho a provar amb més treballadors, podem provar 1, 2, 3, 4 treballadors i en algun moment hauria de fracassar. En la meva prova, va superar amb 1 i 2 treballadors, però va fallar amb 3 treballadors.
Restablim un nombre baix de vm.min_free_kbytes i comprovem si això ens ajuda a executar 3 estressors de memòria amb 1 GB cadascun en un sistema de 3,75 GB.
# echo 67584> / proc / sys / vm / min_free_kbytes# stress-ng --vm 3 --vm-bytes 1G - timeout 60s
Aquesta vegada ha funcionat amb èxit sense error, ho he provat dues vegades sense problemes. Per tant, puc concloure que hi ha una diferència de comportament de tenir més memòria disponible per malloc, quan el valor vm.min_free_kbytes està definit com a un valor inferior.
Configuració predeterminada per a vm.min_free_kbytes
El valor per defecte per a la configuració del meu sistema és 67584, que és aproximadament l’1,8% de RAM del sistema o 64 MB. Per motius de seguretat en un sistema molt afectat, tendiria a augmentar-lo una mica potser fins a 128 MB per permetre una memòria lliure més reservada, però, per a un ús mitjà, el valor per defecte sembla prou sensat. La documentació oficial adverteix sobre com augmentar el valor. Establir-lo al 5 o al 10% de la memòria RAM del sistema probablement no sigui l’ús previst per a la configuració i és massa alt.
Configuració de vm.min_free_kbytes per sobreviure als reinicis
Per assegurar-vos que el paràmetre pot sobreviure als reinicis i no es restaura els valors predeterminats en reiniciar-lo, assegureu-vos que el paràmetre sysctl sigui persistent posant el valor nou desitjat al fitxer /etc/sysctl.conf.
Conclusió
Hem vist que el kernel linux vm.min_free_kbytes sintonitzable es pot modificar i pot reservar memòria al sistema per tal de garantir que el sistema sigui més estable, especialment durant un ús intens i assignacions de memòria intenses. La configuració predeterminada pot ser una mica massa baixa, especialment en sistemes de memòria elevada i s’hauria de considerar que s’incrementa amb cura. Hem vist que la memòria reservada per aquest sintonitzador impedeix que la memòria cau del sistema operatiu faci servir tota la memòria i també impedeix que algunes operacions malloc també utilitzin tota la memòria.