Warum explodiert die Antwortzeit, wenn die Anforderungsfrequenz sinkt?

Korrektur : Reaktionszeit ( %D) ist μs nicht ms! 1

Dies ändert nichts an der Verrücktheit dieses Musters, aber es bedeutet, dass es praktisch viel weniger verheerend ist.

Warum ist die Antwortzeit umgekehrt mit der Anforderungshäufigkeit korreliert?

Sollte der Server nicht schneller reagieren, wenn er weniger mit der Bearbeitung von Anfragen beschäftigt ist?

Irgendwelche Vorschläge, wie man Apache dazu bringt, weniger Last "auszunutzen"?

Dieses Muster ist periodisch. Dies bedeutet, dass es angezeigt wird, wenn die Impressionen unter etwa 200 Anfragen pro Minute fallen - was (aufgrund natürlicher Benutzeraktivität) von spät in die Nacht bis in die frühen Morgenstunden geschieht.

Die Anforderungen sind sehr einfache POSTs, die eine JSON mit weniger als 1000 Zeichen senden - diese JSON wird gespeichert (an eine Textdatei angehängt) - fertig. Die Antwort ist nur "-".

Die in den Diagrammen gezeigten Daten wurden mit Apache selbst protokolliert:

LogFormat "%{%Y-%m-%d+%H:%M:%S}t %k %D %I %O" performance
CustomLog "/var/log/apache2/performance.log" performance

Dies ist in Rechenzentren häufig der Fall. Die Zeiten, in denen Ihre Antwortzeit langsam ist, entsprechen denen, die im Allgemeinen als Stapelfenster bezeichnet werden. Dies ist ein Zeitraum, in dem eine geringe Benutzeraktivität erwartet wird und Batch-Prozesse ausgeführt werden können. In diesem Zeitraum werden auch Sicherungen durchgeführt. Diese Aktivitäten können die Ressourcen von Servern und Netzwerken überlasten und zu Leistungsproblemen führen, wie Sie sehen.

Es gibt einige Ressourcen, die Probleme verursachen können:

• Hohe CPU-Auslastung. Dies kann dazu führen, dass Apache auf eine Zeitscheibe wartet, um die Anforderung zu verarbeiten.
• Hohe Speichernutzung. Dies kann Puffer leeren, die es Apache ermöglichen, Ressourcen bereitzustellen, ohne sie von der Festplatte zu lesen. Es kann auch Paging / Swap von Apache-Workern verursachen.
• Hohe Festplattenaktivität. Dies kann dazu führen, dass die Datenträger-E / A-Aktivität mit entsprechenden Verzögerungen beim Bereitstellen von Inhalten in die Warteschlange gestellt wird.
• Hohe Netzwerkaktivität. Dies kann dazu führen, dass Pakete für die Übertragung in die Warteschlange gestellt werden, Wiederholungsversuche zunehmen und ansonsten den Dienst beeinträchtigen.

Ich benutze sar, um ausgestellt wie folgt zu untersuchen. atsarkann verwendet werden, um sarDaten in täglichen Datendateien zu sammeln . Diese können untersucht werden, um festzustellen, wie sich das System tagsüber verhält, wenn die Leistung normal ist, und über Nacht, wenn die Leistung variabel ist.

Wenn Sie das System mit munineinem anderen System überwachen, das die Ressourcennutzung erfasst und grafisch darstellt, finden Sie dort möglicherweise einige Indikatoren. Ich finde sarimmer noch genauer.

Es gibt Tools wie niceund ionice, die auf Batch-Prozesse angewendet werden können, um deren Auswirkungen zu minimieren. Sie sind nur bei CPU- oder E / A-Problemen wirksam. Es ist unwahrscheinlich, dass Probleme mit dem Arbeitsspeicher oder der Netzwerkaktivität behoben werden.

Verschieben von Sicherungsaktivitäten in ein separates Netzwerk und Reduzieren von Netzwerkkonflikten. Einige Sicherungsprogramme können so konfiguriert werden, dass die verwendete Bandbreite begrenzt wird. Dies könnte Netzwerkkonflikte lösen.

Abhängig davon, wie die Stapelprozesse ausgelöst werden, können Sie möglicherweise die Anzahl der parallel laufenden Stapelprozesse begrenzen. Dies kann die Leistung der Stapelverarbeitungsprozesse tatsächlich verbessern, da wahrscheinlich die gleichen Ressourcenkonflikte auftreten.

Diese Beziehung kann in die andere Richtung verlaufen, wenn die Absender der Anforderung auf den Abschluss einer vorherigen Anforderung warten, bevor sie eine neue senden. In diesem Fall sinkt der Datenverkehr aufgrund der clientseitigen Warteschlange mit zunehmenden Anforderungszeiten (aus welchen Gründen auch immer).

Oder es kann ein Artefakt Ihrer Messung sein. Wenn die obige Grafik abgeschlossene Anforderungen im Gegensatz zu ankommenden Anforderungen anzeigt , sinkt die Rate mit zunehmender Verarbeitungszeit für Anforderungen (unter der Annahme einer begrenzten Kapazität: D).

Obwohl die Antwort von @ BillThor richtig sein mag , ist es unwahrscheinlich, dass die Zeit der geringen Last vollständig von Sicherungsprozessen beansprucht wird (dh, dass die Zeiträume genau übereinstimmen).

