Wie kann ich verhindern, dass Apache umfällt?


8

Ich habe zwei Server, auf denen eine einzelne Magento-E-Commerce-Website mit mäßigem Datenverkehr gehostet wird (60.000 Seitenaufrufe pro Tag, die von Google Analytics gemeldet wurden, ich denke, etwa 80.000 wurden auf dem Server selbst gemeldet). Der Datenbankserver läuft reibungslos und schnell, abgesehen von einem seltenen gelegentlichen Schluckauf, aber der Apache-Server ist von Zeit zu Zeit umgefallen.

Ich habe magento so eingerichtet, dass es das empfohlene PHP-Caching (APC) verwendet und seine eigenen Cache-Dateien in einem 1,5-Gig-tmpfs enthält (dieses tmpfs wird regelmäßig ziemlich voll, und ich habe ein Skript zum Löschen von Cache-Dateien, wenn das tmpfs ist mehr als 80% voll). Ich bediene die meisten Bilder von Amazon Cloudfront. Ich habe kürzlich nginx als Reverse-Proxy für Apache eingerichtet (nginx dient auch den statischen Dateien). Ich habe Apache nach besten Kräften konfiguriert - Keepalives und Hostnamelookups sind deaktiviert, und die Prefork ist wie folgt konfiguriert:

<IfModule prefork.c>
    StartServers      50
    MinSpareServers   50
    MaxSpareServers  100
    ServerLimit  512
    MaxClients   256
    MaxRequestsPerChild 400
</IfModule>

Ich habe .htaccess-Dateien nicht deaktiviert und die Zugriffsprotokollierung ist aktiviert. Ich weiß, dass es einige Module gibt, die ich ausschalten kann. Ich bin mir nicht sicher, welche Auswirkungen diese drei Änderungen haben würden, wenn überhaupt.

Der Apache-Server ist ein VPS mit 6 Gig RAM. Zum Zeitpunkt des Schreibens meldet der Server load average: 17.77, 18.27, 49.76, aber es sind ungefähr 2 Gig RAM frei. Wenn es wirklich schlecht wird, geht die Last auf 120+ und bleibt dort - ein Neustart von Apache bringt die Site wieder hoch und die Last wieder runter.

vmstatist (während der Server die Last oben meldet), denke ich, zeigt einen CPU-Leerlaufwert, der zwischen 0 und 70 oder so schwankt. iostatzeigt einen iowait-Wert zwischen 0 und 0,2%.

Ich stecke ein bisschen fest. Das Wenige, das ich weiß, sagt mir, dass das Problem darin besteht, dass die CPU aufgrund der Kombination des ausgeführten Codes und der Anzahl der Benutzer überlastet ist. Aber ich bin nicht erfahren genug, um sicher zu sein, dass das das Problem ist. Wenn dies das Problem ist, besteht die Lösung meines Erachtens darin, entweder den Code zu verbessern oder das Site-Hosting mit einem Load Balancer auf zwei VPS aufzuteilen.

Ich denke also, meine Fragen sind:

  1. Was kann ich noch tun, um Probleme oder Engpässe auf dem Server zu finden?
  2. Gibt es offensichtliche Änderungen, die ich an der Serverkonfiguration vornehmen kann, um dies zu verbessern?
  3. Ist es eine gute Idee, ein automatisiertes System so einzustellen, dass Apache neu gestartet wird, wenn die Last ein bestimmtes Niveau überschreitet?
  4. Wie wahrscheinlich ist es, dass die Site dem Server entwachsen ist?

Bearbeiten:

Ich fand etwas Seltsames - / var / spool / mail / root war groß ... 38 Gig. Das klingt ... ungesund. Könnte das das Problem sein?


2
38 GB Mail? Finden Sie heraus, was dort los ist. Und dann beheben Sie es.
Alister Bulman

2
" Wie kann ich verhindern, dass Apache umfällt? " - Geben Sie ihm ein Holzbein und halten Sie ihn von der Planke fern.
Shaz

Mailfile ist wahrscheinlich auf die Ausgabe von Root-Cron- oder Crontab-Fehlern zurückzuführen. Wenn Sie gesprächige Jobs haben, füllen sie diese Datei aus.
Kyle Smith

1
Es hat 6 GB RAM, aber ist es ein 64-Bit-Betriebssystem? Können Sie tatsächlich mehr als die 4 GB verwenden, die Sie derzeit verwenden? Wenn dies eine geschäftskritische Box ist, würde ich definitiv Linux-HA ausführen und diese nur für Failover-Zwecke auf zwei Boxen aufteilen. Ich würde denken, Ihr Chef wäre nicht so begeistert, wenn Sie nicht bei jedem Absturz das Endergebnis beeinflussen würden.
Ori

Antworten:


3

