Nebenwirkungen eines Apache2 Reload-Ereignisses

Ich habe mich gefragt, welche Auswirkungen externe Clients auf eine ziemlich ausgelastete Site haben würden, wenn der Apache2-Server neu konfiguriert und dann ein Befehl zum erneuten Laden von /etc/init.d/apache2 ausgegeben würde.

Ich weiß theoretisch, dass aktuelle Aktionen ohne Probleme durchgeführt werden sollten, aber wie würde sich dies insgesamt auf die Website auswirken?

Nehmen wir für dieses Beispiel an, ich möchte einmal pro Minute ein Nachladen durchführen. Würde dies die Leistung der Website erheblich beeinträchtigen?

Vielen Dank

apache-2.2

— BParker
quelle

Nach einem früheren Kommentar, den Sie hinterlassen haben, haben Sie ein SVN-Repository erwähnt. Ich bin ziemlich sicher, dass Sie ein SVN-Repo im laufenden Betrieb erstellen können. Und für die Benutzerauthentifizierung können Sie eine MySQL-Datenbank verwenden. Ich hasse es, Server oder Dienste neu zu starten, es sei denn, ich muss es wirklich. Hinterlasse einen Kommentar, wenn ich eine Antwort mit weiteren Informationen posten soll.

— Natalie Adams

Nathan: Entschuldigung für die späte Antwort, ich würde mich sicherlich für weitere Informationen hier interessieren, ich konnte es überhaupt nicht zum

— Laufen bringen

Tag auch,

Ich vermute, dass ein erneutes Laden pro Minute die Leistung Ihrer Website beeinträchtigen würde, aber dies hängt stark von folgenden Faktoren ab:

Ihre Konfiguration: Welches MPM verwenden Sie? Vorgabel oder Arbeiter? Wie viele Kinder haben Sie angegeben? Und im Falle eines Arbeitnehmers, wie hoch sind Ihre maximalen Threads pro Kind? Dies wirkt sich darauf aus, wie lange die Prozesse aufgrund der eleganten Art des Herunterfahrens warten müssen.
Was machen die Leute auf Ihrer Site: Laden sie große Dateien herunter? Dies führt natürlich zu längeren Sitzungen und damit zu längeren Zeiten, in denen die Prozesse beendet und neu gestartet werden
Was Sie protokollieren: Dies hängt etwas mit dem vorherigen Punkt zusammen. Wenn Sie jedoch die bereitgestellten Bytes protokollieren, wird der Protokolleintrag erst nach Abschluss der Download-Sitzung vorgenommen.
Verwenden Sie Apache 2.2.12 oder höher? Dann haben Sie die Möglichkeit, eine maximale Zeit anzugeben, die "ordnungsgemäß" benötigt, bevor der Prozess beendet und neu gestartet wird.

All dies wirkt sich auf Ihre Antwortzeit auf das Neuladen aus. Ich denke, ein Nachladen pro Minute ist etwas übertrieben und beeinträchtigt nur die Leistung Ihrer Website.

Ich würde vorschlagen, ein Server-HUP in den Prozess einzubeziehen, wenn eine neue Konfiguration wie wir eingeführt wird.

Wir haben bei wichtigen Nachrichtenereignissen über eine Stunde lang ein maximales Verkehrsaufkommen von 3,8 Millionen Treffern pro Sekunde und 7 Millionen Treffern pro Sekunde festgestellt. Ein solcher Ansatz für Konfigurationsaktualisierungen wirkt sich nicht auf unsere Server aus.

HTH

Prost,

— Rob Wells
quelle

Aus den Apache-Dokumenten gehe ich davon aus, dass ein HUP ein vollständiger Neustart von /etc/init.d/apache2 ist. Warum wäre das besser als ein Nachladen? Mein Verständnis ist, dass bei einem Neuladen alle NEUEN Verbindungen den neuen Konfigurationsstatus annehmen würden, während alle derzeit aktiven Verbindungen in ihrem alten Konfigurationsstatus fortgesetzt würden. Ich würde sagen, ein vollständiger Neustart in regelmäßigen Abständen scheint eine sichere Option zu sein. Verursacht ein vollständiger Neustart jedoch keine weiteren Störungen der Site? Hat jemand irgendwelche Daten dazu? Danke

— BParker

G'day, wir haben festgestellt, dass wir mit der Option "Anmutiger Neustart" ein seltsames Verhalten festgestellt haben. In erster Linie, dass einige untergeordnete Prozesse herumhängen. Manchmal als Zombies. Mein Grundsatz ist, dass ein HUP ein sofortiges Herunterfahren und erneutes Laden erzwingt, dh es ist nicht anmutig. Ich spiele gerade damit. Das neue "||" Die Syntax für die Protokollierung ermöglicht es uns, unsere Protokolle jede Nacht zu drehen, ohne die Apache-Server HUP zu müssen, und sie müssen nur Verbindungen trennen, was derzeit ein Problem bei großen Downloads von Programmen für einen bestimmten großen britischen Streaming-Dienst ist. ;-)

— Rob Wells

... (kein Platz mehr). Wenn Sie Ihre Site regelmäßig HUPEN, wird der Dienst unterbrochen, und Sie sollten besser einen ordnungsgemäßen Neustart versuchen. Aber ich würde mir ansehen, wie oft Sie damit rechnen, Konfigurationen zu ändern, und dann von dort aus Ihre Neustartfrequenz ermitteln. Unter welcher Last stehen Ihre Server?

— Rob Wells

Übrigens "Es funktioniert !!!" (-: (Hatte gerade einen Blick)

— Rob Wells

Im Moment sind die Server ziemlich begrenzt ausgelastet, so dass ich die Möglichkeit habe, herumzuspielen. Ich mache ein Subversion-Hosting und die Konfigurationsdateien ändern sich, wenn ein neues Repository erstellt wird, was im Hinblick auf den Serververkehr eine relativ leise Aktivität ist. Ich dachte, da der Großteil der normalen Aktivitäten bei Tageslicht stattfindet, wäre es in Ordnung, jede Nacht einen vollständigen Neustart durchzuführen (vorausgesetzt, es wurden tagsüber einige Nachladevorgänge durchgeführt), aber ansonsten sollten Sie die Nachladebefehle einhalten, damit die Dinge während des Tages funktionieren der Tag. Ich war besorgt, dass ein Neuladen Probleme für Kunden verursachen würde

— BParker

Die Verwendung /etc/init.d/apache2 reloadentspricht einem ordnungsgemäßen Neustart. Wie Sie sagten, werden die aktuellen Verbindungen bis zum Ende übertragen, bevor das Kind stirbt. Wenn Kinder sterben, werden sie durch neue Kinder mit der neuen Konfiguration ersetzt (Neustart siehe Apache-Dokument) .

In der Praxis kann es etwas langsamer werden, da einige Ressourcen erforderlich sind, um das untergeordnete Element neu zu starten, die Konfiguration neu zu laden und Protokolldateien zu schließen und zu öffnen. Dies ist jedoch für die Clients kaum erkennbar.

Was Ihr Beispiel betrifft, hängt es wahrscheinlich davon ab, wie viele freie Ressourcen Sie auf Ihrem Server haben und wie groß die Protokolldateien und die Konfiguration sind, aber meiner Ansicht nach würde dies die Site-Leistung nicht beeinträchtigen.

— Yanik
quelle