Apache Childs lasten Speicher voll aus :(

[infomatrixx]

Hallo alle zusammen,
ich hab ein riesiges Problem und hoffe das man mir helfen kann....
Ich betreibe eine große Internetseite im Inet mit eigenem Server etc. Wir arbeiten momentan mit einem 1,2 Ghz Server, mit 256MB Ram. Das System ist Suse 9.1

Nun beobachte ich schon seit längerem, dass die 20 Apache Childs den ganzen Arbeitsspeicher auslasten (s. ps aux)

wwwrun 4771 0.5 4.7 61164 11868 ? S 12:35 0:01 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL
wwwrun 4846 0.1 4.8 61320 12104 ? S 12:37 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL
wwwrun 4939 0.0 4.4 60580 11108 ? S 12:39 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL
wwwrun 4940 0.8 4.5 60600 11244 ? S 12:39 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL
wwwrun 4942 0.0 4.3 60452 10880 ? S 12:39 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL
wwwrun 4947 1.2 4.7 61148 11832 ? S 12:39 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL
wwwrun 4952 0.5 4.8 61320 12108 ? S 12:39 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL
wwwrun 5036 0.0 4.4 60576 11140 ? S 12:41 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL
wwwrun 5037 0.0 4.4 60564 11084 ? S 12:41 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL
wwwrun 5038 0.0 4.4 60584 11100 ? S 12:41 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL
wwwrun 5039 0.0 5.4 63048 13496 ? S 12:41 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL
wwwrun 5040 0.0 4.2 60320 10628 ? S 12:42 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL
wwwrun 5041 0.0 5.4 63048 13504 ? S 12:42 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL
wwwrun 5063 0.0 4.3 60460 10840 ? S 12:42 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL
wwwrun 5095 0.0 4.2 60320 10624 ? S 12:44 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL
wwwrun 5096 0.0 4.2 60320 10624 ? S 12:44 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL
wwwrun 5097 0.0 4.2 60320 10624 ? S 12:44 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL
wwwrun 5099 0.0 4.2 60320 10624 ? S 12:44 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL
wwwrun 5101 0.0 4.2 60320 10624 ? S 12:44 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL
wwwrun 5105 0.0 4.2 60320 10572 ? S 12:44 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL

Das Command free gibt dabei folgendes aus

total used free shared buffers cached
Mem: 248356 225356 23000 0 6016 100340
-/+ buffers/cache: 119000 129356
Swap: 2048276 48932 1999344

Uptime liefert folgendes:

12:43pm up 99 days 21:29, 1 user, load average: 0.66, 0.57, 0.69

Meine Server Tuning Conf habe ich für Prefork.C wie folgt konfiguriert:

StartServers 20
MinSpareServers 10
MaxSpareServers 20
ServerLimit 256
MaxClients 200
MaxRequestsPerChild 0

Zudem läuft noch mod_rewrite, wenn das damit zusammen hängt ?!?



Vielleicht hat ja jemand eine Idee ....



Danke schon mal im vorraus.



Fabian

[superuser1]

Hi...

Ich betreibe eine große Internetseite

definiere groß - für mein Verständnis von groß reicht eine 1,2 Ghz Maschine mit 256 MB RAM im Leben nicht aus.

Bei Performanceproblemen würde ich auch mit einer etwas weniger mutigen prefork-Konfiguration ansetzen (und davon ausgehend langsam nach oben schrauben, falls nötig):

Code: Select all

<IfModule prefork.c>
StartServers         5
MinSpareServers      5
MaxSpareServers     10
MaxClients          40
MaxRequestsPerChild  0

Dazu das lesen:
http://www.rootforum.org/forum/viewtopic.php?t=33884

Allerdings ist deine CPU- sowie Speicherauslastung ja eher im gemütlichen Bereich, also wo liegt das Problem?

:roll:

[powie]

ich würde zuerst mal die access_logs studieren. Ich hatte das mal auf einer Maschine und dort hat sich dann eine DDOS Attacke geoutet..

[kawfy]

Code: Select all

StartServers 20
MinSpareServers 10
MaxSpareServers 20
ServerLimit 256
MaxClients 200
MaxRequestsPerChild 0

Ursache: die Apache-Prozesse blähen sich auf, weil sie speicherhungrige PHP-Skripte abarbeiten. Der benutzte Speicher wird nicht wieder freigegeben. Ein weiterer Nachteil von mod_php.

Lösungsvorschlag: "MaxRequestsPerChild" nicht auf 0 belassen. Versuche es mit 200. Prüfe die Speicherbelegung in 24 h nochmal und probiere evtl. andere Werte.

Bitte: gibt uns Bescheid, ob das geholfen hat. Benutze den tag "code" für Abschnitte aus Konfigurationsdateien :)

