Java: nicht-heap-Speicher analysiert

haben wir das problem, dass unsere non-heap-Speicher wird immer größer. so haben wir uns auf den Neustart unseres jee (java8) - webapp jeden 3. Tag (wie Sie im screenshot sehen können Sie hier: screenshot aus nicht-heap - und heap-Speicher)

Ich habe bereits versucht heraus zu finden, was füllt, dass nicht-heap. Aber ich konnte nicht finden alle Tools zum erstellen einer nonheap-dump. haben Sie eine Idee, wie ich könnte, untersuchen, um herauszufinden, was Elemente sind, zunehmend wächst?

java-version

java version "1.8.0_102"
Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)

tomcat-version

Apache Tomcat Version 7.0.59
  • In einem Kommentar unten sagen Sie, dass es ein embedded tomcat. Können Sie hinzufügen, um Ihre post die JVM-version und die Parameter, die verwendet werden, um es zu starten?
  • Auch die tomcat-version ist wichtig
  • Danke @Stefan, wenn du auch die version des embedded tomcat...
  • Da Tomcat-version, die 7.0.59 einige memory-leak-Fehler behoben wurden. Können Sie aktualisieren Sie es? Eine weitere Möglichkeit, wenn lebensfähig, könnte sein, ein downgrade jvm 1.7, überprüfen Sie, ob ein perm Platz oom existiert, und den Fall analysieren, es mit sehr ausgereiften tools (eclipse MATTE, jmc, ...)
InformationsquelleAutor stefa ng | 2016-09-05
  1. 4

    Non-heap-Speicher Nutzung, wie Sie MemoryPoolMXBean zählt die folgenden Speicher-pools:

    • Metaspace
    • Komprimiert Klasse Platz
    • Code Cache

    In anderen Worten, standard non-heap-Speicher Statistiken enthält Räume, besetzt von kompilierten Methoden und geladenen Klassen. Höchstwahrscheinlich ist die Erhöhung der nicht-heap-memory-usage zeigt eine class-loader-Leck.

    Verwenden

    • jmap -clstats PID dump class loader Statistik;
    • jcmd PID GC.class_stats zum drucken der detaillierte Informationen über die Speichernutzung von jeder geladenen Klasse. Letzteres erfordert -XX:+UnlockDiagnosticVMOptions.
    InformationsquelleAutor apangin
  2. 0

    Mit Java 8, Klasse meta-Daten werden nun in eine non-heap-Speicher-Abschnitt, genannt Metaspace (und nicht in der PermGen mehr). Wenn Ihre non-heap-Speicher wird vor allem verbraucht durch Metaspace, können Sie es herausfinden mit jstat.

    Es ist nicht ein Allgemeines tool für die Analyse von non-heap-Speicher. Aber es könnte noch Hilfe in Ihrem Fall.

    InformationsquelleAutor Codo
  3. 0

    Als @apangin Punkte heraus, es sieht aus wie Sie mit mehr Metaspace im Laufe der Zeit. Dies ist in der Regel bedeutet, dass Sie geladen werden, mehr Klassen. Ich würde aufzeichnen, welche Klassen geladen werden und Methoden zusammengestellt und versuchen zu begrenzen, wie viel dies in der Produktion auf einer kontinuierlichen basis. Es ist möglich, Sie haben eine Bibliothek, die code-Generierung kontinuierlich, aber nicht entsorgen. Dies ist, wo zu schauen, was die Klassen erstellt werden, könnte einen Hinweis darauf geben, welche.

    Für native non-heap-Speicher.

    Können Sie die Speicher-Zuordnung unter Linux mit /proc/{pid}/maps Dies wird Sie wissen lassen, wie viel virtuellen Speicher verwendet wird.

    Müssen Sie bestimmen, ob dies aufgrund der

    • zunehmende Zahl von threads oder sockets
    • direct ByteBuffers verwendet werden.
    • eine Drittanbieter-Bibliothek, die mithilfe der systemeigenen /direct memory.

    Vom Blick auf Ihre Grafiken, die Sie reduzieren könnten, Ihre Haufen und steigern Sie Ihre maximale direkte Speicher und verlängern Sie die restart-Zeit bis zu einer Woche oder mehr, aber eine bessere Lösung wäre, lösen die Ursache.

    • Sieht aus wie der OP-Grafiken zeigen Sie die Speichernutzung, wie es von der MemoryPoolMXBean. Keine der thread, socket direct byte buffer-oder Drittanbieter-Bibliotheken-Speicher ist, enthalten in der standard-nicht-heap-Statistik. Die nicht-Heap-pools sind nur Code-Cache, Metaspace und Komprimiert Klasse Platz. Das ist es.
    • Das ist eine interessante Beobachtung. Es würde dann zeigen Sie auf einen laden von Klassen problem (wie die Bereitstellung einer neuen .Krieg oder .ear-Datei, wo die alte version ist nicht ordnungsgemäß freigegeben wird, oder übermäßige dynamische bytecode generieren und laden, oder eine Kombination).
    • wir führen die j2ee-web-app mit der integrierten tomcat-Komponente, so dass keine .Krieg - oder .ear-Datei-Bereitstellung
    InformationsquelleAutor Peter Lawrey
Schreibe einen Kommentar