heapdump taille vs hprof taille

J'ai récemment fait un heapdump dans un hprof format quand mon serveur jboss a été en cours d'exécution avec un xms de 4096m et xmx de 4096m et un permsize de 512m.

La hprof fichier généré est de plus de 5 go. Lorsque je charge le heapdump dans visualvm, tapis analyseur ou yourkit, je ne vois qu'un nombre total d'octets d'environ 1 go. J'ai essayé de changé l'accessibilité portée dans yourkit mais il ne montre pas plus de 1 go.

Une idée de ce que cette grande différence dans la taille des fichiers vs affiché heapdump taille peut causer?

ps: je suis en utilisant le jdk1.6.0_23

Malheureusement, je ne suis pas autorisé à soumettre des captures d'écran ici.

Sur le système de fichiers de la hprof taille est de 5.227.659 ko et en yourkit il déclare:

Objets: 9.738.282 /superficielle de la taille de 740 mo /oubli de taille: 740 mo Chaîne accessible parmi eux: 6.652.515 (68%) /superficielle taille: 381 mo (51%) /oubli de taille: 381 MO (51%)

La plus grande retenue est la taille d'un byte[] de 206.810.176

  • Vous pouvez poster la capture d'écran de la "Synthèse" de l'onglet de VisualVM?
  • Je ne peux pas ajouter des captures d'écran, mais j'ai ajouté l'info de yourkit
  • Les données de YourKit ne m'aide pas, je ne sais pas comment ils sont calculés. Je sais comment cela se fait dans VisualVM. Si vous voulez que je vous aide, fournir les données de Base "Info" de la partie (copie dans le menu contextuel) ou vous pouvez télécharger votre comprimé heap dump quelque part et m'envoyer le lien.
  • Salut Thomas, je ne peux pas vous fournir la heapdump en raison de restrictions de sécurité, mais je peux vous donner les infos de base: Date de la prise: Ven Juil 20 14:23:43 CEST 2012 Fichier: OutOfMemoryProd\20120720-20120723\FOFO1\java_11607_lnx0399vm_201207201423.hprof\java_11607_201207201423.hprof taille du Fichier: 5.147,4 MO nombre Total d'octets: 998.064.824 Total des classes: 24.457 Total d'instances: 10.241.901 chargeurs de classes: 1.728 GC racines: 0 Nombre d'objets dans l'attente de la finalisation: 0
  • "GC racines: 0" - ce qui est très suspect. Il ressemble à il ya quelque chose de mal avec votre tas de vidage.
  • Étrange, sa peine impossible de créer une fracture de la décharge ou de manière
  • Comme je l'ai dit, n'ayant pas de GC racines est certainement mauvais. J'ai peur que sans heap dump je ne peux pas dire quel est le problème.

InformationsquelleAutor Michael | 2012-07-26
  1. 2

    quelle commande avez-vous utilisé pour générer des tas de vidage?

    $JAVA_HOME/bin/jmap -dump:live,format=b,file=c:/tmp/heap_dump.bin PID

    peut-être vous avez besoin pour passer en direct de l'option, selon les spec

     -dump:<dump-options> to dump java heap in hprof binary format
                   dump-options:
                     live         dump only live objects; if not specified,
                                  all objects in the heap are dumped.
    • Salut, nous utilisons la commande suivante: jmap -F -dump:format=b,fichier=${filename} $PID . selon oracle live option: "S'il est spécifié, seuls les objets en direct dans le tas qui sont sous-évaluées." Donc, si je le préciser, la heapdump le plus probable sera plus petit, mais peut également diminuer mes chances de trouver la cause d'une fuite de mémoire
    • c'est vraiment une bonne question - qu'est-ce que vivre de l'objet? je suppose que l'objet live est quelque chose qui n'est pas disponible pour le GC. Donc je suppose que vivre option de juste enlever les ordures des objets et vous aurez seulement les objets vivants - cela ne signifie pas que cela diminue les chances de trouver... je n'ai trouvé quelques fuites de mémoire récemment avec live options vraiment énorme dump (environ 16 GO)...
    • Salut Andrey, merci pour votre réponse. "Je n'ai trouvé quelques fuites de mémoire récemment avec live options vraiment énorme dump (environ 16 GO)" je peux imaginer que cela pourrait aider, mais ça ne fonctionne toujours pas à comprendre pourquoi il existe une grande différence entre la hprof taille sur le disque et la taille de l'analyseur d'outils s'affichent lorsque je charge le hprof (heapdump) dans de tels outils...
    InformationsquelleAutor Andrey Borisov
  2. 2

    Avez-vous essayé "Inaccessible Objets Histogramme" (vous trouverez le lien à partir du haut de la page "Aperçu")? Dans un de mes heapdumps taille 1509MB, tapis de montre seulement 454MB, mais le reste est essentiellement ordures, et bien sûr, la somme de "Shallow Tas", dans l'inaccessible objets histogramme est 966MB.

    • Comment obtenir la valeur de type spécifié int Inaccessible Objets Histogramme ? par exemple, je trouve java.lang.Chaîne occupé à 500M, mais je ne trouve pas ce string est. Je seulement obtenir ce qui est du type et de la taille totale de la nature, mais ne peut pas trouver le contenu de l'Éclipse de la Mémoire de l'Analyseur.
    InformationsquelleAutor haridsv
  3. 1

    Cela signifie que le plus probable que votre tas de vidage se composait d'une grande quantité de inaccessible objets qui auraient été ordures collectées, si un GC de courir.
    Maintenant, cela ne signifie pas que vous n'avez pas encore une fuite, cela signifie simplement que dans votre 5 GO Hprof, 4 GO de objets étaient inaccessibles et donc n'étaient pas des sources intéressantes d'une fuite.

    En Java, une fuite de mémoire peut se produire uniquement si la Collecte des Déchets ne peut pas nettoyer un objet parce que quelque chose est d'y faire référence (inattendue). Si votre fuite (le cas échéant) est à trouver dans l'1 GO d'objets, qui est resté dans votre hprof.

    InformationsquelleAutor sfali16