[Apache] Zeer hoog geheugengebruik

[Verwijderd]

Ik heb net een nieuwe installatie gedaan van Slackware 8.1
alles draait naar behoren alleen heeft apache maar besloten om 250+ mb's geheugen in beslag te nemen...

Ik weet van mijn vorige bakkie dat dit niet echt normaal is..

iemand die weet wat ik er aan kan doen

code:

19597 nobody 75792 kB /usr/sbin/httpd 
19598 nobody 74220 kB /usr/sbin/httpd 
19599 nobody 74184 kB /usr/sbin/httpd 
19639 nobody 74184 kB /usr/sbin/httpd 
19638 nobody 74184 kB /usr/sbin/httpd 
19637 nobody 74184 kB /usr/sbin/httpd 
19601 nobody 74184 kB /usr/sbin/httpd 
19600 nobody 74184 kB /usr/sbin/httpd

edit:
Apache/1.3.26

[sebas]

je kunt je httpd.conf editen en

code:

MinSpareServers 2
MaxSpareServers 4
[...]
StartServers 2

(of iets anders redelijks)

Dat is het aantal httpds (child's die als nobody draaien) wat opgestart wordt en (en blijft draaien) om op requests te wachten.

Wat je trouwens ziet is trouwens volgens mij shared mem, en telt dus maar een keer. Hoeveel mem zit er in je bak en kom je ueberhaupt geheugen tekort?

[Verwijderd]

Nee ik kom niks te kort maar het viel gewoon op dat he zoveel was..
op mijn vorige webserverbak had ik dit niet (slack 8.0)

deze bak heeft 320 mb ECC SDRAM

[sebas]

Maakt weinig uit, het is hoogstwaarschijnlijk toch shared memory.

[Verwijderd]

ik begin me toch echt af te vragen wat het probleem is.. tis denk ik geen shared memory want hij geeft niks vrij bij als ik het ergens anders nodig ben.

ik ben nu wat files aan het copyeren naar m'n server en het geheugengebruik is 99 % (4,42 mb vrij)

Het vreemde is ook dat mijn swap bijna niks over neemt ( 1.88 mb in gebruik)

[terrapin]

Ik denk dat je gewoon niet goed kijkt, en het geheugen gebruik heel erg meevalt. De output van programma's als free e.d. is nogal lastig te interpreteren als je niet weet waar je naar moet kijken

Ik denk dat er gewoon totaal niks aan de hand is.
(ik dacht trouwens dat het geheugengebruik van apache er op mijn bak ook zo uitziet)
Niks om je zorgen over te maken, zeker aangezien je swap leegblijft..

[deadinspace]

Extra apache processes nemen maar zeer weinig geheugen in (niet door shared mem, maar door iets anders, zeg maar als ik het uit moet leggen).
Ik vind 75 MB voor een apache process wel nogal veel eigenlijk... Post eens de output van " ps auxf | egrep '(USER|httpd)' " (in code tags graag).

Verwijderd schreef op 12 oktober 2002 @ 23:19:
ik ben nu wat files aan het copyeren naar m'n server en het geheugengebruik is 99 % (4,42 mb vrij)

Post eens de output van " free -m ". 99 tegen 1 dat je cache en buffers meetelt.

[terrapin]

Lijkt me normaal... Ik heb in ieder geval precies hetzelfde.. (debian testing/unstable, apache 1.3.26)

code:

kai@sentinel:~$ ps aux|grep apache
root       544  0.0  0.3 75364  844 ?        S    Oct11   0:00 /usr/sbin/apache
www-data 21009  0.0  1.3 75724 2968 ?        S    Oct11   0:04 /usr/sbin/apache
www-data  5792  0.0  1.2 75788 2736 ?        S    Oct11   0:03 /usr/sbin/apache
www-data 26856  0.0  1.3 75428 3128 ?        S    17:27   0:00 /usr/sbin/apache
www-data 27323  0.0  1.3 75428 3128 ?        S    17:31   0:00 /usr/sbin/apache
www-data 27924  0.0  1.5 75540 3536 ?        S    17:39   0:00 /usr/sbin/apache
www-data 10016  0.0  1.6 75624 3656 ?        S    20:11   0:00 /usr/sbin/apache
www-data 22280  0.0  1.4 75428 3152 ?        S    22:21   0:00 /usr/sbin/apache
www-data 22282  0.0  1.4 75428 3140 ?        S    22:21   0:00 /usr/sbin/apache
www-data 22283  0.0  1.3 75428 3136 ?        S    22:21   0:00 /usr/sbin/apache
www-data 22286  0.0  1.3 75428 3124 ?        S    22:21   0:00 /usr/sbin/apache

[Verwijderd]

code:

USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
root     20476  0.0  1.2 74160 4044 ?        S    21:26   0:00 /usr/sbin/httpd
nobody   20477  0.0  1.8 75844 5816 ?        S    21:26   0:01  \_ /usr/sbin/htt
pd
nobody   20478  0.0  1.8 75844 5816 ?        S    21:26   0:04  \_ /usr/sbin/htt
pd
nobody   20484  0.0  1.7 75584 5564 ?        S    21:26   0:02  \_ /usr/sbin/htt
pd
nobody   20511  0.0  1.8 75884 5816 ?        S    21:28   0:01  \_ /usr/sbin/htt
pd
nobody   22997  0.0  1.2 74184 4072 ?        S    23:33   0:00  \_ /usr/sbin/htt
pd
root     23015  0.0  0.1  1400  460 pts/1    S    23:33   0:00          \_ egrep
 (USER|httpd)

code:

             total       used       free     shared    buffers     cached
Mem:           309        303          6          0          6        234
-/+ buffers/cache:         62        247
Swap:         2047          2       2045

Dit krijg ik eruit

[deadinspace]

Ah, er staat een meg of 75 bij VSZ. VSZ is -afaik- het totaal aan addressable memory space die een programma gebruikt, maarvan kan een groot deel niet-bestaand geheugen zijn, voor bijvoorbeeld mmap() operaties.
Voor het fysieke geheugengebruik moet je naar de RSS kolom kijken: een meg of 5 à 6, een veel gezondere waarde.

En wat betreft je free output:
309 is de totale hoeveelheid beschikbaar geheugen, verdeeld in 303 gebruikt en 6 vrij.
Maar bij die 303 MB gebruikt geheugen zijn ook de kernel buffers en cache meegeteld. De Linux kernel cached en buffert disk I/O, wat goed is voor de performance. Bij veel disk I/O kunnen die caches behoorlijk groot worden en al het geheugen dat niet in gebruik is door programma's vullen.

Om te zien hoeveel MB in gebruik is door programma's (dus excl. buffers en cache) moet je naar "used" in de tweede regel kijken: 62 MB.

[sebas]

deadinspace schreef op 12 oktober 2002 @ 23:31:
Extra apache processes nemen maar zeer weinig geheugen in (niet door shared mem, maar door iets anders, zeg maar als ik het uit moet leggen).
[...]

bij deze dus, ik vind het wel interessant. Of bedoel je hetgeen je in je laatste reply al uitlegde?

[deadinspace]

Apache werkt als volgt: het main process start. Als het main process - die op poort 80 luistert - een connectie krijgt dan start apache hiervoor een nieuw process die die connectie afhandelt. **
Het starten van zo'n nieuw process doet apache (en elk ander programma) met de systemcall fork(). fork() maakt een exacte kopie van een process (met verschillende returnwaarden voor parent en child, zodat de processes later weten wie wie is). Als het parent process van Apache 5 MB is zou elke fork() je dus 5 MB geheugen kosten.

Maar de Linux (bij andere kernels kan het dus anders zijn) implementatie van fork() gebruikt een feature van protected mode CPUs om dit geheugengebruik drastisch te verminderen. Op het moment dat een process fork()t blijven zowel de child als de parent hetzelfde geheugen gebruiken. De initiele geheugenkosten voor een fork() zijn dus alleen die van de nieuwe kernel task structure, page map en dat soort dingen.

Dit gaat natuurlijk grondig fout op het moment dat het parent process een variabele wijzigt; deze variabele zou dan in de child ook wijzigen. Daarom worden alle pages die door het parent en child process gedeeld worden gemarked als "copy-on-write". Op het moment dat een van de twee processes dus iets wijzigt in zijn geheugen wordt de page (geheugen segmentje) waar dat geheugen in valt gedupliceerd en krijgt elk process zijn eigen page, waar naar hartelust in geschreven mag worden, terwijl de overige pages nog gedeeld blijven tussen beide processen (en uiteraard copy-on-write gemarked blijven).

Grote delen van een process zijn code (programma zelf dus) en zijn read-only. Deze kunnen dus oneindig lang gedeeld blijven. Van de data zijn er ook vaak redelijke delen die niet veranderen, dus deze kunnen ook gedeeld blijven. De stukken data die wel veranderd worden (programma-variabelen, nieuw gealloceerd geheugen, stack) moeten dus wel gedupliceerd worden, maar dit is meestal maar een klein deel van het programma.

Stel dat er bij een gemiddeld Apache process ongeveer een halve MB aan pages read-write gebruikt worden... Dan kost elk nieuw Apache process je ongeveer een halve MB, itt de 5 MB (bijv) die elk process zou kosten als deze techniek niet gebruikt werd.

** Niet helemaal... Apache maakt gebruik van een pre-forking model. Dat houdt in dat er van te voren al childs worden geforked, om zo nieuwe connecties onmiddelijk te woord te kunnen staan. Maar dat doet verder weinig af aan de uitleg hierboven.

[sebas]

wow, respect deadinspace. +1 informatief

Een deel ervan was me al bekend, maar vooral hoe dat sharen van het geheugen afloopt en het inplementeren van de permissies had ik nog niet zo goed bekeken. Dankjewel voor het uitleggen!

Begrijp ik het dan goed dat het parentprocess bij voorbaat bepaald welke delen gedupliceerd moeten worden, en er dus door de child processen nooit nooit direct een parent process beinvloed kan worden. 'omzeil' je dit dan door d.m.v. een bufferoverflow bijvoorbeeld naar andere delen van het geheugen te schrijven?

[deadinspace]

Nee, de processes zelf hebben er geen idee van dat dit gebeurt, en het gebeurt echt on-the-fly.

In protected mode is je geheugen verdeeld in 'pages' (standaard 4 kb groot op i386). Elk programma heeft zijn eigen adresruimte (op i386 4GB), en pages uit de adresruimte van programma's kunnen naar willekeurige fysieke pages in je RAM wijzen (de MMU, Memory Management Unit, van je CPU vertaalt dit soort dingen naar de juist adressen).

Als een process geforked is wijzen alle pages van de adresruimte van beide processes dus naar dezelfde pages in je fysieke ram.
Ik weet niet 100% zeker hoe het geimplementeerd is, maar ik neem aan dat de kernel al die pages op read-only zet en onthoudt dat die pages copy-on-write moeten zijn. Als een van beide processes dan probeert te schrijven naar wat geheugen dan genereert de MMU een interrupt (segmentation violation). De kernel interrupt handler krijgt dat interrupt binnen en kijkt wat er aan de hand is.

De kernel ziet dat het gaat om een write naar een read-only page, en dat die page als copy-on-write bedoeld was. De kernel regelt een vrije (fysieke) page geheugen en kopieert de inhoud van de oude fysieke page naar de nieuwe fysieke page. Nu zijn er dus twee fysieke pages met dezelfde inhoud.
Dan zorgt de kernel ervoor dat de virtuele page waar het om ging van het process dat wilde schrijven naar die nieuwe fysieke page wijst. Nu hebben beiden processes voor de page waar het om ging dus ieder een eigen stukje fysiek ram, terwijl de overige pages nog gedeeld worden.
De twee pages die niet meer gedeeld worden (eentje voor de parent, eentje voor de child) hoeven niet langer read-only te zijn, dus de kernel zet die op read-write. De kernel returnt dan van zijn interrupt, en het process dat wilde schrijven naar zijn geheugen gaat gewoon verder waar het gebleven was - bij de schrijfopdracht.
Het process is dus verder niet op de hoogte van die page-stoelendans die de kernel uitvoert, voor het process is het gewoon een stukje geheugen waarvan gelezen kan worden en waarnaar geschreven kan worden.

[Verwijderd]

Dank voor alle uitleg !