[lamp] crash webserver, geheugenlek?

[joostdiepenmaat]

Inmiddels bijna een week bezig met oplossen van een tamelijk frustrerend probleem.
Wat is het geval, we hebben een webserver (Debian Linux) met MySQL database van +/- 15GB erop.
Apache2 draait icm met de laatste stable van php5. De queries zijn allemaal kort en krachtig en duren max 1 sec.

Bij een tamelijk lage load (tot ongeveer 1000 hits per uur) gaat alles prima. Zodra het drukker wordt gebeurt er iets eigenaardigs. Onze website blijft razendsnel, maar er ontstaat een geheugenlek die na ff wat pittige load (3K per uur) aan de swap begint te snoepen. Net zo lang totdat het helemaal niet meer kan, mysql bij zichzelf denkt: bekijk het maar. En in het ergste geval is de ssh daemon zelfs van z'n stokkie gegaan.

Geheugen wordt dus niet meer vrijgegeven, ook terwijl er geen load is. De processlist van MySQL wordt steeds langer en langer. En uiteindelijk gaat het systeem down. Wanneer we apache tussentijds restarten (bijvoorbeeld iedere 30 min) houden we het wel ff vol (geheugen van apache wordt dan weer vrijgegeven).
Het lijkt er dus op dat er ergens tussen apache en php, of tussen apache en mysql iets behoorlijk verkeerd gaat. We hebben echt meer dan genoeg performance, maar plotseling is het afgelopen!

Systeem specs: Athlon 2400 XP
1 GB ram
Linux Debian 3.1

Geinstalleerde packages (van source gecompiled)
- MySQL 5.0.16
- Apache 2.0.55
- PHP 5.1.5

Iemand enig idee wat hier gaande is?

[Luqq]

kan je niet gewoon de apt packages installeren?

[Wirehead]

Zie je iets in:
-logs (daemon.log)?
-dmesg?

[GrooV]

Nou een database van 15GB is best heel erg groot, en ik kan me voorstellen dat je server die load niet aan kan aangezien een Athlon 2400+ geen echte server processor is en je toch echt beter af bent met een Opteron/Xeon configuratie als mysql server.

Maar dat zijn mijn 2 centen

[Gertjan]

GrooV schreef op woensdag 30 november 2005 @ 22:15:
Nou een database van 15GB is best heel erg groot, en ik kan me voorstellen dat je server die load niet aan kan aangezien een Athlon 2400+ geen echte server processor is en je toch echt beter af bent met een Opteron/Xeon configuratie als mysql server.

Ik denk niet dat dat echt van toepassing is. De TS zegt toch dat de website prima te bezoeken blijft, zelfs onder hogere load? Dat betekent volgens mij automatisch dat de server _dus_ snel genoeg is.

Ik kan zo niets bedenken wat de oorzaak hiervan is, klinkt inderdaad als een memleak. Maar inderdaad: waarom niet de apt-packages?

[joostdiepenmaat]

de apt packages zijn een optie. Maar het is onze voorkeur zeker niet.

Een zwaardere server is pure waanzin: de machine voldoet uitstekend.

[kmf]

wat is de connection time out van php en mysql? Misschien dat de een antwoord probeert te geven terwijl de ander al niet meer luistert? of omgekeerd?

[SyS_ErroR]

post een deel van je php.conf eens.... Ik vermoed dat het probleem daar in zit..

[joostdiepenmaat]

SyS_ErroR schreef op woensdag 30 november 2005 @ 23:00:
post een deel van je php.conf eens.... Ik vermoed dat het probleem daar in zit..

ik neem aan dat je php.ini bedoelt, ding is geheel standaard, geen wijzigingen.

[joostdiepenmaat]

athlonkmf schreef op woensdag 30 november 2005 @ 22:57:
wat is de connection time out van php en mysql? Misschien dat de een antwoord probeert te geven terwijl de ander al niet meer luistert? of omgekeerd?

Als ik het goed heb geeft php de resultsset van mysql gewoon vrij, dus dan zou het probleem niet moeten optreden.
Ik denk niet dat het een specifieke setting is, maar eerder een combi van packages.

