2011-11-29 11 views
8

Tengo un volcado de almacenamiento intermedio de 1 GB de un proceso de Java que se quedó sin espacio en el montón. He subido el montón a jvisualm que viene con una distribución java6. Comencé el proceso de "cálculo de tamaños retenidos" hace unas 16 horas y todavía está en ejecución. ¿Cuánto tiempo lleva ejecutar los tamaños retenidos de cómputo para los 20 objetos principales en un montón de 1GB? ¿Debo esperar que termine?¿Cuánto tiempo se tarda en calcular los tamaños retenidos en VM visual para un montón de 1 GB?

+0

no tengo ni idea de lo que está hablando (Tengo poca experiencia con Java), pero mi lógica me dice que si no está ejecutando esto en 1 GHz con 1 GB de RAM (o menos) sistema, 16 horas es demasiado ... – ComputerSaysNo

+0

Solo por curiosidad, ¿lo hizo? ¿terminar? ¿Cuánto tiempo tomó? Si no terminó, ¿finalizó exitosamente una segunda carrera? – uhm

+0

Nunca terminó. Terminé descargando una prueba de YourKit y terminó el mismo proceso en unos 20 minutos. – Joe

Respuesta

1

Tenía un montón de 600MB que solo requería 900 minutos de CPU para calcular los tamaños retenidos. Eso es 15 horas. Asumiría que está muy relacionado con lo que está en el montón, así que no extrapolaré a tu montón (también dijiste que no terminó), pero es otro punto de datos.

4

Parece que también demora para siempre en mi máquina, pero noté por parte del administrador de tareas que ya nada parecía suceder (CPU baja, disco I/O). El motivo fue que, aunque el indicador de progreso sigue mostrando una animación, la acción se anuló silenciosamente según el archivo de registro.

Para abrir el registro utilicé estos pasos:

  • Haga clic en Ayuda
  • Haga clic en Acerca
  • Haga clic en Archivo de registro

Esto me mostró en la parte inferior del registro:

SEVERE [org.openide.util.RequestProcessor] 
java.lang.OutOfMemoryError: GC overhead limit exceeded 
    at java.util.HashMap.newNode(HashMap.java:1734) 
    at java.util.HashMap.putVal(HashMap.java:630) 
    at java.util.HashMap.put(HashMap.java:611) 
    at java.util.HashSet.add(HashSet.java:219) 
    at org.netbeans.lib.profiler.heap.DominatorTree.intersect(DominatorTree.java:279) 
    at org.netbeans.lib.profiler.heap.DominatorTree.computeOneLevel(DominatorTree.java:114) 
    at org.netbeans.lib.profiler.heap.DominatorTree.computeDominators(DominatorTree.java:64) 
    at org.netbeans.lib.profiler.heap.HprofHeap.computeRetainedSize(HprofHeap.java:537) 
    at org.netbeans.lib.profiler.heap.HprofHeap.computeRetainedSizeByClass(HprofHeap.java:594) 
    at org.netbeans.lib.profiler.heap.ClassDump.getRetainedSizeByClass(ClassDump.java:102) 
    at org.netbeans.modules.profiler.heapwalk.HeapFragmentWalker.computeRetainedSizes(HeapFragmentWalker.java:100) 
    at org.netbeans.modules.profiler.heapwalk.ClassPresenterPanel$1$1.run(ClassPresenterPanel.java:187) 
    at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1393) 
[catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2003) 

Por defecto mi 64 bit Java VM Heapsize estará limitado al 25% de la memoria de mi computadora (o incluso a un límite interno de VisualVM mucho más bajo). Para resolver este problema para mi siguiente intento que duraran intento de nuevo a partir VisualVM así:

jvisualvm.exe -J-Xmx16g 

Después de esto, el registro muestra en el inicio:

Heap memory usage: initial 24,0MB maximum 14563,6MB 
+1

Encontré que jvisualvm ignoraba el indicador de línea de comando de mx desde la línea de comando, dado que ya estaba extrayendo un valor predeterminado de -Xmx256m de% JDK_HOME% \ lib \ visualvm \ etc \ visualvm.conf. Ver https://stackoverflow.com/questions/9570921/how-do-i-provide-jvm-arguments-to-visualvm –

Cuestiones relacionadas