2012-12-05 12 views
5

मैं 4-सीपीयू और 32 जीबी मेमोरी 64 बिट मशीन पर टॉमकैट चला रहा हूं (ओएस सेंटोस 6.3 है)। जावा विकल्प मैं टॉमकैट के साथ शुरू करता हूं -server -Xms1024m -Xmx1024m -XX:PermSize=512m -XX:MaxPermSize=512mजावा प्रोग्राम (टॉमकैट) मेमोरी खा रहा है (शीर्ष में आरईएस)

शुरुआत में, आरईएस शीर्ष का उपयोग कर केवल 810 एमबी है, और यह बढ़ता रहता है। इस अवधि के दौरान, मैं जावा मेमोरी ढेर की जांच के लिए jmap -J-d64 -histo pID चलाता हूं, और मुझे लगता है कि जीसी ठीक काम करता है, क्योंकि ढेर शिखर 510 एमबी है और जीसी के बाद लगभग 200 एमबी है। लेकिन जब आरईएस शीर्ष पर 1.1 जी हिट करता है, तो CPU उपयोग 100% से अधिक हो जाएगा और टॉमकैट लटकाएगा।

सीपीयू उपयोग 100% होने पर डंप देखने के लिए jstack pid का उपयोग करके, "वीएम थ्रेड" नामक धागा लगभग 100% CPU खाता है। मैं googled, यह जेवीएम जीसी धागा है। तो मेरा सवाल यह है कि जब जीसी ठीक काम करता है तो क्यों बढ़ता रहता है? मैं इस समस्या को कैसे हल कर सकता हूं? धन्यवाद।

+0

मैं देख रहा हूँ कि आप मेरे इस सवाल का जवाब स्वीकार कर लिया है:

आगे की जांच पड़ताल के लिए इस सूत्र का पालन करें। जिज्ञासा से बाहर, क्या आप संक्षेप में वर्णन कर सकते हैं कि क्या कारण था और वास्तव में क्या मदद मिली? –

+0

जब जीसी थ्रेड 100% से अधिक सीपीयू लेता है, तो मेरे दिमाग में आने वाली पहली चीज़ स्मृति रिसाव होती है। लेकिन तथ्य यह है कि -एक्सएमएक्स 1024 मीटर मेरे ऐप के लिए बहुत छोटा है ..... मैंने गलती की :(मैं 2048 मीटर तक मेमोरी बढ़ाता हूं (-Xmx2048m), और जब यह 1.2 जी तक है तो शीर्ष का आरईएस बढ़ता नहीं है ......... – ing

+1

तो मुझे लगता है कि @digitaljoel द्वारा उत्तर –

उत्तर

1

यदि कचरा संग्रह धागा 100% पर कताई कर रहा है तो यह संभव है कि यह कचरा संग्रह करने की कोशिश कर रहा है, लेकिन किसी भी वस्तु को एकत्र नहीं किया जा सकता है, इसलिए आप एक कचरा संग्रह मौत सर्पिल में हैं जहां यह दौड़ने की कोशिश करता रहता है लेकिन किसी भी स्मृति को मुक्त करने में सक्षम नहीं है।

ऐसा इसलिए हो सकता है क्योंकि आपके प्रोग्राम में मेमोरी रिसाव है, या क्योंकि आप नियमित उपयोग के दौरान लोड की जा रही वस्तुओं की संख्या को संभालने के लिए पर्याप्त स्मृति प्रदान नहीं कर रहे हैं। ऐसा लगता है कि ढेर के आकार को बढ़ाने के लिए आपके पास बहुत सारे हेडरूम हैं। यह मौत सर्पिल को मारने से पहले केवल समय की मात्रा बढ़ा सकता है, या यह आपको चलने वाली स्थिति में ले जा सकता है। आप यह सुनिश्चित करने के लिए कुछ समय के लिए एक परीक्षण चलाने के लिए चाहते हैं कि आप केवल अपरिहार्य देरी नहीं कर रहे हैं।

+0

आपके जवाब के लिए धन्यवाद। pmap/top कमांड दिखाता है कि स्मृति बढ़ती जा रही है, लेकिन jmap दिखाता है कि ढेर एक जीसी के बाद लगभग 200 एमबी है, इसकी चोटी लगभग 550 एमबी है। ढेर के अलावा, जावा में किसी अन्य प्रकार की स्मृति एक रिसाव पेश कर सकती है? – ing

+0

ढेर अभी भी लगभग 200 एमबी है जब भी जीसी धागा 100% है? क्या आप चलते समय कचरा संग्रहण पैटर्न और ढेर स्थान को देखने के लिए jvisualvm संलग्न कर सकते हैं? – digitaljoel

+0

, मैं स्मृति को 2048 मीटर (-Xmx2048m) में बढ़ाता हूं, और 1.2 जी तक होने पर शीर्ष का आरईएस बढ़ता नहीं है। मुझे पूछने से पहले और प्रयास करना चाहिए। आपकी मदद के लिए धन्यवाद। महान लिंक के लिए – ing

2

एक परमिट लीक हो सकता है। यदि आप कहते हैं कि आपका ढेर ~ 500 एमबी पर रहता है, और -XX: MaxPermSize को 512 एमबी पर सेट किया गया है, तो पूर्ण परमान आपको 1 जीबी मेमोरी उपयोग देगा।

ऐसा हो सकता है यदि आपके पास प्रोग्राम के जीवन चक्र में बाद में लोड होने वाले जेएसपीएस के बहुत सारे (जैसे, बहुत सारे!) हों, या आपने String.intern() बहुत कुछ उपयोग किया है। स्वीप करने के लिए How to dump Permgen?

और ट्यूनिंग जीसी के लिए इस सूत्र What does JVM flag CMSClassUnloadingEnabled actually do? permgen

+0

+1। – digitaljoel

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