Memleak / mem cleaner voor linux

[The Source]

Ik denk een memory leak op mijn webserver te hebben. Ik ben een beetje aan het uitzoeken waar aan het ligt. Maar ik betwijfel of, zodra ik er achter ben welk script/proggie verantwoordelijk is, het geheugen uit zichzelf vrijkomt.



(in week 38 is er een mem upgrade geweest. Daar is duidelijk te zien er een mem leak is.)



Daarom ben ik eigenlijk op zoek naar een memcleaner voor linux. Dan hoef ik mijn bak niet te rebooten. Ik weet dat je onder Windows programma's hebt die alle ten onrechte nog niet vrijgegeven geheugen segmenten vrij maken. Zijn er ook zulke programma onder linux? Of programma's die nagaan welke programma's welke geheugen segmenten in gebruik hebben?

[Verwijderd]

man malloc

[deadinspace]

Wat geeft die grafiek precies weer?
Het groene is (neem ik aan) de hoeveelheid geheugen die je hebt, en het blauwe is? Het geheugen dat in gebruik is, of het geheugen dat door programma's in gebruik is?
Geef anders eens de output van 'free -m'...

[The Source]

Nelske: man malloc is niet aanwezig. Ik heb wel http://freshmeat.net/projects/mark_malloc/ gevonden. Daar ga ik even naar kijken.

thesource@www public_html]# free -m
total used free shared buffers cached
Mem: 378 270 107 55 195 33
-/+ buffers/cache: 41 337
Swap: 517 0 517

Geeft dus het totale geheugen dat in gebruik is.

[Verwijderd]

man malloc:

code:

MALLOC(3)        Linux Programmer's Manual       MALLOC(3)

NAME
     calloc, malloc, free, realloc - Allocate and free dynamic memory

SYNOPSIS
     #include <stdlib.h>

     void *calloc(size_t nmemb, size_t size);
     void *malloc(size_t size);
     void free(void *ptr);
     void *realloc(void *ptr, size_t size);

DESCRIPTION
     calloc()  allocates memory for an array of nmemb elements of size bytes each and returns a pointer to the allocated memory.  The mem­
     ory is set to zero.

     malloc() allocates size bytes and returns a pointer to the allocated memory.  The memory is not cleared.

     free() frees the memory space pointed to by ptr, which must have been returned by a previous call to malloc(), calloc() or realloc().
     Otherwise, or if free(ptr) has already been called before, undefined behaviour occurs.  If ptr is NULL, no operation is performed.

     realloc() changes the size of the memory block pointed to by ptr to size bytes.  The contents will be unchanged to the minimum of the
     old and new sizes; newly allocated memory will be uninitialized.  If ptr is NULL, the call is equivalent to malloc(size); if size  is
     equal  to  zero, the call is equivalent to free(ptr).  Unless ptr is NULL, it must have been returned by an earlier call to malloc(),
     calloc() or realloc().

RETURN VALUE
     For calloc() and malloc(), the value returned is a pointer to the allocated memory, which is suitably aligned for any kind  of  vari­
     able, or NULL if the request fails.

     free() returns no value.

     realloc()  returns  a  pointer to the newly allocated memory, which is suitably aligned for any kind of variable and may be different
     from ptr, or NULL if the request fails or if size was equal to 0.  If realloc() fails the original block is left untouched  -  it  is
     not freed or moved.

CONFORMING TO
     ANSI-C

SEE ALSO
     brk(2)
NOTES
     The  Unix98  standard requires malloc(), calloc(), and realloc() to set errno to ENOMEM upon failure. Glibc assumes that this is done
     (and the glibc versions of these routines do this); if you use a private malloc implementation that does not set errno, then  certain
     library routines may fail without having a reason in errno.

     Crashes  in  malloc(),  free()  or  realloc() are almost always related to heap corruption, such as overflowing an allocated chunk or
     freeing the same pointer twice.

     Recent versions of Linux libc (later than 5.4.23) and GNU libc (2.x) include a malloc implementation which is tunable via environment
     variables.   When  MALLOC_CHECK_  is  set, a special (less efficient) implementation is used which is designed to be tolerant against
     simple errors, such as double calls of free() with the same argument, or overruns of a single byte (off-by-one bugs).  Not  all  such
     errors  can be proteced against, however, and memory leaks can result.  If MALLOC_CHECK_ is set to 0, any detected heap corruption is
     silently ignored; if set to 1, a diagnostic is printed on stderr; if set to 2, abort() is called immediately.   This  can  be  useful
     because otherwise a crash may happen much later, and the true cause for the problem is then very hard to track down.

     Linux  follows  an  optimistic memory allocation strategy.  This means that when malloc() returns non-NULL there is no guarantee that
     the memory really is available. In case it turns out that the system is out of memory, one or more processes will be  killed  by  the
     infamous OOM killer.

