Mikrometik für CI/CD-Pipeline | Komentor

Continuous Integration/Continuous Deployment (CI/CD) ist zu einem zentralen Bestandteil der Softwareentwicklung geworden. Um qualitativ hochwertige Software-Releases sicherzustellen, werden Rauchtests, Regressionstests, Leistungstests, statische Codeanalysen und Sicherheitsscans in der CI/CD-Pipeline durchgeführt. Trotz all dieser Qualitätsmaßnahmen treten in der Produktionsumgebung immer noch OutOfMemoryError, CPU-Spitzen, fehlende Reaktion und Verschlechterung der Reaktionszeit auf.

Diese Art von Leistungsproblemen taucht in der Produktion auf, da in der CI/CD-Pipeline nur Metriken auf Makroebene wie: Statische Codequalitätsmetriken, Test-/Codeabdeckung, CPU-Auslastung, Speicherverbrauch, Antwortzeit … untersucht werden. In einigen Fällen reichen diese Makrometriken nicht aus, um Leistungsprobleme aufzudecken. In diesem Artikel sehen wir uns die Mikrometriken an, die in der CI/CD-Pipeline untersucht werden sollten, um qualitativ hochwertige Releases in der Produktion zu liefern. Wir werden auch lernen, wie man diese Mikrometrik bezieht und in die CI/CD-Pipeline integriert.

Wie werden Tsunamis vorhergesagt?
Sie fragen sich vielleicht, warum die Tsunami-Vorhersage mit diesem Artikel zusammenhängt. Es besteht eine Beziehung 😃. Eine normale Meereswelle breitet sich mit einer Geschwindigkeit von 5 – 60 Meilen/h aus, während sich Tsunami-Wellen mit einer Geschwindigkeit von 500 – 600 Meilen/h ausbreiten. Obwohl sich Tsunami-Wellen mit einer 10- bis 100-fachen Geschwindigkeit normaler Wellen ausbreiten, ist es sehr schwierig, Tsunami-Wellen vorherzusagen. Daher verwenden moderne Technologien Mikrometrik, um Tsunamiwellen vorherzusagen.

untitled-design-3.png
Abb.: DART-Gerät zur Tsunami-Erkennung

                         To forecast Tsunami, multiple DART (Deep-ocean Assessment and Reporting of Tsunami) devices are installed all throughout the world. This DART contains two parts:

a. Oberflächenboje: Gerät, das an der Oberfläche des Meerwassers schwimmt
b. Seabed Monitor: Gerät, das am Meeresboden stationiert ist

Tiefseewasser ist etwa 6000 Meter tief. (20x des höchsten San Francisco Sales Force-Turms). Wenn der Meeresspiegel um mehr als 1 mm ansteigt, erkennt DART dies automatisch und überträgt diese Informationen an den Satelliten. Dieser Anstieg des Meerwassers um 1 mm ist ein führender Indikator für die Entstehung eines Tsunamis. Ich möchte Sie bitten, hier kurz innezuhalten und sich eine Länge von 1 mm in der Skala von 6000 Metern Meerestiefe vorzustellen. Es ist nichts, vernachlässigbar. Aber diese mikrometrische Analyse wird für die Vorhersage von Tsunamis verwendet.
**
Wie prognostiziert man Performance-Tsunamis durch Mikrometrik?**
Ebenso gibt es nur wenige Mikrometriken, die Sie in Ihrer CI/CD-Pipeline überwachen können. Diese Mikrometriken sind Frühindikatoren für mehrere Leistungsprobleme, mit denen Sie in der Produktion konfrontiert werden. Anstieg oder Abfall der Werte dieser Mikrometrik sind die großen Indikatoren für die Entstehung von Leistungsproblemen.

  1. Garbage-Collection-Durchsatz
  2. Durchschnittliche GC-Pausenzeit
  3. Maximale GC-Pausenzeit
  4. Objekterstellungsrate
  5. Peak-Heap-Größe
  6. Fadenzahl
  7. Thread-Zustände
  8. Themengruppen
  9. Verschwendeter Speicher
  10. Objektanzahl
  11. Klasse zählen

