Apache2 PHP Site - MaxClients-Limit erreichen - Diagnose?


7

Wir haben eine Site mit mäßigem Datenverkehr (ungefähr 20.000 Zugriffe pro Tag), auf der eine PHP / MySQL-App auf Apache 2.2, Ubuntu 9.10 Server, von einer Amazon EC2 c1.small-Instanz (1,7 GB RAM) ausgeführt wird.

Wir hatten Probleme mit der Website, die wiederholt nicht mehr reagierten. Als schmutzigen Hack habe ich MaxClients / ServerLimit auf 450 gesetzt.

<IfModule mpm_prefork_module>
KeepAlive           On
KeepAliveTimeout     7
StartServers          5
MinSpareServers       5
MaxSpareServers      10
MaxClients          450
ServerLimit         450
MaxRequestsPerChild   0
</IfModule>

Die Seite scheint länger zu dauern als zuvor, stirbt aber immer noch. Ich überprüfe die Liste der Prozesse, die ich habe (dritte Spalte ist physisches Mem, vierte Spalte ist virtuelle Größe):

xxxxxxxxx@domU-XXXXXXXXX:/etc/apache2$ ps -eo pid,user,rss,vsz,args | grep apache
 2333 root     11092  39084 /usr/sbin/apache2 -k start
 3704 www-data 11060  41292 /usr/sbin/apache2 -k start
 3826 www-data 10016  39844 /usr/sbin/apache2 -k start
 3954 www-data 11976  41612 /usr/sbin/apache2 -k start
 4061 www-data 11844  41668 /usr/sbin/apache2 -k start
 4064 www-data 10988  40676 /usr/sbin/apache2 -k start
 4084 www-data 11804  41428 /usr/sbin/apache2 -k start
 4086 www-data 10192  39828 /usr/sbin/apache2 -k start
 4099 www-data 11876  41748 /usr/sbin/apache2 -k start
 4100 www-data 10980  40668 /usr/sbin/apache2 -k start
 4102 www-data  8952  39724 /usr/sbin/apache2 -k start
 4107 www-data 11856  41860 /usr/sbin/apache2 -k start
 4108 www-data  9952  39604 /usr/sbin/apache2 -k start
 4109 www-data     0      0 [apache2] <defunct>
 4114 www-data  7172  39724 /usr/sbin/apache2 -k start
 4115 www-data 10968  40668 /usr/sbin/apache2 -k start
 4122 www-data 11888  41844 /usr/sbin/apache2 -k start
 4123 www-data 11584  41444 /usr/sbin/apache2 -k start
 4124 www-data  7036  39596 /usr/sbin/apache2 -k start
 4125 www-data  6744  39084 /usr/sbin/apache2 -k start
 4126 www-data  9532  39552 /usr/sbin/apache2 -k start
 4127 www-data 10112  39812 /usr/sbin/apache2 -k start
 4128 www-data  6600  39084 /usr/sbin/apache2 -k start
 4129 www-data  6736  39084 /usr/sbin/apache2 -k start
 4130 www-data  7004  39596 /usr/sbin/apache2 -k start
 4131 www-data  6740  39084 /usr/sbin/apache2 -k start
 4132 www-data 11616  41596 /usr/sbin/apache2 -k start
 4134 www-data  7024  39588 /usr/sbin/apache2 -k start
 4135 www-data 11808  41516 /usr/sbin/apache2 -k start
 4136 www-data  7008  39460 /usr/sbin/apache2 -k start
 4137 www-data  6988  39460 /usr/sbin/apache2 -k start
 4139 1003       796   3040 grep --color=auto apache
victorhooi@domU-12-31-39-02-B6-34:/etc/apache2$

Gibt es eine einfache Möglichkeit herauszufinden, was genau los ist? Mein Verständnis von Apaches Innereien ist nicht so gut, aber ich hätte gedacht, dass wir nicht so viele gleichzeitige Prozesse benötigen würden, um eine Seite wie diese mit dieser Art von Verkehr zu versorgen. Wir haben die App geerbt, daher wissen wir nicht viel über ihre Innenseiten, aber es ist eine ziemlich einfache CMS-Site, die einige Suchergebnisse zeigt. Ich hätte nicht gedacht, dass sie diese Art von Grunzen brauchen würde.

Ich bin gegen die Site gelaufen, ich hatte eine ziemlich schlechte Anfragerate (weit unter 50 pro Sekunde), aber das war möglicherweise meine schlechte Wahl der Einstellungen - viele dieser Anfragen schienen fehlzuschlagen.

Wo sollte ich nach Informationen über das Geschehen oder nach Tipps zur Fehlerbehebung suchen, die ich versuchen könnte?

Prost, Victor


Sie müssen erklären, wie Ihre Skripte funktionieren, welche Inhalte sie generieren, Beispiele für SQL-Abfragen usw. bereitstellen, bevor wir Ihnen etwas Interessantes mitteilen können. Auch dies scheint eine Frage für StackOverflow zu sein
Vladislav Rastrusny

Antworten:


2

450 Kinder mit einem RSS von jeweils ca. 10 MB haben mehr als 4 GB Speicherplatz. Mehr als genug, um Ihre c1.small-Instanz auszutauschen. Swapping ist für Apache-Server fast immer eine Abwärtsspirale.

