sslug-teknik team mailing list archive

[Anders Nielsen <anielsen@xxxxxxx>]

On Tue, 2002-10-08 at 15:45, Lars Lerager Hansen wrote:
> Anders Nielsen <anielsen@xxxxxxx> wrote:
> > Ok, fint... Der er i øvrigt også en grænse i bash som du bør have styr
> > på. Prøv at skrive ulimit -a og kig på "max user processes". Grænsen
> > kan afhænge af brugeren så du bør gøre det som den bruger der starter
> > apache.
> 
> Tjo, den står på 2015, så det er vist ikke problemet.


Ok... 

Denne grænse har engang bidt mig (den var lavere på redhat 6.x) så jeg
er meget opmærksom på den. I øvrigt afhænger den af hvordan man var
logget ind, da man i sin tid startede apache (restart ændrer ikke
grænsen). Et cgi-script der skriver "ulimit -a" skulle der til før jeg
opdagede problemet (ja jeg er stadig bitter) :-)



> > Kan du evt. prøve at beskrive hvordan "problemet" påvirker systemet.
> > Eventuelt bør du lave noget overvågning, der holder øje med antal
> > processer, trafik og RAM belastning.
> 
> Som om nogen har hældt sirup i maskinen :-)
> Apache-processer er 250+, trafikken er ~8 Mbit/s (taget fra MRTG) og den
> bruger meget RAM men swapper ikke.
> 


Ok... Det er swap forbruget der er interessant. Kernen vil som regel
altid udnytte alt RAM til buffere med mere. Så det ser ikke ud til at
være det der er problemet.

Et oplagt spørgsmål: Hvor stor båndbredden er til dine brugere? Hvis
trafikken skal gennem en 10 Mbit kanal er der ballade.

Prøv evt. "mii-tool -v" for at tjekke dit eget interface.
Autonegotiation kan nogen gange fucke op og give 10 Mbps selvom 100
eller mereburde være muligt.

Kan sirup-effekten også mærkes fra konsolen og hvad er load avg.??


> > Jeg læste at du har 34.5 mio hits om måneden, hvilket jo er den hel
> > del. Det kan tænkes at hardwaren er flaskehals. Kun du evt beskrive
> > hardwaren (RAM, CPUer, SCSI, NIC med mere). Hvilken distro bruger du?
> > Kunne også være sjovt at få at vide hvilken site der er tale om :-)
> 
> Ja, undskyld - det burde jeg selvfølgelig have skrevet.
> Redhat 7.2 på en 800Mhz PIII - et eller andet Asus bundkort med et onboard
> SiS NIC. Der køres software raid 1 på to Seagate Barracuda IV - 512 MB RAM.
> 

Ok... Klavs Klavsen mente at interruprs fra NICet kan give problemer.
Det bør du nok lige tjekke. Jeg har ikke så meget styr på interrupts -
måske Klavs vil uddybe. Prøv evt en: "watch cat /proc/interrupts".
Onboard NICs lyder for mig som "billige", men det er måske bare en
fordom.


> > Jeg kender ikke de tekniske detaljer om PHP, men hvis det er ligesom
> > mod_perl hvor apaches børneprocesser bliver store og fede RAM mæssigt,
> > så bør du prøve konfigurationen med den foranstillede server der
> > klarer det statiske indhold.
> 
> Det er også en model jeg hælder til - men der vil stadig være en del
> requests til Apache, for der er egentlig ikke ret meget grafik o.l på de
> sider vi viser. Men jeg tror ligesom dig at det handler om at få reduceret
> antallet af processer - desværre er det ikke rigtigt noget der ligger til
> Apache's arkitektur (ikke 1.3.x i hvert fald).


Lad mig forklare hvorfor jeg bruger denne model (ideen er fra mod_perl
manualen): 

Meget trafik betyder mange apache børn. Mod_perl betyder, at det enkelte
apache barn indeholder en slags cache af oversat perl kode, hvilket
betyder stort RAM forbrug per barn.

For at undgå mange store børn sættes en server med lette børn foran, som
håndterer statiske requests. De dynamiske requests proxyes til serveren
med de fede børn. Dermed får man mange lette børn, men færre fede børn.
En anden fordel er at de fede børn afleverer deres svar til et let barn
som så afleverer det til klienten. På den måde undgår de fede børn at
vente på langsomme klienter, og de kan straks gå i gang med at behandle
næste forespørgsel, hvilket også betyder at der skal færre fede børn til
at klare opgaverne.

Konklusionen er altså, at denne model _ikke_ giver færre processer i alt
(det er faktisk omvendt), men færre fede processer.

-- 
Anders Nielsen <anielsen@xxxxxxx>