[Linux] Memory manager/geheugen gebruik van een applicatie

[ATS]

Ik ben bezig met het schrijven van een applicatie die draait op Linux PDA's. Er is voor deze applicatie een sterke tradeoff tussen geheugengebruik en CPU gebruik, resources die beide schaars zijn op een PDA. Het programma zit zo in elkaar dat bestanden pas geladen worden op het moment dat ze nodig zijn, maar daarna in principe in het geheugen blijven. Op een gegeven moment komt het einde van het geheugen in zicht, en gaan we weer bestanden die we waarschijnlijk niet heel binnenkort nodig hebben weer uit het geheugen verwijderen. So far, so good. Het probleem is echter dat het geheugen gereserveerd blijft voor de applicatie, of in ieder geval, daar lijkt het op. Na het unloaden van gegevens is het geheugengebruik niet of niet significant gedaald, maar we kunnen wel nieuwe gegevens laden zonder dat het geheugengebruik stijgt.

We meten het vrije geheugen door de som te nemen van 'FreeMem', 'Buffers' en 'Cache' uit /proc/meminfo. Maar: kennelijk is dat niet voldoende om te weten hoeveel er écht beschikbaar is.

Ik leidt hieruit af dat de memorymanager zo werkt dat hij geheugen dat is vrijgegeven door een applicatie (in principe) voor deze applicatie gereserveerd houdt. Klopt dat? En, als dat zo is, bestaat er een manier om uit te vinden hoeveel geheugen dat betreft?

[igmar]

ATS schreef op 15 maart 2004 @ 17:09:
Ik leidt hieruit af dat de memorymanager zo werkt dat hij geheugen dat is vrijgegeven door een applicatie (in principe) voor deze applicatie gereserveerd houdt. Klopt dat? En, als dat zo is, bestaat er een manier om uit te vinden hoeveel geheugen dat betreft?

Dat hangt van de implementatie af. Wat gebruik je precies ? PDA's gebruiken over het algemeen geen full-blown glibc, maar zoiets als uclibc oid.

[odysseus]

Op een gegeven moment tijdens de ontwikkeling van 2.4 werd gezegd dat er geen manier (meer) was om het exacte geheugengebruik van een systeem te bepalen. Ik concludeer daaruit dat het ook niet mogelijk is het geheugengebruik van een enkele applicatie te bepalen. Je beste kans om te zien of het werkt: start een tweede programma op, dat kleine stukjes geheugen alloceert tot dat niet meer lukt en dan aangeeft hoeveel er 'veroverd' kon worden. Vervolgens doe je dat nog eens na het vrijgeven van je bestanden en als je tweede programma dan meer geheugen kan veroveren, dan is het blijkbaar door je eerste programma vrijgegeven .

* odysseus beseft dat dit niet de mooiste oplossing is...maar het lijkt me wel een goed werkende .

[ATS]

@odysseus: Hmmm.... dat is wel heel erg "hackish". Als ik zoveel geheugen door een ander programma laat alloceren, dan loopt het hele geheugen dus vol. Dat kan serieuze consequenties hebben voor het blijven lopen van het hele systeem. Het punt was nu juist dat ik wilde voorkomen dat mijn geheugen vol zou lopen...

@igmar: /proc/version zegt: "2.4.18-rmk7-pxa3-embedix-021129
Weet je toevallig hoe ik kan zien wat voor lib er gebruikt wordt? Ik zie in /lib alleen gewoon "libc.so.6" die verwijst naar libc-2.2.2.so.

[ Voor 9% gewijzigd door ATS op 15-03-2004 19:05 ]

[RvdH]

ATS schreef op 15 maart 2004 @ 19:04:
@odysseus: Hmmm.... dat is wel heel erg "hackish". Als ik zoveel geheugen door een ander programma laat alloceren, dan loopt het hele geheugen dus vol. Dat kan serieuze consequenties hebben voor het blijven lopen van het hele systeem. Het punt was nu juist dat ik wilde voorkomen dat mijn geheugen vol zou lopen...

@igmar: /proc/version zegt: "2.4.18-rmk7-pxa3-embedix-021129
Weet je toevallig hoe ik kan zien wat voor lib er gebruikt wordt? Ik zie in /lib alleen gewoon "libc.so.6" die verwijst naar libc-2.2.2.so.

