phpbar.de logo

Mailinglisten-Archive

[php] Hilfe bei Apache/Linux

[php] Hilfe bei Apache/Linux

Joerg Behrens behrens_(at)_takenet.de
Mon, 16 Oct 2000 20:29:47 +0200


Werner Stuerenburg schrieb:
> 
> Hi Andreas,
> 
> ich muß doch noch mal nachfragen:
> 
> > ... wieviel Speicher hat die Kiste denn?
> > Wenn ich die top-Ausgabe unten richtig deute, nur 128 MB?
> 
> Genau.
> 
> > > Die Einstellungen sind im Moment
> > >       MinSpareServers 300
> > ... das sind dann mind. 300 Apache-Prozesse, die jeweils
> > knapp 5,5 MByte gross sind. 300 * 5,5 MByte macht dann ca.
> > 1,5 Gigabyte ...
> 
> 5,5 MB pro process? Ist das nicht ein bißchen happig?

Kannst du noch einmal angeben was du nun genau eingestellt hast?
Min/Max/Start usw. Servers.
Was hast du denn alles in dein Apache/PHP 'geballert' sprich kompiliert
das er so gross wird. Ich weil leider nicht ob die DSO gegenueber der
statischen Variante Speichertechnisch irgendwelche Nachteile hat (ausser
das sie langsamer ist). Falls nein baue ihn mal als DSO.

Ein.
CFLAGS='-DBUFFERED_LOGS'
export CFLAGS
./configure --prefix=/usr/local/apache --enable-module=all
--enable-shared=max
make
make install

reicht da ja schon. Die 'BUFFERED_LOGS' sorgen dafuer das er die
Eintrage fuer Logfiles zwischen speichert und und in schueben auf die
Platte schreibt. Fuer Leute mit viel Traffic und ohne SCSI Raid eine
Alternative. Erschwert aber in den Anfangsstunden die Suche nach
Fehlern.. weil halt das error.log halt nicht sofort geschrieben wird.

Nun kannst du alle nicht benoetigten Module erst einmal
ausdokumentieren. Die sollte den Speicherverbrauch reduzieren.
Allerdings ist ist das groesste Modul von allen PHP. Gerade die
Datenbankmodule schlagen hier richitg zubuche.

Hier heisst es also sich auf das noetigste zubeschraenken. Dank DSO
laesst sich ja ein PHP in 2 bis 3 Minuten bauen.  So koenntest du mit
verschiedenen Modulen testen bzw. ein update auf PHP4.0.3pl1 geht ganz
fix. Evtl. bringt es auch etwas ganz selten benoetigte Module als Shared
object zuuebersetzten und dann zur Laufzeit einzubinden.

> 
> Dann kamen mir Bedenken - vielleicht war das in Ordnung? Vom alten Host
> weiß ich, daß regelmäßig User wahnsinnig lange drin waren, und habe
> geschlossen, daß das wohl SE waren, die sich alles gezogen haben. Fireball
> und Google z.B. habe Tausende von Seiten indiziert.

Als ein schlecht programmierter Robot kann die theoretisch den Sever zu
tode 'requesten'. Das selbe kannst du aber auch machen in dem du den
Apache-benchark aus dem bin-Verzeichnis mal nach 'ab -n1000 c5
http://loaclhost/'.

Evtl. mittels einer robots.txt den Zutritt verbieten. Haelt sich evtl.
nicht jede SE drann.. ist aber ein Anfang.

> Kann man im Protokoll vielleicht auch nachvollziehen: wenn eine IP in
> derselben Minute 5 Bestellformulare für Bücher aufzieht - das kann nicht
> ein Besucher sein, und 5 mit derselben IP von AOL?

Wieso das denn nicht? Bei uns rauschen 2000 Anwender mit der selben IP
draussen rum. NAT machts moeglich. Sollte bei den richtigen grossen auch
nicht anders sein. Wo bei die ja noch innerhalb einer Surfsession die IP
wechseln koennen.

 
> Wenn ich nun einen Test mache und eine Seite aufziehe, die deutlich lange
> braucht, bis der Browser alles geladen hat - die sehe ich in top praktisch
> gar nicht, so schnell geht das. Genauso mit mysql - ist normalerweise nicht
> zu sehen, obwohl jede Seite mehrfach die db befragt.

Liegt die Datenbank mit auf dem Rechner? Da kann man natuerlich ueber
Sockets sparsame/schnelle Verbindungen hinbekommen aber die DB braucht
ja auch Speicher. Unter Umstaenden ist hier ein dedizierter DB Server
eine Alternative.

 
> Ich habe auch schon 20 x refresh gemacht, ohne daß was passierte. Wenn der
> aber mit den Prozessen hochgeht (normal 65-70 jetzt) und auf 80, 90 100
> kommt, ist es zu spät, dann geht der in den swap und erholt sich nicht
> mehr.

Ein swappender Webserver ist ein 'schlechter' Webserver.

 
> Im Moment hat er z.B. 65 Prozesse und 85000 used. Es ist nichts los, so
> etwa 1 httpd pro Sekunde.
> 
> Wie muß ich das verstehen: wenn ich eine Seite aufrufe, sind das ja mehrere
> hits. Der macht also nicht für jeden hit/request einen Prozeß auf? Was
> passiert, wenn eine SE saugt? Braucht die einen Haufen Prozesse oder macht
> die das mit einem ab, der eben lange läuft?
> 
> Jetzt habe ich z.B. ziemliche Ruhe, vielleicht 1 httpd pro 2 Sekunden, 67
> Prozesse und 124 K used - da ist der schon fast an der Grenze. Was ist da
> los? Haben wir einfach zu wenig Memory?
> 
> Jetzt ist er runter auf 61 Prozesse und 105000, jetzt bei 68 und 120000 -
> ich beobachte das jetzt mit top normal (alle 5 sec) und sehe keinen
> direkten Zusammenhang - dieselbe Anzahl Prozesse kann unterschiedlichen
> Speicher benötigen.
> 
> Aber klar ist, daß der vermutlich so bei 75 Prozessen Probleme kriegt. Ich
> habe keinen Prozeß mit Status D, entweder sind die Running oder Idle. Jetzt
> baut der wieder ab, ist bei 66 / 110000. Load average ist übrigens
> 0,05/0,33/0,76
> 
> Hat jemand Erfahrung damit?

Also die Load ist ja laecherlich ;) Wobei 128MB fuer einen Webserver nun
auch nicht gerade uebermaessig viel ist.  Hast du wirklich soviele
Requests das du soviele Apachechilds brauchst? Kann das erzeugte HTML
ueberhaupt  uber deine Netzwerkanbindung abfliessen. Wenn du nur mit 2Mb
drann haengst ist das schon mal ein Flaschenhals.

Gruss
Joerg Behrens 

ps: halt uns mal auf dem laufendem. Achja aktuell ist Apache 1.3.14 und
PHP4.0.3pl1

-- 
Key fingerprint =  92 7D E0 A6 CF AE EC 32  14 28 EF 0D 57 2A 88 5B
----------------------------------------------------------------------
TakeNet GmbH					Mobil: 0171/60 57 963			
D-97080 Wuerzburg				Tel: +49 931 903-2243				
Alfred-Nobel-Straße 20				Fax: +49 931 903-3025


php::bar PHP Wiki   -   Listenarchive