0
Ich bin Web-Anwendung in einem Apache Tomcat mit Feder ausgeführt. Ich habe Jmeter Test mit Stresstest getan, aber Heap wird schneller gefüllt und es wird nicht Müll gesammelt. Als ich den Heap-Dump analysierte, war der verdächtige Speicherleck auf TaskQueue zurückzuführen, aber in unserem Code machen wir nichts mit der Aufgabe.
Meine Frage ist, während des Prozesses der Anfrage und Antwort auf den Server mit der obigen Konfiguration verwendet alle Aufgaben bezogenen Klassen. Speicherleck Verdächtigen ist als untenAblauf der HTTP-Anfrage und Antwort mit Apache Tomcat und Spring-Framework für eine Anwendung
One instance of "java.util.TaskQueue" loaded by "<system class loader>" occupies 680,207,896 (82.39%) bytes. The instance is referenced by org.apache.tomcat.util.threads.TaskThread @ 0xc1b52018 ajp-bio-8009-exec-243 , loaded by "java.net.URLClassLoader @ 0xce67a9b8". The memory is accumulated in one instance of "java.util.TimerTask[]" loaded by "<system class loader>"
Zu viele Anfragen waren in der Warteschlange, weil der Durchsatz der Anwendung zu gering war. Das könnte der Grund sein, warum GC überhaupt nicht funktioniert. Im Stresstest die Anzahl der Anfragen (oder die Größe) abgleichen. – dgregory
Hallo bro Danke, ich habe die Anzahl der Treffer mit Jmeter reduziert, aber obwohl der Speicher auf 600 MB Level ist, der von 800 MB oder so reduziert wurde, will ich immer noch, dass es auf einem bestimmten Level klar ist. – Sharan
Können Sie das Systemmetrik-Diagramm von jmeter hochladen? Und was ist passiert, wenn Sie GC gewaltsam auslösen? – dgregory