Geheugenlek traceren op CentOS Server?

[Verwijderd]

Op een server lijkt de laatste tijd het geheugen weleens vol te zitten. Dan krijg ik weer nagios meldingen dat de load tot 5 minuten boven de 20 is geweest, dan komt de OOM-killer in actie, en dan is de load weer rond de 0.2.

Ik begin heel erg het gevoel te krijgen dat het hier om een geheugenlek gaat. Mijn server draait CentOS 5.3/Plesk en host zo'n 300-domeinen. De 5-6 storingen van enkele minuten per week, beginnen storend te worden. Het probleem speelt inmiddels al bijna een maand.

Vroeger had ik maar 2GB aan swap-geheugen en toen was het probleem erger. Hoe dit kan snap ik alleen niet, want vroeger heeft deze server 18 maanden met 100% uptime gedraaid, totdat vorige maand de problemen begonnen. Het geheugen is alleen genoeg geweest en er zijn de laatste maanden geen extra sites bijgekomen. Ook snap ik niet waarom verhogen van het swap-geheugen van 2 naar 6GB ervoor zorgt, dat de services niet meer lang down zijn en alles sneller weer up is.

Gezien de OOM-killer actief bezig is tijdens storingen volgens /var/log/messages, verdenk ik een geheugenlek. Heb al een freelancer ingeschakeld, deze heeft alleen het swap-geheugen verhoogd. Verder is er nog weinig bekend geworden.

Het feit dat er momenteel al 452MB swapgeheugen in gebruik is, snap ik ook niet. Volgens mij hoort er pas geswapt te worden, nadat het normale geheugen vol zit. Op andere goed draaiende servers, is het swap-gebruik nihil en het normale geheugengebruik 100%, echter een redelijk gedeelte cached. Onderstaande free -m zijn overigens van 4:52 's nachts, terwijl er nu nauwelijks bezoekers zijn.

Probleemserver:

code:

[root@server06 ~]# free -m
             total       used       free     shared    buffers     cached
Mem:          3952       1420       2531          0         87        691
-/+ buffers/cache:        642       3310
Swap:         5890        452       5437
[root@server06 ~]#

Goed draaiende server:

code:

[root@server05 ~]# free -m
             total       used       free     shared    buffers     cached
Mem:          3952       3892         60          0        547        472
-/+ buffers/cache:       2872       1080
Swap:         1983          7       1976
[root@server05 ~]#

Indien meer gegevens gewenst zijn, hoor ik dat graag. Ben op zoek naar een goede oplossing voor de slechte performance van server06.

[Verwijderd]

Vanuitgaande dat er een lek is dan moet je eerst kijken waar dat lek zit.

Kijk rond (liefst een eind voor) de probleemperiode met top welk proces het probleem (=teveel geheugen gebruikt). Kun je die niet vinden dan kan het een kernel probleem zijn en daar kun je helemaal geen standaard oplossingen voor geven.

Als je erachter bent wat het probleem programma is, dan zul je het al haast iets als valgrind moeten draaien. Ik weet niet precies hoe nuttig dat is als je geen debug symbolen hebt (misschien dat er debug packages bestaan?) en als het een lek is wat pas optreed bij een bepaald gebruikerspatroon dan word het zeker moeilijk, want je kunt je applicatie om snelheids redenen niet permanent in valgrind laten draaien (maw het word traag).

Dan kun je een lijstje maken van de grootste lekken en hopen dat iemand je ergens kan helpen.

Ik moet zeggen dat programmas als valgrind gemaakt zijn voor programmeurs, dus het kan misschien een beetje raar over komen als je het niet kent. Gewoon even zoeken naar een tutorial als dat het geval is. Het gaat trouwens om de standaard memcheck tool.

[Rainmaker]

Ben blij dat je er in ieder geval achter bent dat het de OOM killer was

Met deze info, als je even kijkt naar de ps output van net voor de crash in
Hoge load op Linux traceren

lijkt het er toch sterk op alsof httpd inderdaad heel je geheugen voltrekt.

Hierdoor lijkt het toch sterk erop alsof er ergens een scripting error in 1 van de webpagina's zit die langzaam je geheugen vol laat lopen. Het feit dat meer swap dat uitstelt, bewijst dat eigenlijk.

Je zou toch een keer in de httpd_access logging moeten kijken welke site er verantwoordelijk voor zou kunnen zijn. Als je die site dan even naar een andere server verplaatst, en het probleem verplaatst zich mee, weet je het zeker.