2013-02-20 45 views
6

का उपयोग कर एएसपीनेट में मेमोरी लीक को समझना मैं बड़ी एएसपीनेट 4.0 वेबसाइट चला रहा हूं। यह एक लोकप्रिय नेट सामग्री प्रबंधन प्रणाली का उपयोग करता है, इसमें हजारों सामग्री आइटम हैं, सैकड़ों समवर्ती उपयोगकर्ता - मूल रूप से एक भारी वेबसाइट है।रेडगेट मेमोरी प्रोफाइलर

1 दिन के दौरान आईआईएस 7 कार्यकर्ता प्रक्रिया का स्मृति उपयोग 8-10GB तक बढ़ सकता है। सर्वर में 16 जीबी इंस्टॉल है और वर्तमान में प्रति दिन एक बार ऐप पूल रीसायकल करने के लिए सेट है।

मुझे स्मृति उपयोग को कम करने के लिए दबाव डाला जा रहा है। अधिकांश मेमोरी उपयोग डेटा के बड़े तारों के कैशिंग के कारण होता है - लेकिन कैश अंतराल केवल 5-10 मिनट तक सेट होता है - इसलिए इन तारों को अंततः स्मृति से समाप्त हो जाना चाहिए।

हालांकि रेडगेट मेमोरी प्रोफाइलर चलाने के बाद मैं देख सकता हूं कि मुझे लगता है कि मेमोरी लीक क्या हैं। मैंने ऑब्जेक्ट्स द्वारा अपने इंस्टेंस लिस्ट परिणाम फ़िल्टर किए हैं जिन्हें "विशेष रूप से डिस्प्ले ऑब्जेक्ट्स द्वारा मेमोरी में रखा गया है" (मैंने रेडगेट फोरम पर पढ़ा है कि इस तरह आपको मेमोरी लीक मिलती है)। इसने मुझे तारों की एक लंबी सूची दी जो स्मृति में आयोजित की जा रही है।

प्रत्येक स्ट्रिंग के लिए मैं इंस्टेंस रिटेंशन ग्राफ का उपयोग करता हूं यह देखने के लिए कि स्मृति में क्या है। प्रतीत होता है कि System.string ऑब्जेक्ट्स को System.Web.Caching.CacheDependency द्वारा किसी बिंदु पर कैश किया गया प्रतीत होता है। यदि मैं ग्राफ़ का पालन करता हूं तो यह सभी तरह के सिस्टमों के माध्यम से चला जाता है। सिस्टम। चयन। विशेषीकृत। लिस्ट डिक्शनरी जब तक यह System.Web.FileMonitor तक नहीं पहुंच जाता है। यह कुछ समझ में आता है क्योंकि स्ट्रिंग्स फ़ाइल (छवियों/पीडीएफ/आदि) के पथ हैं।

ऐसा लगता है कि सीएमएस फाइलों के लिए पथों को कैशिंग कर रहा है, लेकिन इन कैश किए गए ऑब्जेक्ट्स तब "लीक" होते हैं। समय के साथ यह बनाता है और रैम खाता है।

क्षमा करें यह लंबे समय तक घुमाया गया है ... क्या मेरे लिए इन स्मृति रिसाव को रोकने का कोई तरीका है? या ऐप पूल रीसाइक्लिंग का उपयोग किए बिना उन्हें साफ़ करने के लिए? क्या मैं यह देख सकता हूं कि क्या कक्षा/कोड कैशिंग कर रहा है यह देखने के लिए कि क्या मैं रिसाव को ठीक कर सकता हूं?

उत्तर

0

यह सत्र स्थिति के हिस्से के रूप में स्मृति में छोड़ी जाने वाली सामान की बहुत आम समस्या की तरह लगता है। यदि ऐसा ही है तो आपके एकमात्र विकल्प हैं 1. प्रत्येक उपयोगकर्ता के सत्र में इतनी सारी चीज़ें न डालें, 2. सत्र जीवनकाल को कुछ छोटे से सेट करें (डिफ़ॉल्ट 20 मिनट है, मुझे लगता है), और 3. समय-समय पर ऐप पूल रीसायकल करें ।

1 के हिस्से के रूप में मैंने पाया कि डेटा ग्रिड नियंत्रण में डेटा प्रस्तुत करने के "अच्छे तरीके" और "खराब तरीके" हैं। आप यह जांचना चाह सकते हैं कि आप केवल उस डेटा की प्रतिलिपि बना रहे हैं जिसकी आपको आवश्यकता है और पूरे डेटाग्रिड को गलती से संदर्भ बनाए रखना नहीं है।

+0

हम पहले ही ऐप पूल रीसाइक्लिंग कर रहे हैं लेकिन क्लाइंट इसे समाधान के बजाए एक काम के रूप में देखता है। वे औचित्य के साथ कह रहे हैं कि एप्लिकेशन को इतनी मेमोरी का उपयोग नहीं करना चाहिए। –

+0

'System.Web.Caching.CacheDependency' सत्र में कैश की तुलना में एएसपी.NET कैशिंग का उपयोग है। यह कैश किसी भी तरह स्थिर है और सभी उपयोगकर्ताओं के लिए साझा किया गया है, सिवाय इसके कि कैश कुंजी उपयोगकर्ता-विशिष्ट हैं (बिल्कुल अनुशंसित नहीं है और इन प्रकार के मुद्दों का कारण बन सकता है)। पूल रीसाइक्लिंग या सत्र टाइमआउट को कम करने से केवल वेबैप के जीवनकाल को सीमित किया जाता है, स्मृति उपयोग नहीं। – JoeBilly

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