[DM7025] Hoeveel RAM is er nog vrij... - uitleg!

[Gast MiLo]

Omdat ik nog wel eens wat vragen krijg over het geheugen van de 7025, een artikeltje daarover. De tooling kan namelijk nogal verwarrend zijn...

 

Code:

root@dm7025:~# free              total         used         free       shared      buffers  Mem:        72908        71068         1840            0         3848 Swap:            0            0            0Total:        72908        71068         1840

 

Je zou kunnen concluderen dat er nog maar 1,8 MB RAM over is. Dat is wel juist, maar niet wat je weten wil. 1,8 MB van de RAM wordt momenteel nergens voor gebruikt, maar dat wil niet zeggen dat er maar 1,8 MB beschikbaar is.

 

Een trucje ter illustatie: Ik stop een groot bestand (enigma2 is ruim 2MB) in het geheugen (/tmp is in RAM!). Daarna gooi ik het weg.

 

Code:

root@dm7025:~# cp /usr/bin/enigma2 /tmproot@dm7025:~# free              total         used         free       shared      buffers  Mem:        72908        71180         1728            0         4300 Swap:            0            0            0Total:        72908        71180         1728root@dm7025:~# rm /tmp/enigma2root@dm7025:~# free              total         used         free       shared      buffers  Mem:        72908        68520         4388            0         4308 Swap:            0            0            0Total:        72908        68520         4388

 

Mooi he? Het "kost" maar 100k om 2M op te slaan, en ik krijg er veel voor terug, want nu heb ik ineens 4MB vrij.

 

"free" is hiervoor een totaal ongeschikt tooltje. "top" licht een stukje van de sluier op, op de eerste regels van de uitvoer:

Code:

root@dm7025:~# topMem: 68660K used, 4248K free, 0K shrd, 4312K buff, 21984K cachedLoad average: 0.01, 0.02, 0.00    (State: S=sleeping R=running, W=waiting)  PID USER     STATUS   RSS  PPID %CPU %MEM COMMAND27579 root     R        968 26484 16.8  1.3 top16213 root     S        27M 16208  0.8 38.2 enigma216221 root     S        27M 16213  0.8 38.2 enigma216229 root     S N      27M 16213  0.0 38.2 enigma2 2284 root     S       2008  1054  0.0  2.7 CCcam 1054 root     S       2008     1  0.0  2.7 CCcam

 

Hier zien we de "4248K free" weer terug. Maar is is ook nog "buff" en "cache". En daar zit de kneep. "buff" wordt gebruikt voor data van en naar disk, en "cache" is geheugen dat gebruikt wordt voor, eh, cache, dat is dus een kopietje van wat op disk staat. Je box kan dit geheugen op ieder moment vrij maken, want het is alleen maar om dingen sneller te maken. Linux gebruikt bijna alle geheugen dat toch niet in gebruik is voor iets anders voor de cache, bijvoorbeeld om een kopietje van de laatst gelezen disk data op te slaan. Als je het dan nog eens leest, is het veel sneller. Ook data die onderweg is om naar de disk geschreven te worden blijft even in de cache zitten tot de disk klaar is om deze te ontvangen.

 

Eigenlijk is er in totaal dus 4248K + 4312K + 21984K beschikbaar, bijna 30MB in totaal. Niet dat je de cache en buffers op 0 wil krijgen, daar wordt ie niet blij van. Maar zolang er nog lekker veel aan "cache" wordt toegewezen, is er niets aan de hand.

[Erik Slagter]

Bij een goed operating system (zoals linux...) wordt altijd al het geheugen maximaal gebruikt. Geheugen wat niet gebruikt wordt is zonde van het geld wat je ervoor betaald hebt en de energie die het gebruikt.

 

Daarom is het niet meer dan logisch dat het geheugengebruik ALTIJD op 100% staat (of daar vlak bij). Alleen vlak na het booten wil het nog wel eens lager staan.

 

Elk disk blok dat ooit gelezen of geschreven is, blijft in geheugen staan zolang er geen geheugen niet nodig is voor belangrijkere zaken. Uiteraard is het zo dat als geheugen wordt geconfisceerd dat in gebruik is voor blokken die nog geschreven moeten worden, dat die blokken dan ook eerst (meteen) weggeschreven worden. En uiteraard heeft de kernel een voorkeur voor het weggooien van cache-blokken die niet hoeven worden weggeschreven.

 

Linux gebruikt nog meer slimme truuks, als je een dynamic library aan je programma "gekoppeld" hebt en je programma opstart, dan wordt in eerste instantie helemaal niks daarvan ingelezen. Alleen blokken die gebruikt worden, worden ingelezen (en zonodig ook weer vrijgegeven). Dit in tegenstelling tot windows die altijd complete DLL's inleest bij het opstarten van een programma. Hetzelfde geldt ook voor de geheugen-delen van een programma, die worden alleen ingelezen vanaf schijf op het moment dat ze aangesproken worden. Deze delen worden ook nooit uitgeswapt maar gewoon uit het geheugen gegooid. Als je een programma twee (of meer keer) opstart, dan worden alleen de delen die schrijfbaar zijn (data...) dubbel in het geheugen gezet. Idem voor dynamic libraries, die worden altijd gedeeld met alle andere programma's. En nog een paar andere truukjes ;-)

 

Dit alles bij elkaar betekent dat de definitie van "vrij geheugen" heel complex is bij een goed operating system. Het is niet meer zoals bij MS/DOS vroeger.

 

Er zijn twee zaken die van belang zijn: als er programma afgeschoten gaan worden door de Out-Of-Memory-Killer (OOM-killer), dan is het (virtuele) geheugen echt OP. Oplossing: meer geheugen en/of meer swap.

 

Als je wel genoeg swap hebt, maar te weinig geheugen, dan wordt het systeem erg traag door het continu swappen. Dat zie terug in de "load" (zie uptime), als die boven de 1 komt (single core), dan is het foute boel.

 

Als je harddisk continu staat te ratelen, dan kan het een voordeel zijn om er meer geheugen in te stoppen. Meer is altijd beter, alles wordt gebruikt, alleen op een gegeven moment merk je het verschil niet meer.

 

Last but not least: als je cat /proc/meminfo doet, dan zie je wat meer info dan "free" (van busybox) geeft. Even "cached" er dan dus vanaf trekken.

[Gast MiLo]

Origineel bericht van: Erik Slagter

Dit in tegenstelling tot windows die altijd complete DLL's inleest bij het opstarten van een programma.

Onzin.

[Erik Slagter]

Okee, driekwart dan ;-) Ga maar eens een programma opstarten die flink wat dll's gebruikt. Ratel, ratel, ratel...