Voer uit: /lib/libc-2.2.2.so en lees de eerste regel

[ATS]

/lib/libc-2.2.2.so is niet executable en ook cat maakt er niets leesbaars van...

[RvdH]

ATS schreef op 15 maart 2004 @ 20:56:
/lib/libc-2.2.2.so is niet executable en ook cat maakt er niets leesbaars van...

Hmm ik moest hem ook eerst executable maken:

code:

web1:~# chmod +x /lib/libc.so.6
web1:~# /lib/libc.so.6 | head -n 1
GNU C Library stable release version 2.3.2, by Roland McGrath et al

[igmar]

RickJansen schreef op 16 maart 2004 @ 09:23:
Hmm ik moest hem ook eerst executable maken:

code:

web1:~# chmod +x /lib/libc.so.6
web1:~# /lib/libc.so.6 | head -n 1
GNU C Library stable release version 2.3.2, by Roland McGrath et al

glibc op een embedded platform Dat kost inderdaad geheugen.

De globale werking van de malloc() functies van glibc :

- Indien het te alloceren object < 128 kb is wordt d'r brk() gebruikt en een linked list. Objecten die worden vrijgegeven worden enkel in de linked list als vrij aangemerk en hergebruikt.

- Indien het object > 128 kb is, wordt d'r mmap() gebruikt. Objecten die worden vrijgegeven worden antijd munmap()ed.

maw : Je geheugegebruik gaat niet naar beneden omdat je allemaal kleine objecten hebt die niet echt worden vrijgegeven. Merk op dat malloc() standaard gaat opschonen als je 128 kb ongebruikte chunks hebt.

De oplossing(en)

1) Een andere libc die wat meer is toegespitst op embedded systemen
2) Wat compile time opties van glibc veranderen
3) malloc_trim() aanroepen :

code:

if (malloc_trim(0) == 0)
   /* Geen geheugen vrij gegeven */;
else
  /* We geheugen vrijgeven */;

4) malloc africhten via mallopt()

code:

mallopt(M_TRIM_TRESHOLD, 32*1024);
mallopt(M_MMAP_TRESHOLD, 64*1024);

Indien je een systeem hebt dat geen negatieve sbrk() ondersteund zal malloc_trim() niet werken, en zal ook M_TRIM_TRESHOLD geen functie hebben.

[ATS]

Ik heb geprobeerd de versie te achterhalen, maar ik mag libc-2.2.2.so niet executable maken (ook niet als root): het filesystem is read only. Klopt ook wel, het is in rom.

@igmar: ik zal hier eens mee spelen. Ik kan niet zomaar de glibc vervangen (het is gewoon een standaard platform), maar ik kan wel proberen malloc_trim() aan te roepen. Op zich vind ik het helemaal niet erg dat het geheugen niet aan het OS teruggegeven wordt, ik zou alleen graag inzicht hebben in hoeveel geheugen de applicatie zelf nog op voorraad heeft, zodat ik een betere inschatting kan maken of ik nog een extra bestand kan laden of niet.

Ik ben ook aan het kijken naar mallinfo(), maar tot nu toe is dat nog niet gelukt. Anders wordt het vrees ik new en delete overloaden

[ajvdvegt]

Als e de bibliotheek naar een RAM kan kopieren kan je hem wel even executable maken.

[ATS]

Ik heb een oplossing gevonden die zeer werkbaar blijkt voor mij!

code:

    #include <malloc.h>

    struct mallinfo m = mallinfo();

    //add the free space on the heap to the total free space, minus the fragmentation factor
    int heapfree=m.fordblks/1024;
    qDebug("free heapspace: % KB", heapfree);
    if (heapfree > HEAP_FRAGMENTATION_FACTOR) res += heapfree - HEAP_FRAGMENTATION_FACTOR;

mallinfo geeft een struct terug die gevuld is met informatie over het gealloceerde geheugen. Het veld fordblks daarvan geeft het aantal vrije bytes op de heap. Dat aantal, minus een vast getal (ik werk nu met 256KB) om rekening te houden met geheugenfragmentatie, tel ik op bij het vrije geheugen volgens het OS (zie TS), en ik krijg een realistisch antwoord op de vraag hoeveel geheugen ik nog ter beschikking heb.
Iedereen bedankt voor de ideeën!

* ATS is a happy programmer!