Eine alternative Erklärung ist einfach Zwischenspeichern. Wenn ein bestimmtes Skript / eine bestimmte Datenbank oder etwas anderes in letzter Zeit nicht verwendet wurde, wurden die relevanten zwischengespeicherten Daten möglicherweise gelöscht, um Speicher für den Rest des Betriebssystems freizugeben. Dies können Indizes für eine Datenbank oder O / S-Puffer in Bezug auf eine Datei oder ähnliches sein. Eine Abfrage muss diese Informationen dann wiederherstellen, wenn seit der letzten Abfrage eine Weile vergangen ist. In Stoßzeiten tritt dies nicht auf, da die letzte Abfrage häufig war. Dies würde auch erklären, warum während der Besetztzeit niedrige und hohe Antwortzeiten auftreten.

Was Sie dort sehen, scheint mir ein statistisches Problem zu sein. Möglicherweise stimmt die Antwort von @ BillThor nicht, aber ich werde sie der Vollständigkeit halber posten.

Die Antwortzeitdiagramme basieren auf Perzentilen. Ein Beispielpool von 800-1000 Anforderungen ist eine gute Anzahl von Beispielen, ein Pool von 50-100 Anforderungen ist möglicherweise nicht so umfangreich.

Wenn Sie davon ausgehen, dass die Anzahl langsamer Anforderungen keine lineare Funktion des Anforderungsvolumens ist, sodass eine Erhöhung der Anforderungen um eine Größenordnung nicht zu einer Erhöhung der Anforderungen um eine Größenordnung führt, führt dies zu höheren Anforderungsvolumina niedrigere durchschnittliche Anforderungszeit.

Es gibt Lügen, große Lügen und Statistiken.

Meine Hypothese: Sie haben drei verschiedene Kategorien von Anfragen:

1. Der normale variable Datenstrom, der die meisten Anforderungen enthält und alle innerhalb von 200 bis 300 μs abgeschlossen sind.
2. Kleiner Stream mit einer konstanten Rate von ca. 20 Anfragen pro Minute (auch nachts). Jeder Vorgang dauert ca. 2.500 μs.
3. Winziger Stream mit einer konstanten Rate von ca. 10 Anfragen pro Minute (auch nachts). Jeder dauert deutlich über 4.000 μs.

Nachts sind die 50 Anfragen pro Minute entsprechend 20 + 20 + 10. Daher hängt das Ergebnis des 50% -Perzentils jetzt stark vom Ergebnis von Stream 2 ab. Und 95% -Perzentil hängt von Stream 3 ab, sodass es nicht einmal im Diagramm angezeigt werden kann.

Tagsüber sind die Streams 2 + 3 über dem 95% -Perzentil gut versteckt.

Je genauer ich mir das anschaue, desto eher neige ich zu der Annahme, dass ein Problem mit der Datenerfassung vorliegt.

Zunächst einmal ist mit Ihrem TPS etwas wirklich Seltsames los. Während das Gesamtmuster normal aussieht, gibt es eine sehr scharfe Unterbrechung um etwa 21 Uhr und dann noch einmal um etwa 7 Uhr. Ein normales Diagramm ist während des Übergangs zu Nebenzeiten viel flüssiger.

Dies deutet darauf hin, dass sich das Profil geändert hat und Sie möglicherweise zwei verschiedene Arten von Kunden haben:

1. Eine, die nur zwischen 7 Uhr morgens (ish) und 21 Uhr abends (ish) mit hohen Lautstärken arbeitet, und
2. eine andere, die wahrscheinlich rund um die Uhr arbeitet, bei geringeren Lautstärken.

Der zweite Hinweis ist gegen 18:00 Uhr. Die meiste Zeit davor und danach haben wir das hohe Volumenprofil - hohe TPS und niedrige Latenz. Gegen 18:00 Uhr gibt es jedoch einen plötzlichen Abfall von 800-1000 U / min auf weniger als 400 U / min. Was könnte das möglicherweise verursachen?

Der dritte Hinweis ist die Abnahme der Reaktionszeiten im 5. Perzentil. Eigentlich bevorzuge ich es, die minimalen Antwortzeiten zu betrachten (aber das 5. Perzentil ist möglicherweise besser), und zwar aus zwei Gründen: Es gibt mir die Servicezeit (dh die Antwortzeit abzüglich der Wartezeit) und die Antwortzeiten folgen in der Regel einer Weibull-Verteilung, was bedeutet, dass der Modus (oder der gebräuchlichste Wert) liegt knapp über dem Minimum.

Der Abstieg im 5. Perzentil sagt mir also, dass es eine plötzliche Unterbrechung in der Serie gibt und die Servicezeit tatsächlich gesunken ist, obwohl sowohl die Varianz als auch die durchschnittlichen Reaktionszeiten stark zugenommen haben.

Nächste Schritte

In diesem Stadium würde ich tief in die Protokolle eintauchen, um herauszufinden, was an den Proben mit geringem Volumen um 18:00 Uhr anders ist als an den Proben mit hohem Volumen davor und danach.

Ich würde suchen:

• Unterschiede in der geografischen Position (falls die Latenz die $ request_time beeinflusst)
• Unterschiede in der URL (sollte keine sein)
• Unterschiede in der HTTP-Methode (POST / GET) (sollte keine sein)
• wiederholte Anfragen von derselben IP
• und andere Unterschiede ...

Übrigens ist das "Ereignis" um 18:00 Uhr für mich ein ausreichender Beweis dafür, dass es nichts mit einer Überlastung / Aktivität des Rechenzentrums zu tun hat. Damit dies zutrifft, müsste die Überlastung zu einem Rückgang der TPS führen, der um 18:00 Uhr möglich ist, der jedoch äußerst unwahrscheinlich ist, dass zwischen 21:00 Uhr und 7:00 Uhr für 10 Stunden ein anhaltender und sanfter Abfall der TPS auftritt.