जावा जीसी के साथ क्या चल रहा है? पर्मजेन स्पेस भर रहा है?

मुझे नहीं पता कि मेरी जावा प्रक्रिया के साथ क्या चल रहा है। यह प्रक्रिया एक अनुक्रमण प्रक्रिया है। यह ज़िप फ़ाइलों के एक सेट से दस्तावेज़ पढ़ता है, और उन्हें ल्यूसीन इंडेक्स में जोड़ता है। जीसी लॉग से पता चलता है कि यह लगातार पूर्ण जीसी चल रहा है।जावा जीसी के साथ क्या चल रहा है? पर्मजेन स्पेस भर रहा है?

4959.569: [Full GC 19960K->19960K(10617856K), 0.1648590 secs] 
4959.764: [Full GC 19960K->19960K(10617856K), 0.1650240 secs] 
4959.959: [Full GC 19960K->19960K(10617856K), 0.1649380 secs] 
4960.154: [Full GC 19960K->19960K(10617856K), 0.1650000 secs] 
4960.350: [Full GC 19960K->19960K(10617856K), 0.1648900 secs]

जहां तक मेरा इन पंक्तियों व्याख्या कर सकते हैं, इससे पहले कि और 19M के आसपास है के बाद वस्तुओं के आकार, लेकिन क्यों यह यह सब बार की तरह चल रहा है?

धागा डंप इस तरह दिखता है:

........[Unloading class sun.reflect.GeneratedConstructorAccessor1] 
[Unloading class sun.reflect.GeneratedConstructorAccessor2] 
[Unloading class sun.reflect.GeneratedConstructorAccessor3] 
2012-01-13 12:55:24 
Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.4-b02 mixed mode): 

"org.cxv.CXVIndexer.main()" prio=10 tid=0x00007f4540474000 nid=0x4b15 waiting on condition [0x00007f453f5ed000] 
    java.lang.Thread.State: RUNNABLE 
     at org.apache.lucene.index.DocFieldProcessorPerThread.abort(DocFieldProcessorPerThread.java:72) 
     at org.apache.lucene.index.DocumentsWriter.abort(DocumentsWriter.java:424) 
     - locked <0x000000034ab44fb8> (a org.apache.lucene.index.DocumentsWriter) 
     at org.apache.lucene.index.DocumentsWriter.flush(DocumentsWriter.java:659) 
     - locked <0x000000034ab44fb8> (a org.apache.lucene.index.DocumentsWriter) 
     at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3623) 
     - locked <0x000000034aacf660> (a org.apache.lucene.index.IndexWriter) 
     at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3588) 
     at org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1858) 
     at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1822) 
     at org.cxv.IndexCreator.close(IndexCreator.java:25) 
     at org.cxv.CXVIndexer.doIndexing(CXVIndexer.java:41) 
     at org.cxv.CXVIndexer.main(CXVIndexer.java:75) 
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
     at java.lang.reflect.Method.invoke(Method.java:597) 
     at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) 
     at java.lang.Thread.run(Thread.java:662) 

"Low Memory Detector" daemon prio=10 tid=0x00007f4540003800 nid=0x4b0a runnable [0x0000000000000000] 
    java.lang.Thread.State: RUNNABLE 

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

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

"Signal Dispatcher" daemon prio=10 tid=0x000000004032b800 nid=0x4b07 runnable [0x0000000000000000] 
    java.lang.Thread.State: RUNNABLE 

"Surrogate Locker Thread (Concurrent GC)" daemon prio=10 tid=0x0000000040329800 nid=0x4b06 waiting on condition [0x0000000000000000] 
    java.lang.Thread.State: RUNNABLE 

"Finalizer" daemon prio=10 tid=0x000000004030c800 nid=0x4b05 in Object.wait() [0x00007f453fdfc000] 
    java.lang.Thread.State: WAITING (on object monitor) 
     at java.lang.Object.wait(Native Method) 
     - waiting on <0x000000034a6613a8> (a java.lang.ref.ReferenceQueue$Lock) 
     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118) 
     - locked <0x000000034a6613a8> (a java.lang.ref.ReferenceQueue$Lock) 
     at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134) 
     at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) 

"Reference Handler" daemon prio=10 tid=0x0000000040305000 nid=0x4b04 in Object.wait() [0x00007f453fefd000] 
    java.lang.Thread.State: WAITING (on object monitor) 
     at java.lang.Object.wait(Native Method) 
     - waiting on <0x000000034a6627c0> (a java.lang.ref.Reference$Lock) 
     at java.lang.Object.wait(Object.java:485) 
     at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) 
     - locked <0x000000034a6627c0> (a java.lang.ref.Reference$Lock) 

