Apache CPU-Auslastung hoch, RAM-Verbrauch niedrig

R

RootDS

Registered User
Hallo!

Ich habe auf meinem Root-Server u.a. eine Domain die Zeitweise sehr stark besucht wird (z.B. nach Medienberichten). Ich verzweifel gerade ein bisschen daran, den Apache so zu konfigurieren, dass er auch großen Besucheranstürmen gewachsen ist. Ich habe nun schon viel zum Thema Apache-Tuning und -Konfiguration gelesen, nur irgendwie komme ich da nicht weiter. Mein Problem ist, dass egal was ich dem Apache für Einstellungen bei <IfModule mpm_prefork_module> verpasse, er verhält sich immer gleich. Ich habe zum testen das Paessler Web-Stress-Tool. Dazu beobachte ich via Nagios das Verhalten der CPU- und Speicherauslastung. Während nun die CPU-Auslastung bei einem Test merklich ansteigt, bleibt der Speicherverbrauch konstant niedrig. Ich war eigentlich der Meinung, bzw. habe ich das so gelesen, dass die Performance eines Apache Webservers primär vom RAM abhängt. An RAM soll es nicht mangeln. Woran kann es liegen, dass die CPU-Last schnell auf 99% steigt, der RAM-Verbrauch aber so um die 4% rumdümpelt?

Daten zum Server:
Intel Quad-Core Prozessor
4GB RAM

Debian Etch
PHP5 inkl. eAccelerator
Apache 2.2.3 (apache2-mpm-prefork)
Code: 
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 256
MaxRequestsPerChild 5000
</IfModule>

MOD: Bitte CODE Tags beutzen. Danke.
 
Last edited by a moderator:
RootDS said:
Woran kann es liegen, dass die CPU-Last schnell auf 99% steigt, der RAM-Verbrauch aber so um die 4% rumdümpelt?
Code: 
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 256
MaxRequestsPerChild 5000
</IfModule>
Click to expand...
Ich bin kein Profi, habe aber gerade auch Probleme auf dem Server, nur anderes rum :) Zu hohe RAM-Verbrauch.

Bei der Suche nach Apache-Tuning, habe ich folgendes rausgefunden:
Der RAM-Verbrauch hängt unter anderem von der Einstellung für MaxClients ab. Um den korrekten Wert hier zu ermitteln, sollte man folgendermaßen vorgehen:
1. Die durschnittliche Größe eines Apache-Prozesses feststellen mit:
Code: 
ps -ylC apache --sort:rss
2. Dem Apache zur Verfügung stehenden RAM ausrechnen, also alles abziehen, was auf dem Server noch RAM benötigt (Betriebssystem, Datenbank, Sendmail etc.)
3. Dann den zur Verfügung stehenden RAM durch die durschnittliche Größe des Apacheprozesse teilen, ergibt den optimalen Wert für MaxClients.

An einem Beispiel mit Deiner Serverkonfiguration:
durchschnittliche Größe eines Prozesses = 5 MB
zur Verfügung stehende RAM = 3000 MB
ergibt 600 MaxClients

Ich weiß nicht, ob die Formel 100%-ig stimmt, aber wenn Du gerade Benchmarktests durchführst, würde mich interessieren, ob sie etwas bringt.
 
Last edited by a moderator:
Ja, diese Formel habe ich auch schon gefunden.
Was wären denn sinnvolle Werte für MaxRequestsPerChild? Da finde ich im Internet sehr unterschiedliche Angaben.

Übrigens, in meinem Fall liegt das mit der CPU-Last an PHP. Rufe ich mit dem Web-Stress-Tool nur statische HTML-Dokumente auf, kommt der Prozessor auch bei mehreren tausend Zugriffen nicht ins schwitzen. Mache ich den gleichen Test mit aufrufen von dynamischen PHP-Dokumenten ist die CPU recht schnell am Anschlag. Wüßte jetzt nur nicht, wie man PHP weiter optimieren könnte. Letztendlich liegt es ja wohl bei den Skripten...
 
Debian Etch installiert bei Verwendung von Apache2 mit PHP5 automatisch das MPM-Prefork und nicht den MPM-Worker.
 
RootDS said:
Debian Etch installiert bei Verwendung von Apache2 mit PHP5 automatisch das MPM-Prefork und nicht den MPM-Worker.
Click to expand...
Jö, steht auch in Deiner Konfiguration oben. Sorry, muss wohl erst endgültig wach werden, bevor ich hier weiter poste :)
 
Das hier würde mir spontan als erste Maßnahme einfallen:

