पर्ल थ्रेड धीरे-धीरे मेमोरी का उपभोग करते हैं

Question

मैं 10 थ्रेड के साथ एक पर्ल सर्वर चला रहा हूं। कार्यक्रम समाप्त होने तक वे कभी नष्ट नहीं होते हैं, लेकिन ऐसा कुछ है जो मैं जितना संभव हो उतना अपटाइम करना चाहता हूं, इसलिए यही मेरे लिए एक मुद्दा है। धागे कई बार एक साधारण कार्य संभालते हैं। जब मैं सर्वर शुरू करता हूं और सभी धागे शुरू होते हैं, तो मुझे लगता है कि मेरे पास 288.30 एमबी मुफ्त है। प्रत्येक थ्रेड के माध्यम से दो पुनरावृत्तियों के बाद, यह 285.9 6 एमबी मुक्त रिपोर्ट करता है। यह इतना बुरा नहीं है..शायद यह कुछ स्टैक स्पेस आवंटित हो रहा है या उन पुनरावृत्तियों के दौरान कुछ है। लेकिन 15 मिनट के बाद, मुफ्त मेमोरी 248.24 एमबी तक गिर गई! मेरी याददाश्त के साथ क्या हुआ है ?? अब, दिलचस्प बात यह है कि यह पठार करता है। यह धीरे-धीरे उपभोग करता है लेकिन पहले जितना जल्दी नहीं होता है। मैंने सोचा कि शायद यह मेरी गलती थी इसलिए मैंने अपने सभी चर के दायरे को दोबारा जांचने और थ्रेड लूप के अंत में उन सभी को अपरिभाषित करने की कोशिश की।

मैं धागे के हर पुनरावृत्ति के बाद खाली स्थान मुद्रित करता हूं ताकि मैं इसे धीरे-धीरे नीचे देख सकूं। अब दिलचस्प भी है कि यह हर बार कम नहीं होता है। कभी-कभी मुक्त स्मृति पुनरावृत्ति के बाद भी रहता है।

मैं पर्ल 5.8.8 लिनक्स 2.6

पर स्रोत से बनाया का उपयोग कर रहा

किसी को भी यह क्या कारण हो सकता है के रूप में सब पर किसी भी विचार या यहाँ तक कि सुझाव हैं? मैं पर्ल कोर के भीतर मेमोरी रिसाव को रद्द करने के लिए अपने पर्ल को बाद के संस्करण में अपग्रेड करने पर विचार कर रहा हूं।

अद्यतन: क्या यह थ्रेड स्टैक आकार समस्या हो सकता है? क्या मुझे जरूरत से ज्यादा ढेर के लिए और अधिक स्मृति आवंटित किया जा सकता है। जब मैं अपना धागा बनाता हूं तो मैं सेटिंग को डिफ़ॉल्ट से नहीं बदलता। क्या मैं? धागे दस्तावेज़ कहते हैं कि डिफ़ॉल्ट रूप से सिस्टम के आधार पर 16 एमबी डिफ़ॉल्ट है। 16x10 धागे = 160 एमबी -> जो अपराधी हो सकता है। विचार?

अद्यतन: मैंने पर्ल 5.12.1 बनाया और स्थापित किया और मॉड्यूल और सबकुछ का पुनर्निर्माण किया। अब लगभग एक घंटे के लिए स्क्रिप्ट चला रहा है और यहां मैंने जो देखा है। स्मृति उपयोग अब प्रबंधनीय है, लेकिन आदर्श नहीं है।