[infomatrixx]

also groß definiert ihr wahrscheinlich ein bisschen anders als ich =)
Ich rede von ca. 1000-3000 Besucher am Tag....
Also die Einstellungen habe ich wie folgt mal geändert und den apache neu gestartet

Code: Select all

<IfModule prefork.c> 
StartServers         5 
MinSpareServers      5 
MaxSpareServers     10 
MaxClients          40 
MaxRequestsPerChild  200

Was ich an der ganzen Sache nur interessant finde ist die Tatsache, das die Ausführungszeit des Skriptes immer so um die Ausführungszeit: 1-2 Sekunden liegt.

Schaut es euch doch mal an:

http://www.party-connexion.de

Woran erkenne ich denn eigentlich eine DDOS Attacke in den access_logs ?


Fabian

[Joe User]

Die Ausführungszeit ist für ein unoptimiertes Script auf dem System vollkommen OK. Was stört Dich daran? Komprimiere lieber die Bilder und optimiere das Script, statt den Apache (dessen Defaultwerte völlig ausreichen) zu vergewaltigen...

[infomatrixx]

hmmmm,
inwiefern meinst du optimieren ?
was mich bloß wundert ist das die ladezeit um ein vielfaches größer ist, als die ausführungszeit des scriptes.....

[Joe User]

<OT>
Die Ausführungszeit bestimmt lediglich die Zeit, welche der PHP-Interpreter (/usr/bin/php) benötigt, um den PHP-Code (file.php) zu verarbeiten. Der verarbeitete Code wird dann zur weiteren Verarbeitung an den Webserver übergeben und von diesem wiederum zur weiteren Verarbeitung an den Client (Browser) weitergereicht. Der Client muss sich nun alle Referenzen (Bilder/StyleSheets/JavaScripts/etc...) besorgen und auch diese verarbeiten, bevor das erwünschte Resultat auf das Display gezaubert werden kann. Diese Vorgänge benötigen ein vielfaches der Zeit, die der PHP-Interpreter zum Interpretieren des PHP-Codes benötigt.
</OT>

Durch das Komprimieren der Referenzen und dem Optimieren (DB-Queries vermeiden/Kompatibilitätscode und ünnötige Features entfernen/etc..) des PHP-Code, wird zwangsläufig auch die "Ladezeit" gesenkt...

HTH

[mausgreck]

Nun beobachte ich schon seit längerem, dass die 20 Apache Childs den ganzen Arbeitsspeicher auslasten

Nein, tun sie nicht. Du kannst die Werte nicht einfach zusammenzählen, da es sich dabei hauptsächlich um den gleichen Speicher handelt (libraries, code, ...).

Code: Select all

total used free shared buffers cached
Mem: 248356 225356 23000 0 6016 100340
-/+ buffers/cache: 119000 129356
Swap: 2048276 48932 1999344 

129MB "freier" Speicher bei 256MB RAM ist doch Vernünftig, oder?

Was ich an der ganzen Sache nur interessant finde ist die Tatsache, das die Ausführungszeit des Skriptes immer so um die Ausführungszeit: 1-2 Sekunden liegt.

Also ich bekomme mit "time wget" Werte um die 500ms.

[infomatrixx]

Code: Select all

total used free shared buffers cached
Mem: 248356 225356 23000 0 6016 100340
-/+ buffers/cache: 119000 129356
Swap: 2048276 48932 1999344 

129MB "freier" Speicher bei 256MB RAM ist doch Vernünftig, oder?