1. eaccelerator
2. "KeepAliveTimeout 3" kann helfen
3. "MaxRequestsPerChild 15000"
4. DB optimieren (query-cache, buffers, etc)
 
bajab said:
Das hier würde mir spontan als erste Maßnahme einfallen:

1. eaccelerator
2. "KeepAliveTimeout 3" kann helfen
3. "MaxRequestsPerChild 15000"
4. DB optimieren (query-cache, buffers, etc)
Click to expand...

eAccelarator ist schon installiert. KeepAliveTimeout steht bereits auf 2. MaxRequestsPerChild steht auf 0. Damit reguliert sich der Apache selbst. Werte anzugeben birgt die Gefahr, dass bei ungeeigneten Werten das System eher damit beschäftigt ist neue Kind-Prozesse zu erschaffen. DB-Optimierung kommt noch. Allerdings waren die Tests von Seiten ohne Datenbank-Zugriffe. Von daher kam die CPU-Last wohl rein von den Skripten.
 
das mit den MaxRequestsPerChild = 0 kann wohl problematisch sein. Testen
Dann kann man ja noch sehen, was server-status sagt.

Aber auch: Die Site ist wirklich gut besucht oder der php-code "gurkig"... ;)
 
RootDS said:
egal was ich dem Apache für Einstellungen bei <IfModule mpm_prefork_module> verpasse, er verhält sich immer gleich.
...
Während nun die CPU-Auslastung bei einem Test merklich ansteigt, bleibt der Speicherverbrauch konstant niedrig.
Click to expand...
Klingt so, als ob Du nicht den MPM-Prefork sondern den MPM-Worker nutzt.
Bitte nochmal ausführlich prüfen!

Woran kann es liegen, dass die CPU-Last schnell auf 99% steigt
Click to expand...
Wenn Du schon viel dazu gelesen hast, dann hast Du auch von mod_status gehört, oder?
Außerdem bleibt die Frage, ob wirklich Apache die CPU-Last erzeugt, oder ein anderes Programm, wie z.B. die Datenbank.

Einfach mal "top" mitlaufen lassen und evtl. ein Screenshot präsentieren.

Sonya* said:
ergibt 600 MaxClients
Click to expand...
Hierbei bitte aufpassen, daß MaxClients nicht größer sein darf als ServerLimit.
Dazu sollte vom Ram ausreichend Platz für andere Systeme zur Verfügung stehen.
Und wer 600 Request gleichzeitig abarbeiten kann, sollte auch rund 300 Datenbank-Connections annehmen können. Und das kostet ebenfalls nochmal richtig viel Speicher... :)

MaxRequestsPerChild steht auf 0. Damit reguliert sich der Apache selbst.
Click to expand...
Nein, eben nicht. Mit 0 werden die Childs nicht regelmäßig neu gestartet. Damit eine evtl. auftauchende RAM-Lücke ggf. mal geschlossen wird, empfiehlt sich ein Wert >1000.

Ich weiß nicht, ob Du beim rumschauen schon auf huschi.net warst. Aber da findest Du relativ viele Tipps und Erklärungen. Als Einstieg empfehle ich mal kurz den neuesten Artikel, da dort auch alle passenden Artikel mit verlinkt sind:
Server-Beobachtung - huschi.net

huschi.
 
Hi,

ich grabe ungern alte Threads aus, aber diese beschreibt leider auch genau mein Problem.

Vorweg das System:
CPU: 2x Intel® Xeon® X5570 2,93 GHz
Arbeitsspeicher: 24 GB
Betriebssytem: Debian Squeeze GNU/Linux 6.0.4 64Bit (2.6.32-5)
Webserver-Software: Apache 2.2.16
PHP: 5.3.3-7+squeeze8
MySQL: 5.1.49-3
Anbindung: 1 GBit
Click to expand...

Apache-Config
KeepAlive On
axKeepAliveRequests 200
KeepAliveTimeout 10
ServerLimit 4096
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 120
MaxSpareServers 4096
MaxClients 4096
MaxRequestsPerChild 0
</IfModule>
Click to expand...

Für den Lasttest nutze ich hier "TheGrinder3".
grinder.processes = 1
grinder.threads = 60
Click to expand...
TheGrinder3 ruft mit einem Prozess 3 Seiten meines PHP-Projekts auf.

Das Problem was sich nun herausstellt. ca 5GB Ram saugt sich Apache2 weg, was auch völlig legitim ist, da noch über 15GB davon verfügbar sind. Jedoch geht die CPU an Ihre Grenzen: Durchgehend während des Lasttests ist die CPU bei über 90%.