Magento und Zend Framework sind, wie Sie bemerkt haben, ziemlich CPU-schwer. Der beste Weg, um die CPU-Auslastung zu vermeiden, besteht darin, Inhalte nur einmal zu rendern, bis sie sich ändern. Die meisten Teile Ihres Katalogs ändern sich nicht so oft, und oft sind nur der Warenkorbblock auf Ihrer Seite oder der Block "Beliebteste Artikel" die einzigen dynamischen Teile.

Ich würde vorschlagen, einen Lack- Cache vor Apache zu platzieren. Auf diese Weise erhalten Sie ein leistungsstarkes Seiten-Caching, das Ihren LAMP-Stack ernsthaft entlasten kann. Wir haben kürzlich dank Varnish einen sehr öffentlichen Start einer Website überstanden und ich war ernsthaft beeindruckt von der Geschwindigkeit und der geringen CPU-Auslastung. Der Lack ist kostenlos und flexibel genug, um ganze Seiten oder nur die relativ statischen Teile zwischenzuspeichern und den Einkaufswagen dynamisch einzuschließen.

Bei einer Magento-Standardinstallation wird Varnish jedoch nicht viel zwischenspeichern, da es viele dynamische Inhalte, Cookies usw. pro Benutzer gibt. Ein Magento-Modul wie " PageCache powered by Varnish " modifiziert Magento so, dass es gut mit Varnish funktioniert. Es enthält auch eine Lackkonfigurationsdatei, die dem Magento-Setup entspricht. Diese beiden zusammen ergeben ein sehr effizientes Setup. Es ist ein kommerzielles Modul, aber viel günstiger als ein leistungsfähigerer Server.

Die Teile, die Sie auf ein CDN oder Nginx auslagern, sind nicht Ihr eigentliches Problem, obwohl es hilft. Sogar Apache kann eine ganze Reihe statischer Anforderungen verarbeiten. Sie müssen das Material zwischenspeichern, dessen Generierung immer wieder erforderlich ist, dh Ihre dynamischen Teile.


Ich habe mir Varnish angesehen und das scheint eine gute Lösung zu sein, um die CPU-Last zu senken, zumindest bis ich zu einem Host mit besserem CPU-Setup wechseln kann. Vielen Dank.
Dave Child

3

Normalerweise richte ich MaxRequestsPerChild auf Tausende ein - normalerweise näher an 10.000.

Sie sagen, dass Sie "das empfohlene PHP-Caching" haben - aber haben Sie APC installiert? Schließlich, wie viele Benutzer sehen Sie gleichzeitig auf der Website. Wenn Sie über erweiterte Apache-Statistiken verfügen, können Sie sehen, wie viele der Apache-Prozesse gleichzeitig tatsächlich ausgeführt werden.

800 APC-Datei-Treffer pro Sekunde und weitere 200 Benutzer-Cache sind eine Menge. Wenn das ein Dual- oder Quad-Core ist, würde ich erwarten, dass es in Ordnung bleibt. Wenn die Datenbank wirklich mithält, ist es möglicherweise das Beste, eine größere Maschine - und mehr CPUs - zu bekommen, zumindest im Moment.


Zunächst einmal danke! Die Last ist immer noch ziemlich hoch, so dass ich einige dieser Dinge sofort ausprobieren kann, was hilfreich ist :). Ich habe MaxRequestsPerChild auf 4000 erhöht - die Last sprang sofort und blieb sehr hoch. Ich habe es wieder auf 1000 reduziert, und die Last ist etwas gesunken, obwohl immer noch zu hoch. APC ist installiert. SHM ist 256. Die Überschreibung include_once ist aktiviert.
Dave Child

Wenn APC bereits installiert ist, was meldet apc.php? - Download von svn.php.net/viewvc/pecl/apc/trunk/apc.php?view=markup
Alister Bulman

Hier ist die Ausgabe (ich würde es vorziehen, nicht direkt auf die Site / den Server zu verlinken): dl.dropbox.com/u/16366/apc.htm
Dave Child

Entschuldigung, ich habe nicht bemerkt, dass Sie Ihre Antwort bearbeitet haben. Ja, es ist ein Dual-Core-VPS (Xeon 2,4 GHz). Ich hätte gedacht, dass dieser Server in der Lage sein sollte, seine aktuelle Last zu bewältigen, weshalb ich mir Sorgen mache, dass ich etwas in der Konfiguration verpasst habe oder irgendwo keinen Engpass entdeckt habe.
Dave Child

2

Ihre durchschnittliche Last ist für einen Dual-Core-VPS völlig zu hoch. 8 sollte die max sein.

Ich hatte gute Erfolge mit mod_pagespeed und event MPM für Magento. Ich würde empfehlen, auf die Verwendung von Ereignis-MPM umzusteigen und mod_pagespeed zu installieren.

Weitere Informationen zu Event MPM: Apache Event MPM-Dokumentation

Und mod_pagespeed: Google Code: mod_pagespeed

Wenn Sie auch nach den oben genannten Änderungen weiterhin Probleme beim Laden haben, sollten Sie in Betracht ziehen, zu einem anderen, besseren VPS-Plan zu wechseln.