• शुरुआत में ही मेरे थ्रेडों को कम करने के बाद थोड़ा सा प्रतीत होता था। ~ 10- 60MB से नीचे मेरे 10 धागे से ~ 45-50MB तक आवंटित।
• कुछ पुनरावृत्तियों के बाद, उनका उपयोग 3 एमबी कुल (लगभग पहले जैसा ही) बढ़ गया।
• इस बिंदु तक मुझे उम्मीद थी। सभी मेमोरी स्पॉन्गिंग के लिए आगे बढ़ती हैं, और फिर मेरे धागे में उपयोग किए जाने वाले चर के लिए बस थोड़ा सा। यह वह हिस्सा है जिसे मैं पसंद नहीं करता हूं। लगभग 10 मिनट तक चलने के बाद, मैं अतिरिक्त 65 एमबी खो देता हूं! यह ऐसा क्यों करता है? अगर यह पहले से ही 3 एमबी के साथ कुछ बार ठीक हो गया है, तो आवंटित क्यों रखें?
• यह इस बिंदु पर डेढ़ घंटे तक चल रहा है और वे अब अतिरिक्त 65 एमबी का उपयोग नहीं कर रहे हैं, यह अतिरिक्त 84 एमबी है!
• यह धीरे-धीरे अधिक स्मृति लेता है लेकिन अजीब चीज यह है कि मुफ्त मेमोरी की मात्रा प्रत्येक पुनरावृत्ति को कम नहीं कर रही है। मैं प्रत्येक पुनरावृत्ति से पहले और बाद में मुफ्त मेमोरी प्रिंट करता हूं और थोड़ी देर के लिए यह एक निश्चित संख्या के आसपास वही रहता है और फिर अचानक 5-10 एमबी तक बदल जाता है। मैं इसे दो से अधिक दिनों तक नहीं चला सकता, क्योंकि यह मेरी उपलब्ध स्मृति के 80/9 0% के करीब हो रहा है।

क्या कोई अन्य विचार हैं? कोई भी मैं कोशिश कर सकता था? मैं पहले से ही अपने सभी चर को अपरिचित कर रहा हूं।

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

अद्यतन: एचएम, बहुत अजीब। बाद में मेरे डेटा को फिर से उपयोग करने के बाद भी स्मृति एक ही दर पर बढ़ती है। यह अब शुरू होता है क्योंकि मैं कैशिंग कर रहा हूं, लेकिन फिर भी बढ़ता रहता है भले ही यह ज्यादातर मेरे कैश किए गए ऑब्जेक्ट्स का उपयोग कर रहा हो। यह परेशान है। मान लीजिए कि ग्लिबैक को आज़माने का समय है ... या फिर यह सिर्फ पर्ल चुनने की कमी है और हर दो दिनों में सर्वर को रिबूट करने के साथ रहना होगा।

अद्यतन: कैशिंग के बिना कोशिश की, कोई glibc, फिर से। थोड़ी देर के लिए ठीक काम करता है, कुछ घंटों, फिर यह बढ़ने लगते हैं। बस आप एक ग्राफ देखना चाहता था।
http://tinypic.com/r/311nc08/3
http://i32.tinypic.com/311nc08.jpg

अद्यतन: यहाँ एक लॉग से पहले और एक मिनट के बारे में प्रत्येक धागा के बाद मुक्त स्मृति का दस्तावेजीकरण का एक अंश है। शायद यह किसी को समस्या को बेहतर ढंग से समझने में मदद कर सकता है। ऐसा लगता है कि यह थोड़ी देर के लिए स्थिर है और फिर हर बार इस तरह की अधिक स्मृति खाएगा। यहां मैं लगभग 40 एमबी खो देता हूं!

