2013-02-07 8 views
7

मैं निम्नलिखित पैटर्न के साथ एक आवेदन पत्र है रखता है: कि कुछ निष्क्रिय समय के बाद हाइबरनेट में जाने और उनकी स्मृति की खपत के रूप में उम्मीद नीचे चला जाता हैErlang "प्रणाली" स्मृति खंड बढ़ रही

  • 2 लंबे प्रक्रियाओं चल
  • एन (0 < एन < 100) कार्यकर्ता प्रक्रियाओं है कि कुछ काम करना और हाइबरनेट के दौरान प्रयोग में एक से अधिक 10 सेकंड या समाप्त निष्क्रिय दो घंटे से अधिक
  • रात के दौरान, जब कोई गतिविधि नहीं है अगर प्रक्रिया स्मृति जाना लगभग पर वापस वही मूल्य जो एप्लिकेशन शुरू होता था, जिसे के रूप में अपेक्षित किया जाता है, सभी श्रमिकों की मृत्यु हो गई है।

मुद्दा यह है कि "सिस्टम" अनुभाग बढ़ता रहता है (लगभग 1 जीबी/सप्ताह)।

मेरा सवाल यह है कि मैं वहां संग्रहीत किए गए डिबग को कैसे डिबग कर सकता हूं या उस क्षेत्र में स्मृति आवंटित कर रहा हूं और इसे मुक्त नहीं कर रहा हूं।

मैं पहले से ही सूचियों परीक्षण किया है: keysearch/3 और यह, स्मृति रिसाव नहीं लगता है के रूप में है कि केवल देशी बात मैं (कोई बंदरगाहों, कोई ड्राइवरों का उपयोग कर रहा है, कोई NIFs, कोई BIFS, कुछ भी तो नहीं)। Erlang संस्करण R15B03 है। स्मृति() निर्गम (मामूली यातायात, एप्लिकेशन फ़र, 03 पर शुरू):

[{total,378865650}, 
{processes,100727351}, 
{processes_used,100489511}, 
{system,278138299}, 
{atom,1123505}, 
{atom_used,1106100}, 
{binary,4493504}, 
{code,7960564}, 
{ets,489944}, 
{maximum,402598426}] 

यह एक 64-बिट सिस्टम है

यहाँ वर्तमान erlang है। जैसा कि आप देख सकते हैं, "सिस्टम" खंड में ~ 270 एमबी है और "प्रक्रियाएं" लगभग 100 एमबी (जो रात के दौरान ~ 16 एमबी तक गिर जाती है) पर होती है।

+0

समान व्यवहार को देखते हुए।मेरा मानना ​​है कि यह पीरियनल कचरा संग्रह का उपयोग कर एरलांग से संबंधित है, लेकिन मैं पुष्टि नहीं कर सकता। –

+0

यदि ऐसा है, तो दोहराया गया erlang: garbage_collect() या garbage_collect (pid) सभी erlang पीआईडी ​​पर इसे ठीक करना चाहिए। यह सब कुछ "process_memory" को मुक्त करना है, कभी भी "सिस्टम" नहीं। यह आईटी में ऐसा एक आम शब्द है जो कुछ दस्तावेज को संग्रहीत करना असंभव बनाता है कि किस प्रकार का डेटा वहां संग्रहीत किया जाता है। इसके अलावा, वैसे, ओएस लगभग 70% अधिक निवासी स्मृति का उपयोग करता है। – AlexP

+0

क्या आप समय-समय पर memsup चला सकते हैं: get_memory_data/0? यह नोड पर सबसे बड़ी Erlang प्रक्रिया के आवंटित बाइट्स की पिड और संख्या दिखाता है। कुछ अंतर्दृष्टि प्रदान कर सकते हैं – Jr0

उत्तर

4

ऐसा लगता है कि मुझे यह समस्या मिली है।

मेरे पास "process_killer" gen_server है जहां प्रक्रिया आवधिक जीसी या हत्या के लिए सदस्यता ले सकती है। जीसी/मार (कुछ हाथ की तरह कुछ) स्थगित करने के लिए कुछ प्रक्रियाओं द्वारा प्राप्त प्रत्येक संदेश पर इसके सदस्यता कार्यों को बुलाया जाता है।

यह प्रक्रिया एक एरलांग निष्पादित करती है: मॉनिटर अगर मृत प्रक्रिया को पकड़ने और घड़ी सूची से इसे हटाने के लिए पहले से निगरानी नहीं की जाती है। अगर मैं प्रत्येक हैंडल संदेश पर हमारी पुन: सदस्यता लाइन पर टिप्पणी करता हूं, तो "सिस्टम" क्षेत्र सामान्य रूप से व्यवहार करता प्रतीत होता है। इसका मतलब है कि यह मेरी प्रक्रिया_किल्लर में एक बग है जो रिसाव मॉनीटर रेफ करता है (याद रखें कि आप एरलांग को कॉल कर सकते हैं: कई बार मॉनीटर करें और प्रत्येक कॉल एक संदर्भ बनाता है)।

मैं इस विचार का नेतृत्व कर रहा था क्योंकि मैंने एक साधारण मॉड्यूल का परीक्षण किया है जो एरलांग को कॉल कर रहा था: एक लूप में मॉनीटर करें और मैंने प्रत्येक कॉल पर ~ 13 बाइट्स "सिस्टम" क्षेत्र देखा है।

मजदूर स्वयं ठीक थे क्योंकि वे अपने मॉनीटर को उनके साथ ले जायेंगे। एक लंबा चल रहा है (ऐप के साथ शुरू होता है, ऐप के साथ बंद हो जाता है) प्रक्रिया जो सभी संदेशों को उन श्रमिकों को भेजती है जो प्रत्येक प्राप्त संदेश पर जीसी री-आर्म को बुला रहे थे, इसलिए हम प्रति हजार हजार मॉनीटरों के बारे में बात कर रहे हैं घंटा और कभी जारी नहीं किया।

मैं भविष्य में संदर्भ के लिए यह उत्तर यहां लिख रहा हूं।

टीएल; डीआर; सुनिश्चित करें कि आप लंबी चल रही प्रक्रिया पर मॉनीटर रेफरी लीक नहीं कर रहे हैं।