Mailinglisten-Archive |
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