[9:8:30, Fri Jul 23, 2010] [0] Memory usage at end thread 1: 253.812736MB (obj cache: 136) 
[9:8:30, Fri Jul 23, 2010] [0] Memory usage at idle thread 1: 253.812736MB (obj cache: 136) 
[9:8:34, Fri Jul 23, 2010] [204] Sending data to thread 
[9:8:34, Fri Jul 23, 2010] [0] 3 - Creating a new obj 
[9:8:34, Fri Jul 23, 2010] [206] Sending data to thread 
[9:8:34, Fri Jul 23, 2010] [0] 4 - Creating a new obj 
[9:8:35, Fri Jul 23, 2010] [0] Memory usage at end thread 3: 253.812736MB (obj cache: 136) 
[9:8:35, Fri Jul 23, 2010] [0] Memory usage at idle thread 3: 253.812736MB (obj cache: 136) 
[9:8:35, Fri Jul 23, 2010] [0] Memory usage at end thread 4: 253.812736MB (obj cache: 136) 
[9:8:35, Fri Jul 23, 2010] [0] Memory usage at idle thread 4: 253.812736MB (obj cache: 136) 
[9:8:41, Fri Jul 23, 2010] [225] Sending data to thread 
[9:8:41, Fri Jul 23, 2010] [0] 2 - Creating a new obj 
[9:8:42, Fri Jul 23, 2010] [0] Memory usage at end thread 2: 253.681664MB (obj cache: 136) 
[9:8:42, Fri Jul 23, 2010] [0] Memory usage at idle thread 2: 253.681664MB (obj cache: 136) 
[9:8:47, Fri Jul 23, 2010] [243] Sending data to thread 
[9:8:47, Fri Jul 23, 2010] [0] 1 - Creating a new obj 
[9:8:48, Fri Jul 23, 2010] [0] Memory usage at end thread 1: 253.935616MB (obj cache: 136) 
[9:8:48, Fri Jul 23, 2010] [0] Memory usage at idle thread 1: 253.935616MB (obj cache: 136) 
[9:9:1, Fri Jul 23, 2010] [277] Sending data to thread 
[9:9:1, Fri Jul 23, 2010] [0] 3 - Creating a new obj 
[9:9:2, Fri Jul 23, 2010] [280] Sending data to thread 
[9:9:2, Fri Jul 23, 2010] [0] 4 - Creating a new obj 
[9:9:2, Fri Jul 23, 2010] [0] Memory usage at end thread 3: 253.935616MB (obj cache: 136) 
[9:9:2, Fri Jul 23, 2010] [0] Memory usage at idle thread 3: 253.935616MB (obj cache: 136) 
[9:9:3, Fri Jul 23, 2010] [283] Sending data to thread 
[9:9:3, Fri Jul 23, 2010] [0] 2 - Creating a new obj 
[9:9:4, Fri Jul 23, 2010] [284] Sending data to thread 
[9:9:4, Fri Jul 23, 2010] [0] 1 - Creating a new obj 
[9:9:4, Fri Jul 23, 2010] [0] Memory usage at end thread 2: 253.935616MB (obj cache: 136) 
[9:9:4, Fri Jul 23, 2010] [0] Memory usage at idle thread 2: 253.935616MB (obj cache: 136) 
[9:9:5, Fri Jul 23, 2010] [287] Sending data to thread 
[9:9:5, Fri Jul 23, 2010] [0] 3 - Creating a new obj 
[9:9:5, Fri Jul 23, 2010] [0] Memory usage at end thread 4: 253.93152MB (obj cache: 136) 
[9:9:5, Fri Jul 23, 2010] [0] Memory usage at idle thread 4: 253.93152MB (obj cache: 136) 
[9:9:6, Fri Jul 23, 2010] [290] Sending data to thread 
[9:9:6, Fri Jul 23, 2010] [0] 2 - Creating a new obj 
[9:9:7, Fri Jul 23, 2010] [0] Memory usage at end thread 3: 253.804544MB (obj cache: 136) 
[9:9:7, Fri Jul 23, 2010] [0] Memory usage at idle thread 3: 253.804544MB (obj cache: 136) 
[9:9:7, Fri Jul 23, 2010] [0] Memory usage at end thread 1: 253.804544MB (obj cache: 136) 
[9:9:7, Fri Jul 23, 2010] [0] Memory usage at idle thread 1: 253.804544MB (obj cache: 136) 
[9:9:9, Fri Jul 23, 2010] [0] 4 - Creating a new obj 
[9:9:9, Fri Jul 23, 2010] [301] Sending data to thread 
[9:9:9, Fri Jul 23, 2010] [0] 3 - Creating a new obj 
[9:9:9, Fri Jul 23, 2010] [302] Sending data to thread 
[9:9:9, Fri Jul 23, 2010] [0] 1 - Creating a new obj 
[9:9:10, Fri Jul 23, 2010] [0] 3 - Creating a new obj 
[9:9:11, Fri Jul 23, 2010] [0] 3 - Creating a new obj 
[9:9:11, Fri Jul 23, 2010] [0] Memory usage at end thread 4: 253.93152MB (obj cache: 136) 
[9:9:11, Fri Jul 23, 2010] [0] Memory usage at idle thread 4: 253.93152MB (obj cache: 136) 
[9:9:12, Fri Jul 23, 2010] [308] Sending data to thread 
[9:9:12, Fri Jul 23, 2010] [0] 4 - Creating a new obj 
[9:9:13, Fri Jul 23, 2010] [0] Memory usage at end thread 1: 253.804544MB (obj cache: 136) 
[9:9:13, Fri Jul 23, 2010] [0] Memory usage at idle thread 1: 253.804544MB (obj cache: 136) 
[9:9:14, Fri Jul 23, 2010] [0] Memory usage at end thread 4: 253.804544MB (obj cache: 136) 
[9:9:14, Fri Jul 23, 2010] [0] Memory usage at idle thread 4: 253.804544MB (obj cache: 136) 
[9:9:14, Fri Jul 23, 2010] [0] Memory usage at end thread 3: 253.93152MB (obj cache: 136) 
[9:9:14, Fri Jul 23, 2010] [0] Memory usage at idle thread 3: 253.93152MB (obj cache: 136) 
[9:9:15, Fri Jul 23, 2010] [313] Sending data to thread 
[9:9:15, Fri Jul 23, 2010] [0] 1 - Creating a new obj 
[9:9:16, Fri Jul 23, 2010] [0] Memory usage at end thread 2: 214.482944MB (obj cache: 136) 
[9:9:16, Fri Jul 23, 2010] [0] Memory usage at idle thread 2: 214.482944MB (obj cache: 136) 
[9:9:16, Fri Jul 23, 2010] [315] Sending data to thread 
[9:9:16, Fri Jul 23, 2010] [0] 4 - Creating a new obj 
[9:9:17, Fri Jul 23, 2010] [0] Memory usage at end thread 1: 214.355968MB (obj cache: 136) 
[9:9:17, Fri Jul 23, 2010] [0] Memory usage at idle thread 1: 214.355968MB (obj cache: 136) 
[9:9:18, Fri Jul 23, 2010] [316] Sending data to thread 
[9:9:18, Fri Jul 23, 2010] [0] 3 - Creating a new obj 
[9:9:18, Fri Jul 23, 2010] [317] Sending data to thread 
[9:9:18, Fri Jul 23, 2010] [0] 2 - Creating a new obj 
[9:9:18, Fri Jul 23, 2010] [318] Sending data to thread 
[9:9:18, Fri Jul 23, 2010] [0] 1 - Creating a new obj 
[9:9:19, Fri Jul 23, 2010] [0] Memory usage at end thread 4: 214.355968MB (obj cache: 136) 
[9:9:19, Fri Jul 23, 2010] [0] Memory usage at idle thread 4: 214.355968MB (obj cache: 136) 
[9:9:19, Fri Jul 23, 2010] [0] Memory usage at end thread 1: 214.355968MB (obj cache: 136) 
[9:9:19, Fri Jul 23, 2010] [0] Memory usage at idle thread 1: 214.355968MB (obj cache: 136) 
[9:9:20, Fri Jul 23, 2010] [0] Memory usage at end thread 3: 214.482944MB (obj cache: 136) 
[9:9:20, Fri Jul 23, 2010] [0] Memory usage at idle thread 3: 214.482944MB (obj cache: 136) 
[9:9:20, Fri Jul 23, 2010] [0] Memory usage at end thread 2: 214.482944MB (obj cache: 136) 
[9:9:20, Fri Jul 23, 2010] [0] Memory usage at idle thread 2: 214.482944MB (obj cache: 136) 