Lassen Sie uns jede Mikrometrik im Detail untersuchen:

1. DURCHSATZ DER MÜLLSAMMLUNG
Die durchgehende Garbage Collection ist die Zeit, die Ihre Anwendung für die Verarbeitung von Kundentransaktionen aufwendet, im Vergleich zu der Zeit, die Ihre Anwendung für die Garbage Collection aufwendet.

Angenommen, Ihre Anwendung läuft seit 60 Minuten. In diesen 60 Minuten werden 2 Minuten für GC-Aktivitäten aufgewendet.
Das bedeutet, dass die Anwendung 3,33 % für GC-Aktivitäten ausgegeben hat (dh 2 / 60 * 100)
Das bedeutet, dass der Garbage Collection-Durchsatz 96,67 % (dh 100 – 3,33) beträgt.

Wenn der GC-Durchsatz abnimmt, deutet dies auf ein Speicherproblem hin. Nun stellt sich die Frage: Was ist der akzeptable Durchsatz in %? Dies hängt von der Anwendung und den geschäftlichen Anforderungen ab. Typischerweise sollte man einen Durchsatz von mehr als 98 % anstreben.

2. DURCHSCHNITTLICHE PAUSENZEIT BEI DER MÜLLSAMMLUNG
Wenn das Garbage Collection-Ereignis ausgeführt wird, wird die gesamte Anwendung angehalten. Da die Garbage Collection jedes Objekt in der Anwendung markieren muss, prüfen Sie, ob diese Objekte von anderen Objekten referenziert werden. Wenn keine Referenzen vorhanden sind, müssen sie aus dem Speicher entfernt werden. Dann muss der fragmentierte Speicher komprimiert werden. Um all diese Vorgänge auszuführen, wird die Anwendung angehalten. Wenn die Garbage Collection ausgeführt wird, kommt es daher beim Kunden zu Pausen/Verzögerungen. Daher sollte man immer darauf abzielen, eine niedrige durchschnittliche GC-Pausenzeit zu erreichen.

3. MAXIMALE PAUSENZEIT DER MÜLLSAMMLUNG
Einige Garbage Collection-Ereignisse können einige Millisekunden dauern, während einige Garbage Collection-Ereignisse auch mehrere Sekunden bis Minuten dauern können. Sie sollten die maximale Garbage-Collection-Pausenzeit messen, um die schlimmstmöglichen Auswirkungen auf den Kunden zu verstehen. Um die maximale Garbage Collection-Pausenzeit zu reduzieren, sind eine ordnungsgemäße Abstimmung (und ggf. Änderungen des Anwendungscodes) erforderlich.
**
4. ERSTELLUNGSRATE VON OBJEKTEN**
Die Objekterstellungsrate ist die durchschnittliche Anzahl der von Ihrer Anwendung erstellten Objekte. Vielleicht hat die Anwendung in Ihrem vorherigen Code-Commit 100 MB/s erstellt. Ab dem letzten Code-Commit begann die Anwendung, 150 MB/s zu erstellen. Diese zusätzliche Objekterstellungsrate kann viel mehr GC-Aktivität, CPU-Spitzen, potenzielle OutOfMemoryError- und Speicherlecks auslösen, wenn die Anwendung über einen längeren Zeitraum ausgeführt wird.

5. PEAK HEAP-GRÖSSE
Die maximale Heap-Größe ist die maximale Speichermenge, die von Ihrer Anwendung verbraucht wird. Wenn die Peak-Heap-Größe einen Grenzwert überschreitet, müssen Sie dies untersuchen. Möglicherweise gibt es ein potenzielles Speicherleck in der Anwendung, neu eingeführter Code (oder Bibliotheken/Frameworks von Drittanbietern) verbraucht viel Speicher, möglicherweise gibt es eine legitime Verwendung davon. Wenn dies der Fall ist, müssen Sie Ihre JVM-Argumente ändern, um mehr zuzuweisen Erinnerung.