Anbei ein Screenshot.
vmstat liefert mir die gleichen Zahlen. Zum Monitoring wird auf der Virtualbox "PRTG" eingesetzt. Auch dieses sichert mir die 10% CPU free zu. Das seltsams an der Geschichte ist ja, dass vor ca. 2 Jahren, die gleichen Werten, die gleichen Tests, mit der gleichen Software, jedoch älteres OS bessere CPU werte brachte als heute.
Der Apache reagiert weiterhin in unter 100ms mit Antwortzeiten. Auf der Konsole können die Befehle ohne Probleme/Lags ausgeführt werden.

Könnte es am neuem Squeeze ggf. Kernel liegen, dass die CPU nun vom Apache so hochgetrieben wird. Oder ist es die Version vom Apache ?

Bin im Moment echt ratlos :( Hoffe hier findet sich jemand, der mir helfen könnte, das Problem zu beseitigen.
 

Attachments

  • cpu_load.png
    cpu_load.png
    43.5 KB · Views: 356
Last edited by a moderator:
Deine Aussage verwirrt mich...
DU jagst einen Benchmark auf deinen Webserver welcher nun vermutlich Datenbank-Verbindungen aufbauen darf, PHP-Skripte ablauft, und alles moegliche machen muss.
Und du wunderst dich nicht etwa ueber langsames Abarbeiten der Anfragen durch Apache sondern durch hohen Ressourcenverbrauch.

Sinn und Zweck eines Benchmarks ist es Hardware und Software an ihre Grenzen zu bringen um diese zu kennen und eventuelle Flaschenhaelse weg optimieren zu koennen. Dass dabei die Machine ans Limit kommt ist ja gewollt und nicht ein Nebeneffekt =)
 
d4f said:
Deine Aussage verwirrt mich...
....
Sinn und Zweck eines Benchmarks ist es Hardware und Software an ihre Grenzen zu bringen um diese zu kennen und eventuelle Flaschenhaelse weg optimieren zu koennen. Dass dabei die Machine ans Limit kommt ist ja gewollt und nicht ein Nebeneffekt =)
Click to expand...
Das ist mir bewusst und klar :)
Ich zitiere mich gerne mal
Das seltsams an der Geschichte ist ja, dass vor ca. 2 Jahren, die gleichen Werten, die gleichen Tests, mit der gleichen Software, jedoch älteres OS bessere CPU werte brachte als heute.
Click to expand...
Damalig hat sich die CPU gelangweilt, und wies ca. 90% idle auf.
Das ist dass, was mich heute so wundert und stutzig macht.
 
Eventuell zeigte er diesmal bedeutend hoehere Request-per-second Werte auf.
Es waere moeglich dass eine andere Systemkomponente (zB Festplatte) damals die Grenze darstellte.
 
Hardware ist unverändert.
Einzig OS wurde immer auf dem neusten Stand gehalten.
Frischte Installation Anfang des Jahres durchgeführt.

Ist ja nun nicht so, dass der Server(CPU) bereits nach 100 REquest in die Knie geht. Es handelt sich hierbei um einige Millionen.

Aber scheinbar ist es halt die Grenze, an die ich mich stand heute halten sollte :(
 
Die Anzahl der konsekutiven Requests ist mehr oder weniger irrelevant (nicht ganz da bei gleichbleibender Abfrage die Daten nach wenigen Requests bereits im Cache gelandet sind und somit die Festplatte wieder im Tiefschlaf liegt)
Die Anzahl gleichzeitiger Requests und die Anzahl an Requests per Seconds (es besteht eine Relation zwischen beiden) ist relevant.
Und das sind definitiv bei einem ueblichen Server keine "Millionen" =)
 
Naja Millionen pro Sekunde hatte ich damit auch nicht gemeint :)
Es sind derzeit 400 - 500 Requests pro Sekunde, an welche die CPU dann mit 90% wackelt.
Hochgerechnet, sind es dann über 1,5 Mil / Stunde. Hätte mich vlt. besser ausdrücken sollen (sorry).
 
Sooo,

nachdem wir hier ein wenig über die Werte etc. gesprochen haben, habe ich mir nochmals die alten Werte von damalig genauer angeschaut.

ich muss sagen, ich hatte in der damaligen Aufzeichnung leider einen Fehler produziert. Die CPU hatte laut PRTG nichts zu tun, dass richtig, allerdings war das ein Test, der nur ca. 70 Request/Sekunde auf einer Zeitschiene von 1 Std simuliert hatte :) Hatte das Ergebnis in der falschen Liste stehen.

Somit hab ich garkein Problem, nur falsche Aufzeichnungen :(

Schande über mein Haupt.
 
You must log in or register to reply here.
Back
Top