Mailinglisten-Archive |
Moin,moin Werner
bevor es nun Weiter geht die Frage ob man die Aapche Liste wechseln
sollte oder alles per PM macht. Der ein oder andere koennte es OT
finden.
Werner Stuerenburg schrieb:
>
> Hi Joerg!
>
> Langsam kommen wir der Sache näher.
>
> > Kannst du noch einmal angeben was du nun genau eingestellt hast?
> > Min/Max/Start usw. Servers.
>
> MinSpareServers 5
> MaxSpareServers 10
> StartServers 5
> MaxClients 100
> MaxRequestsPerChild 10
>
> Ich habe jetzt beobachtet, daß er bei 90 Prozessen definitiv absäuft. Ich
> glaube also nicht mehr an einen Programmfehler, wie der Typ mir weismachen
> will, der das für mich eingerichtet hat.
MaxClient gibt die max Anzahl laufender Apacheprozesse an.
if((MaxClients x Speicherverbrauch pro Prozess <= Ram in der Kiste) &&
(IO/Network == "very performant")) {
echo "Hurra wir leben noch und alles ist gut";
}
echo {
echo "Schieb Ram nach oder Dreh die Prozesse herunter";
}
Um es mal auf den Nenner zubringen. Bei dem Traffic von 70Gig ist 128 MB
zuwenig. Ausserdem ist der Apacheprocess zu 'Fett' aber siehe unten.
MaxRequestsPerChild bedeuted das jeder Apachechild x Anfragen eines
Clients beantwortet und danach sich selbst beendet (stirbt). Ist ganz
praktisch wenn man mit Speicherleaks zu kaempfen hat. 0 wuerde hier
eine unbegrenze Lebensdauer bedeuten. Dies ist glaube ich sogar der
default? macht aber nur Sinn wenn man weiss das alles glatt laeuft...
und das ist im unserem Fall ja *NOCH* nicht so.
> Ich habe jetzt erst mal
>
> MaxKeepAliveRequests
>
> von 0 auf 80 gesetzt, aber das war natürlich ein Denkfehler - das sind ja
> vermutlich eher 30 Prozesse, die der httpd hat, 80 sollten es insgesamt
> sein.
Der default Wert von 100 kann bei deinem sehr stark frequentierten
Server zuviel sein... herunter setzen war eine gute Idee.
Du kannst natuerlich den Startwert gleich so hoch setzten das er unter
der magischen Grenze deine Rams bleibt. Sieht dann waze komisch aus wenn
da Apacheprozesse rum idlen aber nix anderes hat KK in seinem Artikel ja
auch beschrieben.
Das sollte zumind verhindern das er sich zu tode swappt. Die Idee
mittels eines Shellscripts per Cron nach Zombies oder toten Apachechilds
zu suchen und die dann zu killen hatten wir schon , oder?
> Ich habe dazu noch
>
> MaxClients 30
>
> gesetzt und hoffe jetzt, daß die Sache jetzt nicht dauernd abgewürgt werden
> muß.
>
> Es klappt nicht gleich, ich drehe noch ein bißchen an den Werten.
>
> Es ist ganz klar, so von 19-21 Uhr war relative Ruhe, Abdnessen,
> Tagesschau, jetzt geht das vor dem Schlafengehen wieder los.
>
> > 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.
>
> Tja - ich habe gar nicht. Ist natürlich ein Fehler, sehe ich ein, aber ich
> kann mich nicht zerreißen. Ich habe jemanden gesucht, der mir das abnehmen
> kann, und auf php-center.de niemanden gefunden.
>
> KK konnte ich mir nicht leisten, da habe ich mich erinnert, daß mein
> Reseller das machen könnte - ja und so war das. Der Techniker hat offenbar
> ein solides Halbwissen, aber dafür doppeltes Selbstbewußtsein.
Gibts den die Moeglichkeit das selber Einrichten zukoennen oder mal auf
einem Parallelrechner testen zukoennen?
> Er hat jedenfalls Apache nicht so konfiguriert, wie wir das brauchen,
> sondern wie er das immer macht - z.B. mit Frontpage, und das auch noch
> schlecht - dort fehlt ein Verzeichnis, weshalb Apache meckert. Er dazu: das
> brauchen Sie doch sowieso nicht. (grrrrr!)
>
Haettest du denn die Moeglichkeit den Apache selber zukomplieren? Sorry
aber ich hab den Anfang nicht mitbekommen! Dedizierter Server ja/nein.
Eigene Kiste Root? Oder wie?
> DSO sagt mir gar nichts.
Dynamic Shared Object
http://www.apache.org/docs/dso.html
>
> loaded modules:
>
> mod_php4, mod_frontpage, mod_setenvif, mod_unique_id, mod_usertrack,
> mod_digest, mod_auth_db, mod_auth_dbm, mod_auth_anon, mod_auth, mod_access,
> mod_rewrite, mod_alias, mod_userdir, mod_actions, mod_imap, mod_asis,
> mod_cgi, mod_dir, mod_autoindex, mod_include, mod_status, mod_negotiation,
> mod_mime, mod_log_referer, mod_log_agent, mod_log_config, mod_env,
> mod_vhost_alias, http_core
>
> Was davon brauche ich? Ich brauche php und mySQL und mod_rewrite - sonst
> nichts. Was machen diese ganzen Module, was brauche ich davon?
Dieser Apache ist eindeutig zu Gross. Alles was man nicht braucht
muss/soll raus!! Was nicht drinn ist kann schon mal keine Fehler
verursachen... ist nun einmal eine eine Einfache Regel.
Eine minimal Installation kann so aussehen.
-mod_access
-mod_alias
-mod_auth
-mod_browser
-mod_dir
-mod_log_config
-mod_mime
+
mod_rewrite
Nun kann ich allerdings nicht sagen ob du das eine oder andere brauchst.
Wer den Referer mit ins log haben moechte brauch ein weiteres Modul
usw., usw. Was die Module so machen bzw. welche Funktionalitaet welches
Mod bereitstellt sagt eigentlich das Manual.
Dies ist ja einer der Vorteile wenn man wie untern beschrieben die DSO
Variante baut. Erst einmal alles rein... und dann ausdokumentieren.
Ausserdem ist dann ein update einzelner Mods (wie PHP z.b) kein Problem.
Bei der statischen Version muesste man halt immer der Apache komplett
neu machen.
> > Ein.
> > CFLAGS='-DBUFFERED_LOGS'
> > export CFLAGS
> > ./configure --prefix=/usr/local/apache --enable-module=all
> > --enable-shared=max
> > make
> > make install
>
> Das ist mir leider alles fremd.
>
> > 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.
>
> Im error.log steht nichts Signifikantes drin.
Dann ist die Variante was fuer dich... das bezieht sich aber nicht nur
auf das Errorlog sondern alle Logs. Und das ist es ja auch sinnvoll. Der
Apache protokolliert sich ja bei deinem Traffic fast zutode. Wie gross
sind eigentlich die Logs bei 70gig Traffic pro Monat?
> > 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.
>
> Ja, leider kann ich nicht. Ich brauche da dringend Hilfe. Vielleicht ist
> das kein Ding für die Mailingliste.
>
> > > 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/'.
>
> ?? Nix verstahn.
>
> > Evtl. mittels einer robots.txt den Zutritt verbieten. Haelt sich evtl.
> > nicht jede SE drann.. ist aber ein Anfang.
>
> Eigentlich ist man doch froh, wenn die kommen.
Mann koennte zumind. die cgi-bin/ images/ /geschuetzeBereiche/
ausklammern sollte ein bischen Entlastung bringen. Wenn sich einer der
Crawler doch daneben benimmt koenntest du ihn komplett vor die Tuer
setzten lassen gleich vom Apachen aus. - Richtiges Modul vorhanden
vorausgesetzt :)
>
> > > 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.
HTTP1.1 sei Dank. Bzw. KeepAlive und Persistant Verbindungen. Wie ich
schon oben schrieb ist ein sehr gutes Tool um Last zuerzeugen der
ApacheBenchmark. Das ist besser als 20X Refresh im Browser zudruecken.
Den Benchmark kannst du von jedem x-beliebigen Rechner ausstarten..
Generiert dann natuerlich auch den Traffic... anders als wenn du ihn auf
dem Webserver direkt startest... was aber bei einem Benmark ja unsinnig
waere.
> Wenn alles ruhig ist, geht es auch sehr schnell, wenn nicht gerade der
> lokale Provider Probleme hat.
>
> > ps: halt uns mal auf dem laufendem. Achja aktuell ist Apache 1.3.14 und
> > PHP4.0.3pl1
>
> Habe ich mitgekriegt. Ich habe den Einrichter darauf angesprochen, daß
> 4.0.2 laut KK genommen werden soll, während er 4.0.1 genommen hat. Er
> darauf: Quack! Da könnte man ja laufend neu bauen, ständig kämen neue
> Versionen heraus. 4.0.1. sei stabil und damit basta.
Ha,ha,ha typische Auasage eines Admins der gerade mal eine <?php
phpinfo(); ?> hinbekommt, wenn ueberhaupt! Aber garantiert nicht in PHP
entwickelt. Fakt es das es da nicht um zig neue Features geht sondern
teilweise im Sicherheitsrelevante Sachen. Im 12er Apache ist ein Bug im
mod_rewrite. Der 14er ist nicht umsonst gekommen.
KK spricht davon das ein Apache max. 2-2.5 MB haben soll. Man sollte
ihn aber noch bedeutend kleiner bekommen.
Gruss
Joerg Behrens
--
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