„Garbage-Collection-Durchsatz, durchschnittliche GC-Pausenzeit, maximale GC-Pausenzeit, Objekterstellungsrate, mikrometrische Spitzenwerte der Heap-Größe können nur aus Garbage-Collection-Protokollen bezogen werden. Zu diesem Zweck können keine anderen Tools verwendet werden.
Als Teil Ihrer CI/CD-Pipeline müssen Sie eine Regressionstestsuite oder einen Leistungstest (ideal) ausführen. Garbage Collection-Protokolle, die aus dem Test generiert wurden, sollten an übergeben werden REST-API von GCeasy. Diese API analysiert Garbage-Collection-Protokolle und antwortet mit den oben genannten Mikrometriken. Um zu erfahren, wohin diese Mikrometriken in der API-Antwort und im JSON-Pfadausdruck für sie gesendet werden, zu diesem Artikel. Wenn ein Wert verletzt wird, kann der Build fehlschlagen. Die GCeasy-REST-API verfügt über Intelligenz, um verschiedene andere Garbage-Collection-Probleme zu erkennen, wie z im ‘problem’-Element der API-Antwort. Vielleicht möchten Sie auch dieses Element verfolgen“.
**

  1. FADENZAHL**
    Die Anzahl der Threads kann eine weitere wichtige zu überwachende Metrik sein. Wenn die Thread-Anzahl ein Limit überschreitet, kann dies zu CPU- und Speicherproblemen führen. Zu viele Threads können in der Produktionsumgebung mit langer Ausführungszeit „java.lang.OutOfMemoryError“ verursachen: „Neuer nativer Thread kann nicht erstellt werden“.

7. THREAD-STATUS
Anwendungs-Threads können sich in unterschiedlichen Thread-Zuständen befinden. Informationen zu verschiedenen Thread-Zuständen finden Sie hier schneller Videoclip. Zu viele Threads im Status RUNNABLE können CPU-Spikes verursachen. Zu viele Threads im BLOCKED-Zustand können dazu führen, dass die Anwendung nicht mehr reagiert. Wenn die Anzahl der Threads in einem bestimmten Thread-Status einen bestimmten Schwellenwert überschreitet, können Sie erwägen, entsprechende Warnungen/Warnungen im CI/CD-Bericht zu generieren.

8. FADENGRUPPEN
Eine Thread-Gruppe stellt eine Sammlung von Threads dar, die ähnliche Aufgaben ausführen. Es könnte eine Servlet-Container-Thread-Gruppe geben, die alle eingehenden HTTP-Anforderungen verarbeitet. Es könnte eine JMS-Thread-Gruppe geben, die alle JMS-Sende- und -Empfangsaktivitäten handhabt. Es könnte auch einige andere sensible Thread-Gruppen in der Anwendung geben. Möglicherweise möchten Sie die Größe dieser sensiblen Threadgruppen verfolgen. Sie möchten nicht, dass ihre Größe weder unter einen Schwellenwert fällt noch einen Schwellenwert überschreitet. Eine geringere Anzahl von Threads in einer Thread-Gruppe kann die Aktivitäten blockieren. Eine größere Anzahl von Threads kann zu Speicher- und CPU-Problemen führen.

