इकाई फ्रेमवर्क मेमोरी उपयोग

Question

डेटाबेस ढांचे को डेटाबेस में नई ऑब्जेक्ट्स डालने पर स्मृति की अत्यधिक मात्रा का उपयोग करना प्रतीत होता है।

for(int i = 0; i < numOwners; ++i) 
{ 
    var owner = Owner.CreateOwner(); 
    db.AddToOwnerSet(owner); 
    for(int j = 0; j < numChildren; ++j) 
    { 
     var child = Child.CreateChild(); 
     owner.Childs.Add(child); 
    } 
} 
db.SaveChanges(); 

इस बिंदु पर, इन वस्तुओं में बहुत कम डेटा तत्व होते हैं। डेटाबेस में 140,000 इन ऑब्जेक्ट्स को डालने पर, एप्लिकेशन का कुल मेमोरी उपयोग 600 एमबी था, और 1.2 गीगाबाइट 300,000 के लिए था। ये वस्तुएं छोटी हैं, केवल एक स्ट्रिंग नाम और एक पूर्णांक कुंजी है।

मैं लूप में SaveChanges कॉल डालकर मेमोरी उपयोग को कम कर सकता हूं, लेकिन फिर निष्पादन समय बहुत खराब हो जाता है, और यह पहले से ही बहुत खराब है।

कोई भी जानता है कि इकाई ढांचा इतनी मेमोरी का उपयोग क्यों कर रहा है, या इसे कम स्मृति का उपयोग करने के लिए कैसे प्राप्त किया जाए?

Answer 1

चूंकि इकाई ढांचा स्मृति में डेटा रखता है (जैसा कि कई ओआरएम करता है), तो कई मेमोरी संग्रहों के साथ शायद आंतरिक सरणी भी होती हैं। जैसे ही आप किसी संग्रह में आइटम जोड़ते हैं, आंतरिक सरणी क्षमता में युगल होती है।

उदाहरण के लिए, यदि आपके पास 256 आइटम वाले एरेलेस्टिस्ट जैसे संग्रह हैं, और इसमें 257 वें आइटम जोड़ें, तो आंतरिक रूप से क्या होता है स्मृति की एक नई ब्लॉक 512 आइटम सरणी के लिए आवंटित की जाती है, वे 256 आइटम सरणी है नई 512 आइटम सरणी में कॉपी किया गया, और फिर 256 आइटम सरणी कचरा संग्रह के लिए उपलब्ध कराई गई है। इस प्रकार संक्रमण के बिंदु पर आपके पास स्मृति में आवंटित 768 आइटम होंगे क्योंकि आपने 257 वां आइटम जोड़ा था। मेमोरीस्ट्रीम का उपयोग करते समय मैंने इसके साथ सिरदर्द में भाग लिया है, क्योंकि आपको वास्तव में आवश्यकतानुसार लगभग 3 गुना अधिक असंगत स्मृति की आवश्यकता है। यह संग्रह क्षमता है जिसे आप संग्रह पर देखते हैं, और यह लगभग हमेशा 2 की शक्ति है (क्योंकि यह आवश्यकतानुसार आकार में दोगुना है)।

मेरी शर्त है कि आंतरिक सरणी हैं जो स्मृति वस्तुओं में आपके संग्रह का समर्थन करने के लिए आवश्यक आकार में दोगुनी हैं। तो उसी प्रकार की 300,000 ऑब्जेक्ट्स शायद आकार 524,288 की आंतरिक सरणी में आयोजित की जाएंगी। इसके अतिरिक्त, यदि यह .NE फ्रेमवर्क में कहीं और समान तकनीक की तरह है, तो जब भी 262145 वें आइटम जोड़ा गया था, तो 262144 और 524288 की एक सरणी स्मृति में मौजूद थी, जबकि आइटम को नए सरणी में कॉपी किया गया था। स्मृति में कुल 786432 आइटम। पुराने सरणी तब तक चिपक जाती है जब तक कचरा कलेक्टर ने फैसला नहीं किया कि अब इसकी आवश्यकता नहीं है।

समेकन समर्थन के संबंध में इकाई ढांचे में कुछ विकल्प हो सकते हैं जिन्हें आप अक्षम कर सकते हैं जो स्मृति उपयोग में सुधार कर सकता है। हालांकि मैं केवल यहां अनुमान लगा रहा हूं, लेकिन समेकन का समर्थन करने के लिए वे डेटा के वर्तमान संस्करण दोनों में स्मृति को संग्रहीत करते हैं, और समर्थन समरूपता की तुलना में यह मूल संस्करण है।

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

Answer 2

आपकी वस्तुएं वास्तविक डेटा के संदर्भ में "छोटी" हो सकती हैं, लेकिन प्रत्येक वस्तु एक डीटीओ नहीं है - इकाई फ्रेमवर्क आपके प्रत्येक इकाई को बहुत सारे बॉयलरप्लेट कोड को जोड़ता है, जिसका अर्थ है कि प्रत्येक ऑब्जेक्ट का वास्तविक आकार काफी है विशाल।

यदि आप लगातार बड़े ऑब्जेक्ट ग्राफ के साथ काम कर रहे हैं, तो एनएचबीर्नेट जैसे कुछ का उपयोग करने पर विचार करें जो स्थिर, परिपक्व और काम करने के लिए सिद्ध है। सुविधाओं और प्रदर्शन के मामले में इकाई फ्रेमवर्क बहुत पीछे है।

Answer 3

मुझे पता है कि यह एक पुराना सवाल है लेकिन मुझे आज भी यही समस्या का सामना करना पड़ रहा था और यह पता लगाने में कामयाब रहा कि इसका क्या कारण था!

ऐसा लगता है कि एसक्यूएल स्क्रिप्ट की पीढ़ी स्मृति में बड़ी कूद के लिए ज़िम्मेदार है। मैंने पाया कि संग्रहित प्रक्रियाएं बनाना और उन्हें मेरी ऑब्जेक्ट्स से जोड़ना (लेकिन सुनिश्चित करें कि आप this article में दिखाए गए आईडी के लिए मान वापस कर दें) ने मुझे 300 एमबी से अधिक मेमोरी बचाई है।