में कमी उत्तरजीवी रिक्त स्थान निरंतर पूर्ण जीसी

Question

के लिए नेतृत्व मैं एक बिलाव सर्वर है, जो चलाता है के साथ इस परेशान अनुभव प्राप्त हुआ है:

• हमारे Hudson सर्वर
• हमारे वेब एप्लिकेशन का एक स्टेजिंग संस्करण, प्रति दिन 5-8 बार फिर से तैनात किया गया।

समस्या यह है कि हम निरंतर कचरा संग्रह के साथ समाप्त होते हैं, लेकिन पुरानी पीढ़ी कहीं भी भरने के करीब नहीं है। मैंने देखा है कि उत्तरजीवी रिक्त स्थान inexisting के बगल में हैं, और कचरा कलेक्टर उत्पादन के समान है: करने के लिए पारित कर दिया

Attaching to process ID 10171, please wait... 
Debugger attached successfully.    
Server compiler detected.      
JVM version is 14.1-b02      

using thread-local object allocation. 
Parallel GC with 8 thread(s)   

Heap Configuration: 
    MinHeapFreeRatio = 40 
    MaxHeapFreeRatio = 70 
    MaxHeapSize  = 3221225472 (3072.0MB) 
    NewSize   = 2686976 (2.5625MB) 
    MaxNewSize  = 17592186044415 MB  
    OldSize   = 5439488 (5.1875MB) 
    NewRatio   = 2      
    SurvivorRatio = 8      
    PermSize   = 21757952 (20.75MB) 
    MaxPermSize  = 268435456 (256.0MB) 

Heap Usage: 
PS Young Generation 
Eden Space: 
    capacity = 1073479680 (1023.75MB) 
    used  = 0 (0.0MB) 
    free  = 1073479680 (1023.75MB) 
    0.0% used 
From Space: 
    capacity = 131072 (0.125MB) 
    used  = 0 (0.0MB) 
    free  = 131072 (0.125MB) 
    0.0% used 
To Space: 
    capacity = 131072 (0.125MB) 
    used  = 0 (0.0MB) 
    free  = 131072 (0.125MB) 
    0.0% used 
PS Old Generation 
    capacity = 2147483648 (2048.0MB) 
    used  = 106164824 (101.24666595458984MB) 
    free  = 2041318824 (1946.7533340454102MB) 
    4.943684861063957% used 
PS Perm Generation 
    capacity = 268435456 (256.0MB) 
    used  = 268435272 (255.99982452392578MB) 
    free  = 184 (1.7547607421875E-4MB) 
    99.99993145465851% used 

प्रासंगिक JVM झंडे: पुन: प्रारंभ बिलाव से पहले

[GC 103688K->103688K(3140544K), 0.0226020 secs] 
[Full GC 103688K->103677K(3140544K), 1.7742510 secs] 
[GC 103677K->103677K(3140544K), 0.0228900 secs] 
[Full GC 103677K->103677K(3140544K), 1.7771920 secs] 
[GC 103677K->103677K(3143040K), 0.0216210 secs] 
[Full GC 103677K->103677K(3143040K), 1.7717220 secs] 
[GC 103679K->103677K(3143040K), 0.0219180 secs] 
[Full GC 103677K->103677K(3143040K), 1.7685010 secs] 
[GC 103677K->103677K(3145408K), 0.0189870 secs] 
[Full GC 103677K->103676K(3145408K), 1.7735280 secs] 

ढेर जानकारी टॉमकैट हैं:

-verbose:gc -Dsun.rmi.dgc.client.gcInterval=0x7FFFFFFFFFFFFFFE -Xmx3g -XX:MaxPermSize=256m 

कृपया ध्यान दें कि जीवित रिक्त स्थान स्टार्टअप पर लगभग 40 एमबी पर आकार में हैं।

इस समस्या से बचने के तरीके पर कोई भी विचार की सराहना की जाएगी।

---

अपडेट:

JVM संस्करण

$ java -version 
java version "1.6.0_15" 
Java(TM) SE Runtime Environment (build 1.6.0_15-b03) 
Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02, mixed mode) 

मैं PermGen आकार जोड़ने से और देख गौर करने के लिए जा रहा हूँ कि अगर मदद करता है - शायद उत्तरजीवी के आकार रिक्त स्थान असंबंधित था।

Answer 1

कुंजी शायद PS Perm Generation जो 99.999% (केवल 184 बाइट्स 256 *** एमबी से बाहर *** नि: शुल्क) में है।

आमतौर पर, मैं सुझाव दूंगा कि आप इसे अधिक परम जीन दें लेकिन आपने इसे पहले ही 256 एमबी दिया है जो बहुत होना चाहिए। मेरा अनुमान है कि आपके पास कुछ कोड जनरेशन लाइब्रेरी में मेमोरी रिसाव है। पर्म जनरल ज्यादातर कक्षाओं के लिए बाइटकोड के लिए प्रयोग किया जाता है।

