jstack 출력을 해석하는 중

BatchInserter을 사용하여 많은 .csv 파일의 데이터를 Neo4j 데이터베이스로로드하는 Java 프로세스가 있습니다. (ls -lh에 따른) 제 164기가바이트 로딩 후jstack 출력을 해석하는 중

오픈 JDK 7
우분투 12.04
Neo4j 2.0 M3

을 폴더 크기 증가를 중지하지만 프로세스는 계속 실행 : I가 사용하고 , 메모리가 해제되지 않았으며 CPU가 여전히 100 %였습니다 (모두 htop에 따라).

로드 프로세스가 단일 스레드입니다 만 JVM은 1 개 이상의 스레드를 사용 - 나는 ParallelGC에 의해 같아요.

나는 이러한 유형의 문제를 진단하는 방법을 잘 모르겠지만 jstack을 시도하도록 지시했다, 그래서 아래의 출력을 포함했다.

사람은 누구나 잘못 또는 내가이 진단에 대해 갈 수있는 방법에 대한 제안을 가지고 어떤 아이디어가있다?

Full thread dump OpenJDK 64-Bit Server VM (22.0-b10 mixed mode): 

"Attach Listener" daemon prio=10 tid=0x00007fc3a4001000 nid=0x5636 runnable [0x0000000000000000] 
    java.lang.Thread.State: RUNNABLE 

"Service Thread" daemon prio=10 tid=0x00007fcf58123000 nid=0x4545 runnable [0x0000000000000000] 
    java.lang.Thread.State: RUNNABLE 

"C2 CompilerThread1" daemon prio=10 tid=0x00007fcf58120800 nid=0x4544 waiting on condition [0x0000000000000000] 
    java.lang.Thread.State: RUNNABLE 

"C2 CompilerThread0" daemon prio=10 tid=0x00007fcf5811d800 nid=0x4543 waiting on condition [0x0000000000000000] 
    java.lang.Thread.State: RUNNABLE 

"Signal Dispatcher" daemon prio=10 tid=0x00007fcf5811b800 nid=0x4542 waiting on condition [0x0000000000000000] 
    java.lang.Thread.State: RUNNABLE 

"Finalizer" daemon prio=10 tid=0x00007fcf580c4800 nid=0x4541 in Object.wait() [0x00007fc3f3cfb000] 
    java.lang.Thread.State: WAITING (on object monitor) 
     at java.lang.Object.wait(Native Method) 
     - waiting on <0x00007fc4165fc708> (a java.lang.ref.ReferenceQueue$Lock) 
     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135) 
     - locked <0x00007fc4165fc708> (a java.lang.ref.ReferenceQueue$Lock) 
     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151) 
     at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:177) 

"Reference Handler" daemon prio=10 tid=0x00007fcf580c2000 nid=0x4540 in Object.wait() [0x00007fc3f3dfc000] 
    java.lang.Thread.State: WAITING (on object monitor) 
     at java.lang.Object.wait(Native Method) 
     - waiting on <0x00007fc4165ffe08> (a java.lang.ref.Reference$Lock) 
     at java.lang.Object.wait(Object.java:503) 
     at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133) 
     - locked <0x00007fc4165ffe08> (a java.lang.ref.Reference$Lock) 

"main" prio=10 tid=0x00007fcf58007800 nid=0x452c runnable [0x00007fcf606b7000] 
    java.lang.Thread.State: RUNNABLE 
     at java.lang.String.substring(String.java:1960) 
     at java.lang.String.subSequence(String.java:1993) 
     at java.util.regex.Pattern.split(Pattern.java:1202) 
     at com.ldbc.socialnet.neo4j.CsvFileReader.parseLine(CsvFileReader.java:73) 
     at com.ldbc.socialnet.neo4j.CsvFileReader.nextLine(CsvFileReader.java:61) 
     at com.ldbc.socialnet.neo4j.CsvFileReader.hasNext(CsvFileReader.java:33) 
     at com.ldbc.socialnet.neo4j.CsvFileInserter.bufferLines(CsvFileInserter.java:62) 
     at com.ldbc.socialnet.neo4j.CsvFileInserter.insertAllBuffered(CsvFileInserter.java:93) 
     at com.ldbc.socialnet.neo4j.LdbcSocialNeworkNeo4jImporter.load(LdbcSocialNeworkNeo4jImporter.java:79) 
     at com.ldbc.socialnet.neo4j.LdbcSocialNeworkNeo4jImporter.main(LdbcSocialNeworkNeo4jImporter.java:49) 

