So lösen Sie das Problem der häufigen vollständigen GC aufgrund einer abnormalen Nutzung des Java-Speichers

Problemsystem

Bei der täglichen Inspektion wurde festgestellt, dass in der Anwendungszeile häufig vollständige GC angezeigt wurde Zeile

Fehlerbehebungsprozess
Analyse-Dump

Ziehen der Dump-Datei: Zwischenspiel: Wenn Sie beim Dumping :live angeben, führt der JVM vor dem Dumping einen vollständigen GC durch und der Dump des vollständigen GC wird im GC-Protokoll gedruckt. Diese Art der Fehlerbehebung bei abnormalen Online-Speichersituationen, die durch Nicht-Speicherlecks verursacht werden, verursacht Unannehmlichkeiten . Dies führte dazu, dass wir mehrmals entsorgt wurden.

Analysieren Sie die Dump-Datei:

a Es wurde festgestellt, dass eine große Anzahl von long[]-Arrays den maximalen Platz einnimmt, und es gibt Ausnahmen

#🎜 🎜#

#🎜🎜 #

b Überprüfen Sie den gc-Wurzelknoten und stellen Sie fest, dass die meisten dieser long[]-Daten von org.HdrHistogram.Histogram gespeichert werden 2048size long[]#🎜🎜 #

c Betrachtet man die Anzahl der Histogramminstanzen, sind es tatsächlich 50.000, verglichen mit dem Stapel normaler Projekte, also etwa das 100-fache 🎜#

# 🎜🎜##d Hier ist eine weitere Episode, die ich anfangs verwendet habe, aber der von mat generierte Bericht ist nicht so nützlich wie jvisualvm .exe und Ideenprofiler zur Analyse von abnormalem Speicher#🎜 🎜#Fehlerbehebungsgründe

Lokaler Start kann die Speichernutzung dieser Klasse reproduzieren, also starten Sie einen anderen Dienst mit normalem Speicher und der problematischen Anwendung lokal , und analysieren Sie den Speichervergleich

#🎜🎜 #Hier wird der Profiler der Idee verwendet, was sehr praktisch ist.

Finden Sie den Unterschied:

Im Vergleich zum Normalzustand Bei Anwendungen wurde festgestellt, dass die Referenzen abnormaler Anwendungen ab #🎜 🎜#

● Die Referenz von rx.internal.operators.OnSubscribeReduceSeed$ abnormal sind ReduceSeedSubscriber. Es wird vermutet, dass diese abnormale Referenz dazu führt, dass diese Instanzen in der neuen Generation nicht recycelt werden können, sondern sich in der alten Generation ansammeln. Der Grund, warum die vollständige GC in der Ära ausgelöst wird:

Ich habe mir kurz den relevanten Code angesehen, aber ich kann den Grund nicht erkennen, also habe ich das System direkt debuggt und verglichen.

Ich habe den relevanten Code eingegeben und einen hinzugefügt Verweis auf Histogramm, aber die normale Anwendung tat dies nicht

Aber ich kann nicht sagen, warum, wenn ich mir nur die untere linke Ecke ansehe Es ist ziemlich seltsam, dass es sich um den Thread-Pool von Metric handelt Noch einmal der Stapel, die Logik, um hierher zu gelangen, ist

Dieser Stream wird verwendet, um Systemindikatoren pro Zeiteinheit zu zählen, was zu Hystrix-Anwendungen führt Das lange Array des Histograms implementiert einen gleitenden fensterähnlichen Effekt, um Indikatoren pro Zeiteinheit zu zählen auf Parametern, was dazu führt, dass hystrix neue Objekte hinzufügt, die mehr (Einheitszeit-) Histogrammreferenzen für die Aggregation enthalten, um Indikatoren in einem längeren Zeitbereich zu zählen. Da diese Referenzen zum Zählen längerer Zeitspannen verwendet werden, werden sie von den Referenzen beeinflusst . Die Haltezeit ist lang und erreicht das Alter, aber das Wesentliche ist kein Speicherverlust, sodass sie nach jedem vollständigen GC recycelt werden kann

Das Problem lösen

Siehe Aufgrund der oben genannten Unterschiede und des seltsamen Thread-Pools besteht die erste Reaktion darin, die Metrik zu deaktivieren, damit die Anwendung keine Verweise auf diese Logik hinzufügt. Sehen Sie sich die offizielle Dokumentation an und bestätigen Sie, dass diese Funktion nur Auswirkungen hat Indikatorstatistiken und hat keinen Einfluss auf die Funktion des Leistungsschalters selbst. Verwenden Sie die Konfiguration „Configure hystrix.metrics.enabled=false“, um

Nach dem Hinzufügen der Konfiguration den Stapel zu überprüfen und anzuzeigen, kehrt die Referenz zum Normalzustand zurück Das System fügt nach einiger Zeit keine weiteren Histogramminstanzen hinzu. Nach einer Weile wurde das vollständige GC-Problem tatsächlich gelöst, aber andere Anwendungen haben dieses vollständige GC-Problem nicht um die Grundursache weiterzuverfolgen und zu untersuchen, um zu verhindern, dass andere Projekte dasselbe Problem haben #

Klasse Es basiert hauptsächlich auf hystrix.metrics.enabled, aber die Standardeinstellung ist wahr. Warum wird das Projekt nicht gestartet? ?

Ich habe den Quellcode durchsucht und festgestellt, dass die Aktivierung dieser Klasse mit einer Annotation zusammenhängt.

Nach dem Vergleich des Codes stellt sich heraus, dass nur die abnormale Anwendung diese Annotation verwendet auf dem Leistungsschalter

Aber nach Recherchen habe ich festgestellt, dass Funktionen wie Leistungsschalter immer noch verfügbar sind, ohne diese Anmerkung zu verwenden. Der Grund dafür ist, dass Spring nach der Spring-Cloud-Version Hystrix verwendet, um OpenFeign zu kapseln, anstatt Leistungsschalter zu verwenden Integration des gesamten Hystrix-Systems. Möglicherweise hat Spring-Cloud auch Nutzungsprobleme bei Hystrix entdeckt. In höheren Versionen (zumindest in unserer Version) schaltet Feign den Leistungsschalter über feign.hystrix.enabled ein und aus (wenn dieser Schalter aktiviert ist). aus, das einfache Hinzufügen von @EnableCircuitBreaker zum Kommentieren des Leistungsschalters wird nicht wirksam)

Tatsächlich wurde die @EnableCircuitBreaker-Annotation in höheren Versionen von Spring-Cloud als veraltet markiert, aber vielleicht gibt es sie, weil wir eine Zwischenversion sind Situationen, in denen es nicht als veraltet markiert ist und tatsächlich keinen Nutzen hat

Kurz gesagt, die Leistungsschalterfunktion von feign wird nur durch feign.hystrix.enabled gesteuert. Durch das Hinzufügen der Annotation @EnableCircuitBreaker werden nur alle anderen Indikatoren und anderen Funktionen von Hystrix aktiviert

Das obige ist der detaillierte Inhalt vonSo lösen Sie das Problem der häufigen vollständigen GC aufgrund einer abnormalen Nutzung des Java-Speichers. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!