Answer 2

मुझे लगता है कि यह एक ऐसे सर्वर सर्वर के लिए असामान्य नहीं है जो लगातार तैनात हो जाता है। परम जीन स्पेस, जो आपके लिए भरा हुआ है, वह वर्ग है जहां कक्षाएं जाती हैं। ध्यान रखें कि जेएसपी जावा कक्षाओं के रूप में संकलित किए जाते हैं, और जब आप एक जेएसपी बदलते हैं, तो एक नई कक्षा उत्पन्न होती है और लोड हो जाती है।

हमें यह समस्या है, और हमारा समाधान है कि कभी-कभी ऐप सर्वर पुनरारंभ हो।

1. तैनात हडसन एक अलग सर्वर करने के लिए अपने मचान सर्वर
2. कॉन्फ़िगर हडसन से समय-समय पर अपने मचान सर्वर को पुनः आरंभ करने के लिए:

   यह मैं क्या कर होता है। आप या तो इसे दो तरीकों से कर सकते हैं:

   1. समय-समय पर पुनरारंभ करें (उदा।, मध्यरात्रि में हर रात, भले ही निर्माण गतिविधि हो); या
   2. क्या वेब ऐप परिनियोजन कार्य सर्वर को पुनरारंभ करने के लिए सर्वर को ट्रिगर करता है। यदि आप ऐसा करते हैं तो सुनिश्चित करें कि पुनरारंभ नौकरी के लिए वास्तव में एक लंबी अवधि है (हम अपने 2 घंटे तक सेट करते हैं), ताकि आपको प्रत्येक बिल्ड के लिए सर्वर पुनरारंभ नहीं किया जा सके (यानी, यदि दो वेब ऐप परिनियोजन 2 घंटों के भीतर होता है , वे केवल एक सर्वर को पुनरारंभ करेंगे)।

Answer 3

झंडा -XX:SurvivorRatio ईडन और उत्तरजीवी रिक्त स्थान के बीच अनुपात तय करता है। JDK 1.5 tuning doc के अनुसार, डिफ़ॉल्ट मान 32 है, जो 1:32 अनुपात देता है। यह आप जो देख रहे हैं उसके अनुसार है। यह मेरे लिए अविश्वसनीय रूप से छोटा लगता है, हालांकि मैं समझता हूं कि ईडन से जीवित रहने वाले स्थान तक पहुंचने के लिए केवल बहुत ही कम वस्तुओं की अपेक्षा की जाती है।

तो, यह मानते हुए कि आपके पास बहुत लंबी जीवित वस्तुएं हैं, आपको जीवित अनुपात को कम करना चाहिए। जोखिम यह है कि स्टार्टअप चरण के दौरान आपके पास केवल उन दीर्घकालिक वस्तुएं होती हैं, और इसलिए ईडन आकार सीमित कर रहे हैं। एक परीक्षण सर्वर के लिए, मुझे संदेह है कि यह एक मुद्दा होने जा रहा है।

मैं शायद -XX:NewRatio (डिफ़ॉल्ट 3 है) बढ़ाकर ईडन स्पेस के आकार को भी कम कर दूंगा। मेरा आंत कहता है कि युवा पीढ़ी के लिए एक सौ एमबी या तो पर्याप्त है, और आप कचरे के संग्रह की लागत में वृद्धि कर रहे हैं ताकि इतनी बड़ी मात्रा में आवंटित किया जा सके (यानी, वस्तु ईडन में बहुत लंबे समय तक रहती है)। लेकिन यह सिर्फ वृत्ति है, और निश्चित रूप से आपके पर्यावरण के लिए मान्य होना चाहिए।

---

और एक अर्द्ध संबंधित टिप्पणी, अन्य उत्तरों को पढ़ने के बाद: अगर आप permgen स्थान से बाहर चलाने के लिए त्रुटि नहीं दिखाई दे रहे हैं, अपने समय यह के साथ नगण्य खर्च नहीं करते। Permgen बाकी ढेर से अलग से प्रबंधित किया जाता है।

Answer 4

क्लासलोडर लीक होना बहुत आसान है - यह सब एक क्लासलोडर के माध्यम से लोड किया गया एक ऑब्जेक्ट होता है जिसे किसी ऑब्जेक्ट द्वारा लोड नहीं किया जाता है। एक लगातार पुन: नियोजित ऐप फिर पर्मगेन स्पेस को भर देगा।

This article बताता है कि क्या देखना है, और a followup समस्या का निदान और ठीक करने का वर्णन करता है।