"VM Thread" prio=10 tid=0x00007fcf580ba000 nid=0x453f runnable 

"GC task thread#0 (ParallelGC)" prio=10 tid=0x00007fcf58012800 nid=0x452d runnable 

"GC task thread#1 (ParallelGC)" prio=10 tid=0x00007fcf58014800 nid=0x452e runnable 

"GC task thread#2 (ParallelGC)" prio=10 tid=0x00007fcf58016000 nid=0x452f runnable 

"GC task thread#3 (ParallelGC)" prio=10 tid=0x00007fcf58018000 nid=0x4530 runnable 

"GC task thread#4 (ParallelGC)" prio=10 tid=0x00007fcf5801a000 nid=0x4531 runnable 

"GC task thread#5 (ParallelGC)" prio=10 tid=0x00007fcf5801b800 nid=0x4532 runnable 

"GC task thread#6 (ParallelGC)" prio=10 tid=0x00007fcf5801d800 nid=0x4533 runnable 

"GC task thread#7 (ParallelGC)" prio=10 tid=0x00007fcf5801f800 nid=0x4534 runnable 

"GC task thread#8 (ParallelGC)" prio=10 tid=0x00007fcf58021000 nid=0x4535 runnable 

"GC task thread#9 (ParallelGC)" prio=10 tid=0x00007fcf58023000 nid=0x4536 runnable 

"GC task thread#10 (ParallelGC)" prio=10 tid=0x00007fcf58025000 nid=0x4537 runnable 

"GC task thread#11 (ParallelGC)" prio=10 tid=0x00007fcf58026800 nid=0x4538 runnable 

"GC task thread#12 (ParallelGC)" prio=10 tid=0x00007fcf58028800 nid=0x4539 runnable 

"GC task thread#13 (ParallelGC)" prio=10 tid=0x00007fcf5802a800 nid=0x453a runnable 

"GC task thread#14 (ParallelGC)" prio=10 tid=0x00007fcf5802c800 nid=0x453b runnable 

"GC task thread#15 (ParallelGC)" prio=10 tid=0x00007fcf5802e000 nid=0x453c runnable 

"GC task thread#16 (ParallelGC)" prio=10 tid=0x00007fcf58030000 nid=0x453d runnable 

"GC task thread#17 (ParallelGC)" prio=10 tid=0x00007fcf58032000 nid=0x453e runnable 

"VM Periodic Task Thread" prio=10 tid=0x00007fcf5812d800 nid=0x4546 waiting on condition 

JNI global references: 175 

Heap 
PSYoungGen  total 11211840K, used 7045440K [0x00007fcb95000000, 0x00007fcf3d160000, 0x00007fcf55000000) 
    eden space 7045440K, 100% used [0x00007fcb95000000,0x00007fcd43050000,0x00007fcd43050000) 
    from space 4166400K, 0% used [0x00007fce39510000,0x00007fce39510000,0x00007fcf379d0000) 
    to space 4035328K, 0% used [0x00007fcd43050000,0x00007fcd43050000,0x00007fce39510000) 
PSOldGen  total 31457280K, used 31300002K [0x00007fc415000000, 0x00007fcb95000000, 0x00007fcb95000000) 
    object space 31457280K, 99% used [0x00007fc415000000,0x00007fcb8b668b98,0x00007fcb95000000) 
