[apache] een specifieke thread uitpluizen

[killercow]

Ik heb een probleem

Op een productie server zie ik soms een of meerdere apache threads tot meer dan 100 meg aan ram op vreten, wat natuurlijk bij meer dan 10 van dat soort threads tot swapping tot gevolg heeft voor de andere threads.

Is er een manier om tijdens zo'n excesieve burst te achterhalen wat de specifieke apache thread aan het doen is door bijvoorbeeld de zoeken dmv het pid?

Ik heb natuurlijk al geprobeerd logging op verschillende nivo's aan te zetten en te tweaken, maar dit heeft het probleem nog niet boven wat gebracht.

[Kees]

%P ('The process ID of the child that serviced the request.') toevoegen aan je logging, en dan in je logs kijken naar welke files die thread als laatste heeft geserveerd en zien of je daar een patroon in kan ontdekken.

Dus bijvoorbeeld een logformat alla '%{%t}t %P %D %r' gebruiken (tijd in seconden - PID - tijd in ms die nodig was de request te serveren - eerste lijn van de request).

Je kan eventueel ook het probleem oplossen door apache threads eerder dood te laten gaan, in plaats van dat ze oneindig veel clients serveren kun je bijvoorbeeld een limit van 1000 erop zetten (na 1000 requests worden ze afgeschoten en start apache een nieuwe child op)

http://httpd.apache.org/docs/2.2/mod/mod_log_config.html
http://httpd.apache.org/d....html#maxrequestsperchild

[GX]

Je kan ook een bepaald bestand door apache laten genereren die per thread / request aangeeft wat ie aan het doen is.

Even direct uit onze developmentserver-config:

code:

<IfModule mod_status.c>
    ExtendedStatus On
    <Location /server-status>
        SetHandler server-status
    </Location>
</IfModule>

Locatie kan je natuurlijk aanpassen naar iets dat je interessanter vind

[smesjz]

Je kan verder eens kijken naar strace om op low-level te kijken wat ie aan het doen is, andere opties zijn evt. lsof waarbij je de output beperkt tot files die geopend zijn door je www-data/apache user.

Makkelijkste is als je met een core dump aan de slag kan. Je kan door de threads heen bladeren en binnen frames variabelen bekijken. Maar 100 meg aan RAM volgens ps aux kan ook een vertekend beeld op geven, met pmap zie je beter het onderscheid tussen proces specifiek geheugen en shared (zoals bijv php5.so). Hoe ziet bijv. je ps aux uitvoer er uit?

[igmar]

Hebben we het hier over echte threads of hebben we het over processen ? Da's wel een behoorlijk verschil, en geeft een hele andere discussie / oplossing.

[killercow]

Allereerst, bedankt voor de reacties,

Ik had de maxrequestsperchild al naar beneden geschroefd, en het lijkt nu allemaal wat stabieler te draaien, ik kom minder in de buurt van de max mem.

Nu zijn dat natuurlijk alleen maar lap middeltjes en wil ik toch graag uitvinden wat de echte probleem pagina's zijn

Server-status heb ik ondertussen aangezet, maar ik wacht nog op het probleem om zich voor te doen,

ik zie idd 100meg aan ram via top/ps,

ik heb op de server geen mods draaien met een shared ram achitectuur, het gaat trouwens om een 1.3 apache met php 4. trucjes als memcached etc gebruik ik verder nergens.

Ik kan goed zien dat het echt 100meg ram is doordat ik de server met 300meg vrij geheugen zag, en daarna een apache thread zie groeien van 11meg naar 110 meg, waarmee tegelijk de free mem counter in top zie afnemen van 300 naar 200 meg vrij.

Ik heb het over processen in apache die rond de 100meg gebruiken, en waarschijnlijk wordt dit getriggerd door een of andere foute thread hier binnen.

[igmar]

Apache 1.3 is niet threaded. Heb je een memory limit aan staan ? Zo nee, begin daar eens mee, dan kun je in ieder geval uitzoeken welk script de oorzaak is.