GNU              1993-04-04         MALLOC(3)

Het gaat dus om dat laatste stuk (MALLOC_CHECK_=1).

Overigens lijkt met een geheugenlek me heel sterk. Ik zie het geheugen gebruik namelijk niet steeds meer toenemen in dat grafiekje. Eigenlijk zie ik er niks vreemds aan, buiten een geheugen dip, maar dat kan allerlei oorzaken hebben.

[RG]

Geeft dus het totale geheugen dat in gebruik is.

Als je er emer RAM instopt zal Linux je Ram eerder gebruiken voor caching enzo... Dat is altijd zo, maar dat is absoluut geen probleem. Hoezo geheugenlek?? Als je een geheugenlek hebt, dan loopt die lijn zeer waarschijnlijk naar rechtsboven toe en zal het programma af worden geschoten als al het geheugen gebruikt is...

[deadinspace]

Op woensdag 10 oktober 2001 21:46 schreef nelske het volgende:
Eigenlijk zie ik er niks vreemds aan, buiten een geheugen dip, maar dat kan allerlei oorzaken hebben.

Gokje: toen heeft hij zijn bak uitgezet?
De groene lijn (total mem) gaat daar namelijk ook ineens omhoog, en ik gok niet dat zijn bak hotpluggable memory heeft

Op woensdag 10 oktober 2001 22:28 schreef RG© het volgende:
Als je er emer RAM instopt zal Linux je Ram eerder gebruiken voor caching enzo... Dat is altijd zo, maar dat is absoluut geen probleem. Hoezo geheugenlek?? Als je een geheugenlek hebt, dan loopt die lijn zeer waarschijnlijk naar rechtsboven toe en zal het programma af worden geschoten als al het geheugen gebruikt is...

precies

[igmar]

[quote]
Ik denk een memory leak op mijn webserver te hebben.
[quote]

Lijkt me sterk.

Daarom ben ik eigenlijk op zoek naar een memcleaner voor linux. Dan hoef ik mijn bak niet te rebooten. Ik weet dat je onder Windows programma's hebt die alle ten onrechte nog niet vrijgegeven geheugen segmenten vrij maken. Zijn er ook zulke programma onder linux? Of programma's die nagaan welke programma's welke geheugen segmenten in gebruik hebben?

Die bestaan niet. Zodra een process afloopt geeft de kernel het door die applicatie gebruikte geheugen weer vrij.

memclean is voor lame OS'sen die geen fatsoenlijk memory management hebben, waaronder alle Windows versies. Zolang de kernel z'n werk doet zijn er geen leaks.

Langlopende processen die leaks hebben worden op ene moment vanzelf afgeschoten, maar Apache hier is behoorlijk stabiel kwa geheugengebruik.

[The Source]

Er is idd meer geheugen ingezet (zoals het groene gebied aangeeft.) Maar voor de upgrade werd er max 200 gebruikt... Na de upgrade ben ik niet meer gaan draaien, dus dan ga ik er ook vanuit dat er niet meer mem gebruikt wordt. Maar dat was dus niet zo...

Ondertussen heb ik ook deze info:

total used free shared buffers cached
Mem: 378 338 40 45 285 19
-/+ buffers/cache: 33 345
Swap: 517 0 517


Wat betekent 285 in de buffers? Bruikbaar geheugen neem ik aan. Misschien laat ik MRTG wel het verkeerde monitoren...

[ACM]

Wat zou kunnen is dat je shared-memory segments leaked.