PSPermGen  total 21248K, used 7487K [0x00007fc40aa00000, 0x00007fc40bec0000, 0x00007fc415000000) 
    object space 21248K, 35% used [0x00007fc40aa00000,0x00007fc40b14ff48,0x00007fc40bec0000)

특히, 사람이 힙 값에 대한 약간의 통찰력을 제공하거나 그들에 대한 좋은 읽기를 제안 할 수 있습니다? 프로세스가 거의 메모리가 부족처럼

Heap 
PSYoungGen  total 16348096K, used 12660905K [0x00007f833a560000, 0x00007f87639c0000, 0x00007f8765000000) 
    eden space 15282432K, 82% used [0x00007f833a560000,0x00007f863f18a688,0x00007f86df1a0000) 
    from space 1065664K, 0% used [0x00007f86df1a0000,0x00007f86df1a0000,0x00007f8720250000) 
    to space 1036288K, 0% used [0x00007f87245c0000,0x00007f87245c0000,0x00007f87639c0000) 
ParOldGen  total 34952576K, used 34903343K [0x00007f7ae5000000, 0x00007f833a560000, 0x00007f833a560000) 
    object space 34952576K, 99% used [0x00007f7ae5000000,0x00007f833754bd90,0x00007f833a560000) 
PSPermGen  total 21248K, used 7130K [0x00007f7adfe00000, 0x00007f7ae12c0000, 0x00007f7ae5000000) 
    object space 21248K, 33% used [0x00007f7adfe00000,0x00007f7ae04f6860,0x00007f7ae12c0000)

출처

2013-08-10 Alex Averbuch

같습니다 :

eden space 7045440K, 100% used 
object space 31457280K, 99% used

을이 경우 GC에서 모든 CPU를 alomist 소모, 일부 메모리를 확보하려고 continiosly 실행할 수 있습니다. 따라서 응용 프로그램 논리 스레드가 많이 부족합니다. -Xmx JVM 옵션을 통해 메모리를 추가하거나 응용 프로그램을 프로파일 링 할 수 있습니다. JVisualVM, Jprofiler 또는 다른 도구를 통해 프로파일 링하면 중요한 런타임 데이터가 제공됩니다 :

메모리 할당 역학. 메모리 소비는 모든 시간을 증가하는 경우 당신은 메모리가 당신이 certanly 할 수 있습니다,이 데이터를 기반으로 momory
GC 통계

을 차지하는 것을 알 수

힙 내용을 누설이 가능성이있어 문제를 해결할 수 있습니다.

출처

2013-08-10 12:46:33 Jk1

감사합니다. 다음 중 감시해야 할 것이 가장 중요한 것을 아십니까? 힙 *** PSYoungGen (총 16348096K, 12660905K 사용) - 공간 15282432K 에덴 82 %가 사용되는 공간 - 1065664K에서 0 % 사용 - 공간 1036288K로, 0 %가 사용 ParOldGen *** - 34952576K 총 34903343K 오브젝트 공간 34952576K, 99 % 사용됨 *** PSPermGen 합계 21248K, 7130K 오브젝트 공간 사용 21248K, 33 % 사용 –

ParOldGen은 장기간 메모리 소비 모니터링에 가장 중요합니다. 프로세스에 메모리 누수가 없다면, 장기적으로는 다소 안정적이어야합니다. – Jk1

다시 한 번 감사드립니다. fyi, 나는 그것이 메모리 누출이라고 생각하지 않는다. 프로세스는 다수의 "큰" 맵 (총 450,000,000 개의 항목)을 유지합니다. Xmx를 선택할 때만이 맵을 고려했으며 많은 호흡 실을 남기지 않았습니다. 이제 나는 그것에 대해서 버퍼 (String [] [])와 다른 임시 상태를 유지한다고 생각한다.증가 된 힙을 가진 프로세스를 다시 시작했으며 jstack 힙 정보를 계속 주시 할 것입니다. –

답변

관련 문제