अद्यतन (2010/08/12): बस धागे और सिस्टम malloc के साथ पर्ल 5.12 की एक नई संकलित संस्करण के साथ एक दिन के लिए यह भाग गया। आश्चर्यजनक रूप से मुझे वही व्यवहार मिलता है। धीरे-धीरे एक समय में एमबी के टुकड़े खोना। यह देखने के लिए Valgrind कोशिश कर सकते हैं कि मैं इसे क्यों खो रहा हूँ। जबकि मैं कुछ और के साथ खेल रहा था हालांकि मैंने कुछ और सोचा था। मेरी लिपि कई कथित तौर पर कई एसएसएल सॉकेट बनाती है और नष्ट कर देती है। क्या यह संभव है कि व्यापक रूप से उपयोग किए जाने वाले मॉड्यूल जैसे आईओ :: सॉकेट :: एसएसएल थोड़ा सा लीक हो? या शायद ओपनएसएसएल? (V0.9.8o का उपयोग कर)। एसएसएल मॉड्यूल तक पहुंच को सिंक्रनाइज़ करने का प्रयास करने के लिए यह देखने के लिए जा रहा है कि इसका कोई प्रभाव है या नहीं, इसमें थ्रेड के साथ समस्याएं हो सकती हैं।

अद्यतन: प्रत्येक थ्रेड, तेज़ मेमोरी उपयोग के भीतर मॉड्यूल को अलग से लोड करने का प्रयास किया। सॉकेट फ़ंक्शंस का उपयोग करके क्षेत्रों को लॉक करने का प्रयास किया, इसलिए एक समय में केवल एक थ्रेड उन्हें इस्तेमाल करता था, फिर भी स्मृति को पहले से ही खो देता था। काम की सटीक मात्रा के साथ 4 से 10 तक कार्यकर्ता धागे की संख्या में वृद्धि हुई। मेमोरी 30 मिनट तक नहीं चला। मुझे विश्वास है कि यह या तो थ्रेड कार्यान्वयन के साथ आंतरिक रूप से एक पर्ल समस्या है, या एक स्टैक समस्या (कोई इरादा नहीं है)। मैंने निर्मित थ्रेड विधियों का उपयोग करके स्टैक आकार को बदलने की कोशिश की लेकिन एक ही परिणाम। एक और तरीके से देखने के लिए जा रहे हैं। शायद एक निम्न स्तर का रास्ता। में इस दिलचस्प tidbit मिला: थ्रेड की संख्या बनाता मेमोरी बढ़ाने के लिए तेजी से जाना ... या धागे 'ढेर कार्यान्वयन के साथ कुछ ढेर के आकार