Kill je webserver-apps en doe es
ipcs

Als je dan een (lange) lijst krijgt (dat is overigens van alle apps die een shared memory segment aanmaken, dus ook je DB of whatever)

Evt kan je de segments verwijderen met ipcrm

[kenneth]

Op donderdag 11 oktober 2001 15:15 schreef The Source het volgende:
Er is idd meer geheugen ingezet (zoals het groene gebied aangeeft.) Maar voor de upgrade werd er max 200 gebruikt... Na de upgrade ben ik niet meer gaan draaien, dus dan ga ik er ook vanuit dat er niet meer mem gebruikt wordt. Maar dat was dus niet zo...

Gelukkig niet nee. Hoe meer geheugen, hoe meer Linux gebruikt voor de cache, en dat is wat iedereen wel wilt. Daarom is er onder een OS met VM nooit zoveel geheugen 'vrij': het wordt altijd wel ergens voor gebruikt, zij het code, zij het data, zij het cache...

[The Source]

ipcs leverde een lege lijst terug dus no problum daaro. Ik zal daarom maar aannemen wat mithalph zegt en het geheugen management onder linux niet zo bekijken als onder w2k. Alles draait nog soepel


iig iedereen bedankt die ff reageerde!

[Jelmer]

-/+ buffers/cache: 33 345

dus je hebt idd maar 33MB in gebruik en 345 vrij

[deadinspace]

Even voor de duidelijkheid: Het geheugengebruik dat jij op het grafiekje omhoog ziet gaan is het *totale* geheugengebruik.
Zoals al opgemerkt: programma's gebruiken een bepaalde hoeveelheid geheugen, en de kernel zal de rest grotendeels gebruiken voor buffers en cache.

Cache 'onthoudt' informatie (vnl van je HD) die vaak gelezen wordt, zodat als die informatie nog eens opgevraagd wordt, hij uit het geheugen kan komen, wat veel sneller is dan als het van de HD moet komen.
Buffers zijn ongeveer het tegenovergestelde; ze houden data die naar de HD geschreven wil worden nog even vast, zodat als die data vaak geschreven wil worden dat niet ook in werkelijkheid vaak gebeurt. Ook kan de kernel zo besluiten om die data pas weg te schrijven als het wat rustiger is (en het HD geratel dus niet zo uitmaakt).

Als je meer ram in een GNU/Linux bak stopt, en hij staat lang genoeg aan, dan zal het geheugen bijna allemaal gebruikt worden op die manier (ik heb/beheer 4 bakken met >512 meg ramm daar zie je dat gedrag heel sterk).
Maar dit is een goed iets, want dat geheugen wordt dus nuttig gebruikt, en caches en buffers leveren een enorme snelheidswinst (nouja, de eerste 32 of 64 MB ofzo iig wel... 256 of 512 MB maakt dan een stuk minder uit), zie DOS met en zonder SMARTDRV...

Voor gegevens over je geheugen kun je beter naar de output van 'free -m' kijken, dan zie je dat bij jou maar 33 MB gebruikt is door programma's zelf, en dat er in totaal 338 MB in gebruik is, dus een meg of 300 voor buffers en cache.

Het enige vreemde dat ik aan jouw free output kan ontdekken, is dat de buffers veel en veel groter zijn dan de caches, terwijl dit vaak andersom is (althans, zo zie ik het vaak).

[Verwijderd]

Op donderdag 11 oktober 2001 00:03 schreef deadinspace het volgende:
Gokje: toen heeft hij zijn bak uitgezet?
De groene lijn (total mem) gaat daar namelijk ook ineens omhoog, en ik gok niet dat zijn bak hotpluggable memory heeft

Damn, /me slaat zichzelf even voor zijn kop.
Die had ik zelf ook wel kunnen bedenken

[The Source]

Ik ben ook een beetje blind geweest. Boven de MRTG stats staat duidelijk:

"Linux can grow to fill almost all physical memory in the system,regardless of whether or not it is actually in use. On a Linux system, memory performance can best be gauged by watching the amount of swap space actually in use. If a system is using all of its physical memory and most of its swap, it probably needs more physical memory."