Für mich sind das ca. 23 MB oder guck ich falsch ?

MEM FREE = 23000


Sind 0,5 ms denn gut, oder ist das schlecht ?

Und was kann ich noch machen, um die Performance zu verbessern ?

[mausgreck]

Für mich sind das ca. 23 MB oder guck ich falsch ?

Yup, die zweite Zeile zählt.
Siehe z.B.: http://gentoo-wiki.com/FAQ_Linux_Memory_Management

Sind 0,5 ms denn gut, oder ist das schlecht ?

Ich würde sagen schlecht, aber es kommt natürlich auf die Komplexität der Seite an und es könnte auch an der Leitung liegen. Sehr gut sind <20ms.

Und was kann ich noch machen, um die Performance zu verbessern ?

Schritt 1 ist immer herauszufinden, warum es langsam ist. :) Kenn mich aber mit php zu wenig aus, um da Ratschläge zu geben... Interessant wäre mal ein lokales "time wget". Die Hauptverdächtigen, wie Joe User schon anmerkt, sind auf jeden Fall Datenbankzugriffe: um so mehr, um so schlechter. Wenn man an der Zahl/Komplexität der DB-Zugriffe nichts ändern kann, dann ist Cachen von ganzen Seiten oder auch nur von Teilen immer ein heißer Tipp.

[andreask2]

hmmmm,
inwiefern meinst du optimieren ?
was mich bloß wundert ist das die ladezeit um ein vielfaches größer ist, als die ausführungszeit des scriptes.....

Ist halt alles weit weg von optimal. Erstmal lädst Du bei einem Request nicht nur eine PHP-Datei, sonderrn der Browser sendet (und der Server verarbeitet) zig andere Requests (Bilder, JS, CSS, "Google-Ads"). Bei Dir ist es besonders schlimm mit Bildern. Dazu kommt dass Du die Bilder größer überträgst als sie anzuzeigen. Hat dann zur Folge das die Qualität schlechter ist, gleichzeitig der Traffic höher und die Ladezeit länger. Du sendest keine Caching-Header, so dass der Browser - egal wie oft er ein Bild schon aufgerufen hat - jedesmal erneut nachfragen muss, ob sich das Bild geändert hat (was ja vermutlich sehr unwahrscheinlich ist, wenn sich ein Bild ändert benenne es um).

Ich zitiere einfach mal von http://de.webmasterplan.com/cgi-local/r ... s=opt_load

Ladezeit-Analyse für:
http://www.party-connexion.de/
Ausgeführt am 22-4-05, 3.32 Uhr(GMT).

Anzahl der Elemente auf dieser Seite: 11
Seitengröße insgesamt (in Bytes): 115039
Theoretische Ladezeit bei Modem 28.8 kps (in Sek.): 31.96
Theoretische Ladezeit bei ISDN 64 kps (in Sek.): 14.38
Bewertung (nach Schulnoten): 6

oder auch

Ladezeit-Analyse für:
http://www.party-connexion.de/index.php?include=team
Ausgeführt am 22-4-05, 3.35 Uhr(GMT).

Anzahl der Elemente auf dieser Seite: 33
Seitengröße insgesamt (in Bytes): 518459
Theoretische Ladezeit bei Modem 28.8 kps (in Sek.): 144.02
Theoretische Ladezeit bei ISDN 64 kps (in Sek.): 64.81
Bewertung (nach Schulnoten): 6

Was ich als erstes mal machen würde sind folgende Dinge:
1. Bilder in der Größe speichern wie sie auch angezeigt werden
2. Bilder optimierern
3. Caching-Header für statische Inhalte senden (dann sendet der Browser nicht mal mehr einen Request)
4. Google-Kram rausschmeißen (das kostst oft auch ne Menge Ladezeit)
5. Reduziere die Anzahl der zusätzlich geladenen Resourcen auf ein Minimum (externe wie Google komplett abschaffen)
6. Wenn möglich die HTML-Ausgabe der Scripte Cachen und ohne PHP aufrufen

Ich kann Dir nur empfehlen mal in Ruhe den folgenden Artikel durchzulesen: http://aktuell.de.selfhtml.org/artikel/ ... index.html