"main" prio=10 tid=0x0000000040111000 nid=0x4af7 in Object.wait() [0x00007f4563c79000] 
    java.lang.Thread.State: WAITING (on object monitor) 
     at java.lang.Object.wait(Native Method) 
     - waiting on <0x000000034aadf6f8> (a java.lang.Thread) 
     at java.lang.Thread.join(Thread.java:1186) 
     - locked <0x000000034aadf6f8> (a java.lang.Thread) 
     at org.codehaus.mojo.exec.ExecJavaMojo.joinThread(ExecJavaMojo.java:415) 
     at org.codehaus.mojo.exec.ExecJavaMojo.joinNonDaemonThreads(ExecJavaMojo.java:405) 
     at org.codehaus.mojo.exec.ExecJavaMojo.execute(ExecJavaMojo.java:317) 
     at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107) 
     at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) 
     at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) 
     at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) 
     at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) 
     at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) 
     at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) 
     at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) 
     at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) 
     at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) 
     at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534) 
     at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) 
     at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) 
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
     at java.lang.reflect.Method.invoke(Method.java:597) 
     at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) 
     at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) 
     at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) 
     at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) 

"VM Thread" prio=10 tid=0x00000000402fe000 nid=0x4b03 runnable 

"Gang worker#0 (Parallel GC Threads)" prio=10 tid=0x0000000040120000 nid=0x4af8 runnable 

"Gang worker#1 (Parallel GC Threads)" prio=10 tid=0x0000000040122000 nid=0x4af9 runnable 

"Gang worker#2 (Parallel GC Threads)" prio=10 tid=0x000000004nid=0x4afa runnable 

"Gang worker#3 (Parallel GC Threads)" prio=10 tid=0x0000000040125800 nid=0x4afb runnable 

"Gang worker#4 (Parallel GC Threads)" prio=10 tid=0x0000000040127800 nid=0x4afc runnable 

"Gang worker#5 (Parallel GC Threads)" prio=10 tid=0x0000000040129000 nid=0x4afd runnable 

"Gang worker#6 (Parallel GC Threads)" prio=10 tid=0x000000004012b000 nid=0x4afe runnable 

"Gang worker#7 (Parallel GC Threads)" prio=10 tid=0x000000004012d000 nid=0x4aff runnable 

"Concurrent Mark-Sweep GC Thread" prio=10 tid=0x0000000040220800 nid=0x4b02 runnable 
"Gang worker#0 (Parallel CMS Threads)" prio=10 tid=0x000000004021c800 nid=0x4b00 runnable 

"Gang worker#1 (Parallel CMS Threads)" prio=10 tid=0x000000004021e800 nid=0x4b01 runnable 

"VM Periodic Task Thread" prio=10 tid=0x000000004033a000 nid=0x4b0b waiting on condition 

JNI global references: 1154 

Heap 
par new generation total 153344K, used 0K [0x0000000340000000, 0x000000034a660000, 0x000000034a660000) 
    eden space 136320K, 0% used [0x0000000340000000, 0x0000000340000000, 0x0000000348520000) 
    from space 17024K, 0% used [0x00000003495c0000, 0x00000003495c0000, 0x000000034a660000) 
    to space 17024K, 0% used [0x0000000348520000, 0x0000000348520000, 0x00000003495c0000) 
concurrent mark-sweep generation total 10464512K, used 19960K [0x000000034a660000, 0x00000005c91a0000, 0x0000000780000000) 
concurrent-mark-sweep perm gen total 2097152K, used 2097151K [0x0000000780000000, 0x0000000800000000, 0x0000000800000000)

धागा डंप से, यह 2 जी पर्म जनरल भरने है जैसा दिखता है। क्या यह वास्तव में परम जीन के लिए उस जगह की जरूरत है?

स्रोत

2012-01-13 user3111525

आपका PermGen पूरी तरह से भरा हुआ है। इसका मतलब है कि कक्षा वस्तुओं का निर्माण होता है जो अंतरिक्ष की कमी के कारण संभाल नहीं सकता है। पहला प्रयास करें: अपने पर्मजेन स्तर को '-XX: MaxPermSize = 3 जी' के साथ बढ़ाएं और इसे VisualVM के साथ बढ़ते देखें। लोड किए गए वर्गों की संख्या देखें, और देखें कि यह एक निश्चित स्तर तक पहुंचता है – Grooveek