[WHiZZi]

Misschien ook even om iets naar te kijken, hou het aantal processen van MySQL eens in de gaten (SHOW PROCESSES in de MySQL cli)

Zit er niet ergens een .php-file die een database connectie aanroept en niet meer afsluit of in een oneindige loop terecht komt ?

[igmar]

deepman schreef op woensdag 30 november 2005 @ 21:03:
Bij een tamelijk lage load (tot ongeveer 1000 hits per uur) gaat alles prima. Zodra het drukker wordt gebeurt er iets eigenaardigs. Onze website blijft razendsnel, maar er ontstaat een geheugenlek die na ff wat pittige load (3K per uur) aan de swap begint te snoepen. Net zo lang totdat het helemaal niet meer kan, mysql bij zichzelf denkt: bekijk het maar. En in het ergste geval is de ssh daemon zelfs van z'n stokkie gegaan.

Belangrijk is uit te vinden waar de lek zit. ps kan daar handig bij zijn, aangezien die het gebruik per proces kan weergeven. Verder : welke kernel draai je ?

Vreemd is dat het probleem pas bij een hoge load optreed : Een memleak zou dan ook moeten optreden bij een lagere load, tenzij het al door het OS wordt vrijgegeven. Ik zou in eerste instantie kijken naar PHP / Apache, MySQL is behoorlijk leak-free AFAIK.

[Verwijderd]

Kan het zijn dat het komt door de combinatie Debian 3.1 (da's de huidige 'stable') met de nieuwste versies van apache2/php/mysql en dat er wellicht een compatibiliteitsprobleem is met bijv. de oudere libs uit 'stable' ?

Is het een optie om als test een identieke server in te richten met Debian unstable waarin de versies van apache/php/mysql met de van de TS en dan te proberen of dit systeem ook geheugen lekt?

[Eijkb]

Het ligt mijn inziens niet aan distributie, php versie of mysql versie. Wij hebben de zelfde problemen op zwaardere machines (gedeelde webhost) welke soms vastlopen, waarbij ook SSH daemon vast loopt. Het betreft dan Fedora Core 1, 2 of 3 met Mysql 3 of 4 en php 4.3.* / 4.4.*.

[joostdiepenmaat]

Eijkb schreef op donderdag 01 december 2005 @ 12:00:
Het ligt mijn inziens niet aan distributie, php versie of mysql versie. Wij hebben de zelfde problemen op zwaardere machines (gedeelde webhost) welke soms vastlopen, waarbij ook SSH daemon vast loopt. Het betreft dan Fedora Core 1, 2 of 3 met Mysql 3 of 4 en php 4.3.* / 4.4.*.

Jep, in mijn zoektocht naar de oplossing ben ik idd mensen met een vergelijkbaar probleem tegengekomen, meestal gebruikmakend van fedora core 3. Er http://support.fogcreek.com/default.asp?fogbugz.4.7681.3 beschrijft ook iets dergelijks al ben ik absoluut niet zeker dat dit hetzelfde probleem is.

[koffiedrinker]

Als ik dit zo lees dan denk ik eerder dat Apache of MySQL ziet childs niet afschiet als ze niet meer nodig zijn. In httpd.conf kan je aanpassen hoeveel childs apache mag aanmaken en wanneer deze weer moeten worden afgeschoten.
Hier is te lezen hoe je in Apache Multi Processing Modules (MPM) instelt. De keuze van MPM belangrijk voor de prestatie van de server, dus lees dit even en doe er misschien je voordeel mee

Het zijn iig mijn 2 centen.

[Gertjan]

Hoe zien ps auxf en top eruit op het moment dat de problemen zich voordoen (even voordat de server onbruikbaar wordt dus ). Zie je bij ps bijvoorbeeld heel veel Apache-processen, of processen met buitenproportioneel geheugengebruik?

[HarmoniousVibe]

Wij hebben een zulksoorting probleem ook ooit gehad. Er waren toe exceptioneel veel apache processen, die elk zo'n 30MB slurpten. Na lang zoeken bleek de oorzaak bij awstats te liggen.