अद्यतन (2010/09/15) प्रतीत होता है आईओ :: सॉकेट :: एसएसएल डॉक ...

इस तथ्य यह है कि एक परिपत्र संदर्भ आईओ :: सॉकेट :: एसएसएल सॉकेट वस्तुओं और ग्लोब संदर्भ की तरह एक साथ काम करते हैं बनाने के लिए आवश्यक है के कारण है।

"परिपत्र संदर्भ" हुह? एक और संभावित स्पष्टीकरण यह है कि ये सॉकेट कुछ समय के लिए चारों ओर चिपके हुए हैं, भले ही मैंने उन्हें स्पष्ट रूप से अपरिचित किया। यह देखने के लिए जागृत होना कि क्या यह सॉकेट के साथ कुछ भी करता है। अगर मुझे कुछ दिलचस्प लगता है तो आपको बताएगा।

हल (2010/09/16): मेरा उत्तर है कि मैं समाधान युक्त पोस्ट किया

Answer 1

अंततः रिसाव को दबा दिया। सबसे पहले, मैं आपको सुधार दिखाना चाहता हूं। आपको वास्तविक संख्याओं को नहीं देखना चाहिए क्योंकि पहले ग्राफ़ को लेने के बाद उपयोगकर्ता आधार बढ़ गया है, बस ढलान में अंतर देखें।

से पहले स्मृति उपयोग ग्राफ: http://i32.tinypic.com/311nc08.jpg
स्मृति उपयोग ग्राफ के बाद: http://i51.tinypic.com/29goill.jpg

कई महीनों के लिए मैं सर्वर को पुन: प्रारंभ हर कुछ दिनों फंस गया था, लेकिन पिछले 14 घंटे से अधिक है, वहाँ में कोई वृद्धि की गई है स्मृति उपयोग।

हर ट्यूटोरियल, उदाहरण, प्रस्तुति, और पुस्तक है कि मैं मदद करने के लिए सर्वर को विकसित करते थे, सब छोड़े गए एक बहुत बहुत महत्वपूर्ण आईओ :: सॉकेट :: एसएसएल के बारे में तथ्य यह है। और थ्रेड किए गए ऐप के भीतर उस मॉड्यूल का उपयोग करने वाले हर कोई बेहतर सुनता है। आईओ :: सॉकेट :: एसएसएल के दस्तावेज में किसी भी आखिरी पंक्तियों में से किसी ने कभी भी जोर नहीं दिया, जिसके कारण मुझे बहुत मूर्खतापूर्ण मानना ​​पड़ा कि किसी भी अन्य डेटा संरचना की तरह मैं जो भी सॉकेट बनाता हूं, उसे स्कोप से बाहर जाने के बाद मुक्त कर दिया जाएगा (और हाँ , मुझे उस नियम के अपवाद पता है)।मैंने सोचा कि मैं हर किसी को एक एहसान दूंगा और जिस लाइन का जिक्र कर रहा हूं उसे बुलाओ।

... आईओ :: सॉकेट :: एसएसएल सॉकेट प्रोग्राम समाप्त होने तक खुला रहेगा या आप उन्हें स्पष्ट रूप से बंद कर देंगे। यह इस तथ्य के कारण है कि आईओ :: सॉकेट :: एसएसएल सॉकेट्स ऑब्जेक्ट्स और ग्लोब संदर्भों के साथ-साथ कार्य करने के लिए एक परिपत्र संदर्भ की आवश्यकता होती है।
http://search.cpan.org/dist/IO-Socket-SSL/SSL.pm#LIMITATIONS

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