क्या आप हमें यह बता सकते हैं कि आपकी 'जावा प्रक्रिया' वास्तव में क्या है? क्या यह एक सर्वर है, एक डेस्कटॉप अनुप्रयोग, क्या? –

@ मैथ्यूफारवेल हाँ, यह एक सर्वर है। यह एक अनुक्रमण प्रक्रिया है। यह ज़िप फ़ाइलों के एक सेट से दस्तावेज़ पढ़ता है, और उन्हें ल्यूसीन इंडेक्स में जोड़ता है। – user3111525

यह तब होगा जब आपकी याददाश्त खंडित हो, या साफ करने के लिए कुछ भी नहीं है। यह अक्सर होता है जब आप अधिकतम मेमोरी आकार के करीब होते हैं।

मैंने कभी भी प्रति व्यक्ति 2 जी की आवश्यकता वाले किसी के बारे में नहीं सुना है। क्या आप वाकई युवा और कार्यरत जगहों को नहीं देख रहे हैं जिन्हें आप देखना चाहते हैं?

बीटीडब्ल्यू: इंटर्न() एड स्ट्रिंग जावा 7 में मुख्य ढेर रिक्त स्थान में रखा गया है। जावा 7 से पहले, उन्हें परम जीन स्पेस में रखा जाता था, जिससे यह बहुत अधिक डेटा इंटर्न करने का बुरा विचार बनाता है ()

स्रोत

2012-01-13 14:00:07

+1। इसे अभी आज़माएं। – user3111525

पुराने संग्राहक (उदा। ParallelOldGC) को संकलित करने वाले कलेक्टर का उपयोग करने का प्रयास करें और देखें कि क्या आप अनुमति स्थान के साथ एक ही समस्या में भागते हैं। –

अपने आवेदन को विस्तार से देखे बिना, यह कहना मुश्किल है। हालांकि, परमजन स्पेस का उपयोग करने के लिए सामान्य अपराधी इंटर्न वाले स्ट्रिंग हैं (.intern() के लिए अपने कोड बेस में खोजें) और गतिशील कोड जनरेशन।

स्रोत

2012-01-13 13:55:41

permanent generation (perm gen)generational garbage collection के साथ JVMs में "स्थायी" डेटा होता है जो एकत्र नहीं किया जाता है। इस मेमोरी सेगमेंट में मुख्य रूप से सिस्टम क्लासलोडर द्वारा लोड की गई क्लास परिभाषाएं होती हैं, इसलिए यदि आपका प्रोग्राम बहुत से वर्गों को लोड करता है (उदाहरण के लिए कई बड़ी निर्भरताएं हैं) तो यह स्थान भर जाएगा। ध्यान दें कि जब तक आप एक कस्टम क्लासलोडर (यानी डिफ़ॉल्ट, सिस्टम क्लासलोडर के अलावा) का उपयोग नहीं कर रहे हैं, तब तक कक्षाएं (आमतौर पर) अनलोड नहीं की जाएंगी।

परम जन अंतरिक्ष का आकार बदलने के बारे में जानकारी के लिए this guide देखें।

स्रोत

2012-01-13 13:57:17 maerics

तो, आपको यह भी लगता है कि परम जीन में कोई समस्या है? – user3111525

@ फ्रैंकमोस: जरूरी नहीं कि कोई समस्या हो, नहीं; यह हो सकता है कि आप निर्भर वर्गों (या परम जीन में संग्रहीत अन्य डेटा) की "बड़ी" संख्या लोड कर रहे हों और तदनुसार परम जीन हीप स्पेस को बढ़ाएं। जावा 7 के बारे में याद दिलाने के लिए – maerics

मेरे मामले में, परमजिन पूर्ण जीसी भर रहे थे और उत्तेजित कर रहे थे क्योंकि जेएक्सबी का मेरा उपयोग गतिशील रूप से कक्षाएं बना रहा था। इसे डीबग करने के लिए, मैंने देखा कि जेएमएक्स कंसोल के माध्यम से पर्मजेन की निगरानी सीधे पूर्ण जीसी (-verbose: gc का उपयोग करके) से मेल खाती है। इसके अलावा, -verbose का उपयोग करके: कक्षा ने मुझे दिखाया कि यह मेरा जेएक्सबी उपयोग था।

स्रोत

2012-07-26 15:15:12

जावा जीसी के साथ क्या चल रहा है? पर्मजेन स्पेस भर रहा है?

उत्तर

संबंधित मुद्दे