Ich würde sagen, die nächsten Dinge, die ich überprüfen möchte, sind
: Erwähnt das Apache-Fehlerprotokoll
das Erreichen von maxclients ? Erwähnt dmesg oder / var / log / messages überhaupt den OOM-Killer? Ist
der Server-Austausch ? Ist
die Speichernutzung ? Wachstum langsam und stetig oder stachelig / schnell einsetzend

Die ersten beiden betrachten nur txt-Dateien. Das dritte können Sie cli machen, aber Diagramme helfen, und das vierte benötigen Sie Diagramme. Richten Sie den mod_status von apache ein (wahrscheinlich schon da, kommentieren Sie ihn einfach aus) und zeigen Sie mit munin / collectd / cacti darauf.

Wenn Sie bestätigen, dass die Ursache Speichererschöpfung und Austausch ist, können Sie von dort aus Tonnen tun. Zunächst einmal können Sie Ihre maxclients auf etwa 150 senken. Dadurch bleibt Platz für andere Dinge und den Dateisystem-Cache (MySQL hier? Wenn ja, lassen Sie mehr). RSS ist eine grobe Metrik, um so zu extrapolieren. Es ist einfach alles, was wir haben. Sobald Sie dies eingestellt haben, sehen Sie sich die Grafiken im Laufe der Zeit an und prüfen Sie, ob Sie Platz haben, um nach oben oder unten zu gehen. Von dort aus können Sie sich auf 1.) dünnere Apache-Kinder konzentrieren (weniger Module, straffen Sie die PHP-Konfiguration) 2.) Apache weniger tun lassen (Mischung aus CDN, alternativen http-Servern und http-Proxy-Optionen) 3.) upgrayyed $$$


1

Möglicherweise sind dauerhafte Verbindungen zu Ihrem Server mit einer langen Zeitüberschreitung geöffnet. Wenn weitere Clients weiterhin eine Verbindung herstellen, übernehmen sie immer mehr Apache-Prozesse. Bei dauerhaften Verbindungen kann jeder Client 1 (oder mehrere) Verbindungen zu Ihrem Server herstellen.

Weitere Informationen finden Sie hier: http://httpd.apache.org/docs/1.3/misc/perf-tuning.html


heya, <br/> Ich dachte, es könnte KeepAlive gewesen sein, aber wenn ich den "apache2ctl-Status" überprüfe, sind die meisten von ihnen normalerweise nicht in einem Ruhezustand. z Anfragen werden derzeit bearbeitet, 11 untätige Mitarbeiter. Siehe auch hier für frühere Status: <br /> ubuntuforums.org/showthread.php?t=1310139 <br /> Prost, Victor
victorhooi

Na gut, das hat total nicht funktioniert ... lol ... funktioniert <br /> nicht oder so? Hmm oder <br/>. Urgh ... Entschuldigung für diese Jungs. <br/> Gerade überprüft, "52 Anfragen werden derzeit bearbeitet, 4 untätige Mitarbeiter", also ist es immer noch meistens aktiv, denke ich. <br/> Gibt es noch etwas, das ich überprüfen kann, um sicherzugehen? Oder ich kann Keepalive ausschalten.
Victorhooi

1

Ich habe kürzlich eine Reihe von Tipps zur Leistungsoptimierung in http://www.anchor.com.au/hosting/dedicated/improving-server-capacity for work zusammengefasst. Es hat ziemlich gut für die Maschinen funktioniert, auf denen ich es kürzlich angewendet habe. Darüber hinaus habe ich einen ausführlicheren Artikel unter http://www.anchor.com.au/hosting/development/HuntingThePerformanceWumpus, der sich mit einem umfassenderen Problem der Maschinenleistung befasst, das möglicherweise nicht spezifisch für Apache ist Identifizieren, welche Komponente des Systems Probleme verursacht.


Wenn Sie MaxClients treffen, gehen Anfragen schneller ein, als Sie bearbeiten können. Es ist ein Leistungsproblem. 20.000 Treffer pro Tag geben ungefähr 4 Sekunden Zeit, um jede Anfrage zu bearbeiten, multipliziert mit der Anzahl der Apache-Kinder, die Sie haben. Selbst mit nur 10 Kindern sind das 40 Sekunden pro Anfrage. Ich vermute, dass jede Anfrage eine eindeutige Ressource erfordert und alle anderen Anfragen dahinter anstehen. MySQL ist wahrscheinlich ein Schuldiger. Suchen Sie im langsamen Abfrageprotokoll nach lock_time. Eine weitere Option ist, dass Sie große Dateien bereitstellen, deren Download einige Minuten dauert. Vielleicht ist es beides.
Ladadadada

1

Sie können auch versuchen, Apache anzuweisen, mit 50 Prozessen (StartServers 50) zu starten, damit beim Start nicht die gesamte Servererweiterungsroutine durchlaufen werden muss. Versuchen Sie auch, Ihre Max-Ersatzserver auf etwa 20 zu erhöhen, damit Threads ausgeführt werden Sterben Sie nicht ab, wenn Ihre Anfragen in Wellen kommen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.