2014-09-14 4 views
11

मेरे पास स्कैला में एक सिस्टम है, जिसमें कई सारे थ्रेड और सिस्टम कॉल हैं। इस प्रणाली में कुछ समस्या है, क्योंकि समय के साथ स्मृति उपयोग बढ़ रहा है।स्कैला में मेमोरी लीक और प्रक्रिया

छवि bellow एक दिन के लिए स्मृति उपयोग दिखाता है। जब यह सीमा तक पहुंच जाता है, तो प्रक्रिया बंद हो जाती है और मैंने इसे फिर से ठीक करने के लिए घड़ी-कुत्ते को रखा। inserir a descrição da imagem aqui

मैं समय-समय पर आदेश चला

jcmd <pid> GC.run 

और यह स्मृति धीरे-धीरे बढ़ाने के लिए करता है, लेकिन रिसाव अभी भी होता है।

मैंने jvisualvm के साथ विश्लेषण किया, समय में अलग-अलग क्षणों की तुलना में, 40 मिनट डेल्टा के साथ। छवि bellow समय में इन दो क्षणों के बीच तुलना दिखाता है। ध्यान दें कि ConcurrentHashMap$HashEntry, SNode, WeakReference,और String और पैकेज में कई वर्ग scala.collection.concurrent जैसे कुछ वर्गों के उदाहरणों में वृद्धि हुई है।

memory leaked ojects

क्या स्मृति रिसाव के कारण हो सकता है?

संपादित करें 1: JVisualVM जांच करते हुए, मुझे लगता है कि TriedMap में हैं CNode और inode कक्षाओं की वस्तु देखा, कि sbt.TrapExit $ अनुप्रयोग वर्ग के अंदर instanced है। यहाँ वस्तु पदानुक्रम आंकड़ा है:

object hierarchy

+1

http://stackoverflow.com/questions/1218872/avoiding-scala-memory-leaks-scala-constructors?rq=1 http://stackoverflow.com/questions/7944148/weakreference-and-memory-leaks http : //stackoverflow.com/questions/3871960/long-lived-java-weakreferences – Tony

+0

मैं list.toStream.map देखता हूं, लेकिन scala.collection.concurrent कहां से आते हैं? जब आप कहते हैं कि "बहुत सारे धागे" क्या आपका मतलब है "foo.par" बहुत? मैं समांतर संग्रह में एक विशेषज्ञ के रूप में नहीं पूछ रहा हूँ। क्या आप स्पष्ट रूप से एक TrieMap का उपयोग कर रहे हैं? –

+0

बहुत सारे धागे का मतलब है कि सैकड़ों कलाकार हैं, प्रत्येक अभिनेता सिस्टम कॉल करता है और कार्यों को अतुल्यकालिक रूप से निष्पादित करने के लिए कुछ वायदा बनाता है। मैं स्पष्ट रूप से TrieMap का उपयोग नहीं करता। –

उत्तर

1

पहले कब्जा एक ढेर डंप जब स्मृति मुद्दे से बाहर होने के कारण आपके अनुप्रयोग क्रैश हो जाता। जब JVM

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump 

इसके बाद आप हीप डंप विश्लेषण करने के लिए स्मृति रिसाव के स्रोत पता लगाने की जरूरत है शुरू कर निम्नलिखित झंडे जोड़ें। मैं Eclipse MAT का उपयोग करने की सलाह देते हैं। Leak Suspects रिपोर्ट आपको यह समझने देगी कि वास्तव में कौन सी वस्तुएं रिसाव पैदा कर रही हैं।

+0

ढेर diffs के साथ, मुझे पहले से ही विचार है कि लीकिंग का स्रोत क्या है। ConcurrentHashMap $ हैशएन्ट्री संख्या बढ़ रहे हैं। लेकिन मैं इन ऑब्जेक्ट्स को अपने कोड में उपयोग नहीं करता, इसलिए यह स्कैला या जेवीएम –

+0

के अंदर कुछ दिखता है, हो सकता है कि आप सीधे ऑब्जेक्ट्स को तुरंत चालू न करें लेकिन ऐसा होता है। इसलिए आपको यह पता लगाने की आवश्यकता है कि ये ऑब्जेक्ट्स कब/कब/कहां बनाई गई हैं। तो जो सीएनओडी इंस्टेंस इत्यादि बनाता है। कुछ ऑब्जेक्ट सीएनओडी को संदर्भित करता है (और वस्तुओं को संदर्भित करता है) कचरा होने से रोकता है। ग्रहण MAT में यह दृश्य है - http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.mat.ui.help%2Ftasks%2Ffindingresponsibleobjects.html जो आपको कुछ जानकारी देनी चाहिए। – rrevo

0

कार्यान्वयन को देखने के बिना यह कहना मुश्किल है। आपकी पोस्ट के शीर्षक से पता चलता है कि स्कैला में मेमोरी रिसाव है, लेकिन क्या आपने ऑब्जेक्ट जारी करने में समस्याओं के खिलाफ अपना कार्यान्वयन देखा है?

  • आप बिल्कुल अभिनेताओं की संख्या को सीमित है:

    आप निम्नलिखित की जांच किया?

  • क्या आप सिस्टम कॉल के लिए टाइमआउट सेट करते हैं?
  • क्या आप थिएटर कार्यों को निष्पादित करते समय अभिनेताओं को ढेर से हटाए जाने की अनुमति देते हैं?
  • आप गिनती कितने अभिनेताओं अपनी स्मृति में फिट कर सकते हैं या आप सिर्फ इतना है कि JVM पता चल जाएगा "क्या करना है"

मैं क्या कहने की कोशिश कर रहा हूँ वह यह है कि "अभिनेता के सैकड़ों" पैदा कर रहे आशा के साथ किया हो सकता है कि आप स्मृति से बाहर हो जाएं क्योंकि आप बस कई ऑब्जेक्ट्स बनाते हैं जिन्हें बाद में रिलीज़ नहीं किया जाता है, क्योंकि वे अभी भी अपने कार्य (कोई टाइमआउट नहीं) कर रहे हैं या आपने उनमें से कई को बनाया है।

शायद आपको अपने आवेदन को कई jvms में स्केल करने की आवश्यकता है? आप कितने jvms का उपयोग करते हैं?

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