„Thread-Anzahl, Thread-Zustände, Mikrometriken von Thread-Gruppen können aus Thread-Dumps bezogen werden. Als Teil Ihrer CI/CD-Pipeline müssen Sie eine Regressionstestsuite oder einen Leistungstest (ideal) ausführen. 3 Thread-Dumps in einem Intervall von 10 Sekunden sollten erfasst werden, wenn Tests ausgeführt werden. Erfasste Thread-Dumps sollten weitergegeben werden Die REST-API von FastThread. Diese API analysiert Thread-Dumps und antwortet mit den oben genannten Mikrometriken.
Um zu erfahren, wohin diese Mikrometriken in der API-Antwort und dem JSON-Pfadausdruck für sie gesendet werden, siehe zu diesem Artikel. Wenn ein Wert verletzt wird, kann der Build fehlschlagen“. FastThread REST API verfügt über Intelligenz, um mehrere Threading-Probleme zu erkennen, wie z. B.: Deadlocks, CPU-Spike-Threads, verlängerte blockierende Threads, … Alle erkannten Probleme werden im „Problem“-Element der API-Antwort gemeldet. Vielleicht möchten Sie auch dieses Element verfolgen“.

9. VERSCHWENDETER SPEICHER
In der modernen Computerwelt wird viel Speicher aufgrund schlechter Programmierpraktiken verschwendet, wie z aufgrund all dieser ineffizienten Programmierpraktiken. Dies kann eine Schlüsselmetrik sein, die es zu verfolgen gilt. Falls die verschwendete Speichermenge einen bestimmten Prozentsatz überschreitet, kann die CI/CD-Erstellung fehlschlagen oder es können Warnungen generiert werden.

10. OBJEKTZAHL
Möglicherweise möchten Sie auch die Gesamtzahl der Objekte verfolgen, die im Arbeitsspeicher der Anwendung vorhanden sind. Die Anzahl der Objekte kann aufgrund von ineffizientem Code, der neuen Einführung von Bibliotheken von Drittanbietern und Frameworks ansteigen. Zu viele Objekte können zu OutOfMemoryError, Speicherlecks und CPU-Spitzen in der Produktion führen.

11. KLASSENZÄHLUNG
Möglicherweise möchten Sie auch die Gesamtzahl der Klassen verfolgen, die im Speicher der Anwendung vorhanden sind. Manchmal kann die Anzahl der Klassen aufgrund der Einführung von Bibliotheken oder Frameworks von Drittanbietern ansteigen. Spitzenwerte in der Anzahl der Klassen können Probleme im Metaspace/PermGen-Bereich des Speichers verursachen.

„Verschwendete Speichergröße, Objektanzahl und Mikrometriken der Klassenanzahl können aus Heap-Dumps bezogen werden. Als Teil Ihrer CI/CD-Pipeline müssen Sie eine Regressionstestsuite oder einen Leistungstest (idealerweise) ausführen. Heap-Dumps sollten erfasst werden, nachdem der Testlauf abgeschlossen ist. Erfasste Heap-Dumps sollten übergeben werden RESTAPI von HeapHero. Diese API analysiert Heap-Dumps und antwortet mit diesen Mikrometriken.
Um zu erfahren, wohin diese Mikrometriken in der API-Antwort und im JSON-Pfadausdruck für sie gesendet werden, siehe diesen Artikel. Wenn ein Wert verletzt wird, kann der Build fehlschlagen“. Die HeapHero-REST-API verfügt über die Intelligenz, mehrere speicherbezogene Probleme zu erkennen, wie z. B.: Speicherlecks, Objektabschluss usw. Alle erkannten Probleme werden im „Problem“-Element der API-Antwort gemeldet. Vielleicht möchten Sie auch dieses Element verfolgen“.

Biografie des Autors:

Ram Lakshmanan
Jeden Tag nutzen Millionen und Abermillionen von Menschen in Nordamerika – Banken, Reisen und Handel – die von Ram Lakshmanan entwickelten Anwendungen. Ram ist ein gefeierter Redner auf großen Konferenzen zu Themen der Skalierbarkeit, Verfügbarkeit und Leistung. Vor kurzem hat er ein Startup gegründet, das sich auf Fehlerbehebung bei Leistungsproblemen.

Similar Posts

Leave a Reply

Your email address will not be published.