तो जैसा कि आप कल्पना कर सकते हैं, यह एक बहुत ही सरल फिक्स था। मेरे धागे के काम लूप के भीतर जहां एक सॉकेट हर पुनरावृत्ति उत्पन्न करता है, मैंने नीचे दिए गए eval { close $socket; };undef $socket; को नीचे रखा है ताकि यह सुनिश्चित किया जा सके कि यह अगले क्लाइंट को प्रोसेस करने से पहले बंद हो जाए। मैंने अपना सर्वर शुरू किया और इंतजार किया और देखा क्योंकि मेमोरी उपयोग ठोस था क्योंकि आप मेरे दूसरे ग्राफ में देख सकते हैं। तो इस मुद्दे को चालू और बंद करने के दो महीने बाद, मैं अंततः एक समाधान में आया। मुझे आशा है कि यह सॉकेट के साथ किसी भी अन्य शौकिया प्रोग्रामिंग के लिए कुछ अंतर्दृष्टि प्रदान करता है। उत्तर/टिप्पणियां/सुझाव प्रदान करने वाले हर किसी के लिए धन्यवाद, हर चीज में मदद मिली, और इससे विचारों को उछालने में मदद मिली।

Answer 2

आपका पर्ल 4 और आधे साल पुराना है। 5.12 पर अपग्रेड करें। बस 5.12 निर्माण नोटों खोज और प्रमुख धागे सुधार की गंदगी टन पर देखने यह है कि सिर्फ जादुई अपने अस्पष्ट समस्या ठीक हो सकती:

• 5,12 :: @_ और $ _ अब धागे (आर टी # तहत रिसाव 34,342 और # 41,138, यह भी # 70,602, # 70,974) '
• 5.10 :: ithreads के तहत, PL_reg_curpm में regex अब गिना संदर्भ है। यह संदर्भित होने के संदर्भ में इसका सामना करने के लिए बहुत सारे हैकिश कामकाज को समाप्त करता है।
• 5.9 :: धागे: कई फिक्स, उदाहरण के लिए() समस्याओं और मेमोरी लीक के लिए उदाहरण के लिए। कुछ प्लेटफार्मों (जैसे लिनक्स) में ग्लिब का उपयोग करते हैं, एक इथ्रेड की न्यूनतम मेमोरी पदचिह्न कई सौ किलोबाइट कम हो गई है।
• 5.9 :: धागे :: साझा किए गए कई मेमोरी लीक तय किए गए हैं।

मेरा मतलब सूची बस जब आप thead विकास और सामान की एक विस्तृत श्रृंखला के चार साल कि इस समस्या पैदा कर सकता है की बात पर चला जाता है, threads::shared

के आधुनिक बदलाव का बाहर की जाँच मैं आपकी पोस्ट पर टिप्पणी , यह मेरा अगला सुझाव होगा: यदि आप glibc का उपयोग नहीं कर रहे हैं और आप perl malloc (डिफ़ॉल्ट) का उपयोग कर रहे हैं, तो आप कभी भी ओएस को स्मृति जारी नहीं करेंगे। प्रक्रिया का आकार अधिकतम आकार प्रति पीएलएल का प्रतिनिधित्व करेगा। ग्लिबैक मॉलोक के साथ पुनर्निर्माण करने का प्रयास करें (पुन: संकलन की आवश्यकता है) देखें कि क्या यह एक अलग स्मृति प्रोफ़ाइल प्रदान करता है। इसके अलावा, यह कोड दिखाने का समय होगा।

Answer 3

कोशिश उन्नयन threads.pm और धागे :: साझा की है। 5.12.1 पर अपग्रेड करना भी एक अच्छा विचार है।

Answer 4

मैं 5.10 के साथ एक ही समस्या में पड़ गए और कई विरोध है कि नए पर्ल स्मृति रिसाव नहीं था, जब धागे का उपयोग किया गया के बावजूद, पर्ल स्मृति लीक जब धागे इस्तेमाल किया गया।

मेरे समाधान Thread::Pool::Simple का प्रयोग कर एक थ्रेड पूल बनाने के लिए और का उपयोग करें कि बजाय नया सूत्र बनाने के लिए किया गया था। मेरे मामले में, मुझे बहुत सारे थ्रेड होने की उम्मीद नहीं थी, न ही उनके लिए लंबे समय तक चलने की उम्मीद थी (शायद 30 सेकंड अधिकतर)। मुझे नहीं पता कि यह आपके लिए एक विकल्प होगा, लेकिन यदि आप वास्तव में अपने धागे को सरल कार्यों को संभालने में हैं, तो हो सकता है।