2

Wie Alister andeutet, ist ein MaxRequestsPerChild-Wert von 400 absurd niedrig.

Der Auslastungsdurchschnitt ist sehr hoch - aber 60.000 Seitenaufrufe pro Tag sind nicht viel Verkehr.

Wie viele Prozesse haben Sie normalerweise, um Anfragen zu bedienen?

Ich bin mit Magento nicht vertraut, aber es sieht so aus, als ob mit diesem Setup etwas nicht stimmt. Ich würde erwarten, dass Sie bei niedrigerem Lastniveau deutlich mehr Durchsatz erzielen können.

Holen Sie sich ein Exemplar von Steve Souders Buch und lesen Sie es. Aktivieren Sie die Komprimierung für alle ausgehenden HTML-Inhalte (statisch und dynamisch). Und stellen Sie sicher, dass Sie eine gute Caching-Konfiguration haben. Beginnen Sie mit der Protokollierung von% D in Ihrer Datei access_log und erstellen Sie einige Tools zum Analysieren der Daten / Isolieren der Langsamkeit. Ähnliches gilt für MySQL.

Probieren Sie mysqltuner.pl aus und prüfen Sie, ob Probleme auftreten.


Normalerweise werden etwa 10 bis 20 Prozesse zu jedem Zeitpunkt aktiv bearbeitet. Wenn die Last extrem hoch ist, dann viel mehr. Magento ist so etwas wie ein Monster, das ausgeführt werden muss. Obwohl ich erwarten würde, dass andere Systeme mit diesem Datenverkehr und Setup in Ordnung sind, kann ich glauben, dass dies möglicherweise Magento ist, das aus der Box herauswächst. Danke für die Buchempfehlung.
Dave Child

mod_pagespeed hilft Magento sehr. Versuch es.
Laebshade

2

Ich führe ein ähnliches Setup aus, aber mit nginx / php-fpm / apc (opcode und fast_backend / memcached (slow_backend). Ich finde, dass php das größte Ressourcenproblem ist, wahrscheinlich weil Magento entweder wahnsinnig groß oder nur schlecht codiert ist Schau dir an, was genau die Ressourcen frisst. Könnte es PHP sein wie in meinem Fall?

Zusätzlich zu dem, was Martijn Heemels schreibt, gibt es ein Open-Source-Lackmodul, das Sie ausprobieren können. Überprüfen Sie http://moprea.ro/2011/may/6/magento-performance-optimization-varnish-cache-3/ und https://github.com/madalinoprea/magneto-varnish .
Ich habe es nur in einer Testumgebung getestet und bisher so gut.


Speichern Sie Sitzungen in der Datenbank oder auf der Festplatte (und wenn ja, auf tmpfs)?


Sie sind in einem tmpfs gespeichert.
Dave Child

1

Wenn Sie VPS verwenden, teilen Sie die CPU. Ich würde empfehlen, dass Sie mit Ihrem Host sprechen, um Ihren VPS auf eine weniger ausgelastete Hardware zu verschieben oder dediziert zu werden.

Aufgrund der gemeinsam genutzten CPU können Ihre Anwendungen nicht rechtzeitig ausgeführt werden und werden immer wieder in die Warteschlange gestellt, wodurch höhere Anforderungen für die Verarbeitung und der damit verbundene Overhead entstehen. Schließlich gibt es einen Zustand, in dem Apache oder PHP oder MySQL ihre eigenen Grenzen ausgeschöpft hätten und diese Probleme verursachen.

Fazit ist. VPS ist im Grunde eine gemeinsam genutzte CPU. Ihr Host legt möglicherweise zu viele VPS-Konten auf derselben CPU ab.

Wenn Sie die zugewiesene CPU voll ausnutzen möchten, fragen Sie entweder nach einem besseren Server mit weniger VPS, wenn möglich (Host verschieben, obwohl dies problematisch ist) oder gehen Sie dediziert vor.

Sie können sich auch vollständig für Amazon entscheiden und sich keine Sorgen über Nginx machen, indem Sie den Load Balancer verwenden, der mit wenigen Klicks für alle Ihre Server in der Cloud eingerichtet werden muss.

Der Ordner /var/mail.../root ist farbig, dh er sammelt viele E-Mails, die normalerweise aus Ihren Anwendungen stammen. Zum Beispiel versucht ein fehlerhaftes PHP-Skript, E-Mails zu senden, oder alle Cron-Jobs sind so konfiguriert, dass sie Ihnen den Status der Cron-Läufe und die Ausgabe per E-Mail senden. Sie können in die Mail schauen und sehen, was die Datei hat. Ich vermute seine Fehlermeldungen, damit Sie herausfinden können, woher es kommt.

Ich werde mehr hinzufügen, wenn Sie weitere Informationen benötigen, und möglicherweise benötige ich auch einige Informationen

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.