.NET कचरा कलेक्टर और x64 वर्चुअल मेमोरी

Question

16 जीबी रैम के साथ विंडोज सर्वर 2008 x64 पर एक .NET अनुप्रयोग चला रहा है। इस एप्लिकेशन को बहुत बड़ी मात्रा में डेटा (लगभग 64 जीबी) लाने और विश्लेषण करने की आवश्यकता है, और इसे एक ही समय में स्मृति में रखें।

मुझे क्या देखने की उम्मीद है: प्रक्रिया का आकार पिछले 16 जीबी से 64 जीबी तक फैलता है। विंडोज़ आवश्यकतानुसार डिस्क से अतिरिक्त डेटा को पृष्ठ पर वर्चुअल मेमोरी का उपयोग करता है। यह क्लासिक वर्चुअल मेमोरी उपयोग केस है।

जो मैं वास्तव में देखता हूं: प्रक्रिया का आकार भौतिक स्मृति (16 जीबी) की मात्रा तक ही सीमित है। आवेदन कचरा कलेक्टर में अपने समय का 99.8% खर्च करता है।

हमारा एप्लिकेशन वर्चुअल मेमोरी का उपयोग करने में विफल क्यों है? क्या यह .NET कचरा कलेक्टर की कॉन्फ़िगरेशन में या Windows x64 वर्चुअल मेमोरी मैनेजर में एक समस्या है? भौतिक स्मृति तक सीमित होने के बजाय वर्चुअल मेमोरी का उपयोग करने के लिए हमारे आवेदन को प्राप्त करने के लिए मैं क्या कर सकता हूं?

धन्यवाद।

- ब्रायन

अद्यतन:

using System; 

namespace GCTest 
{ 
    class Program 
    { 
     static void Main() 
     { 
      byte[][] arrays = new byte[100000000][]; 
      for (int i = 0; i < arrays.Length; ++i) 
      { 
       arrays[i] = new byte[320]; 
       if (i % 100000 == 0) 
       { 
        Console.WriteLine("{0} arrays allocated", i); 
        System.Threading.Thread.Sleep(100); 
       } 
      } 
     } 
    } 
} 

यदि आप इसे करने की कोशिश करना चाहते हैं, 64 के लिए निर्माण करने के लिए सुनिश्चित करें: मैं एक बहुत छोटे से प्रोग्राम है जो एक ही व्यवहार दिखाता लिखा है। आपको अपने सिस्टम को तनाव देने के लिए स्थिरांक को थोड़ा सा संशोधित करना पड़ सकता है। मैं जो व्यवहार देखता हूं वह यह है कि प्रक्रिया 16 जीबी के आकार तक पहुंच जाती है। कोई त्रुटि संदेश या अपवाद फेंक दिया गया है। प्रदर्शन मॉनिटर रिपोर्ट करता है कि जीसी में सीपीयू समय का% 100% तक पहुंचता है।

क्या यह अस्वीकार्य नहीं है? वर्चुअल मेमोरी सिस्टम कहां है?

Answer 1

ऐसा लगता है कि आप बड़े डेटा का संदर्भ नहीं रख रहे हैं। कचरा कलेक्टर संदर्भित वस्तुओं को एकत्र नहीं करेगा।

Answer 2

क्या आपने यह सुनिश्चित करने के लिए जांच की है कि आपकी पेजिंग फ़ाइल कॉन्फ़िगर की गई है ताकि वह उस आकार में विस्तार कर सके?

अद्यतन

मैं चारों ओर इस के साथ अपने दिए गए उदाहरण के साथ काफ़ी खेल रहा है, और यहाँ मैं क्या देखते हैं।

सिस्टम: विंडोज 7 64 बिट, 6 जीबी ट्रिपल-चैनल रैम, 8 कोर।

1. आपको अपने ओएस से किसी अन्य स्पिंडल पर एक अतिरिक्त पेजिंग फ़ाइल की आवश्यकता है या इस तरह की जांच आपकी मशीन को नली करेगी। अगर सब कुछ एक ही पेजिंग फ़ाइल पर लड़ रहा है, तो इससे चीजें बदतर हो जाती हैं।

2. मुझे जीसी में पीढ़ी से पीढ़ी तक बड़ी संख्या में डेटा को बढ़ावा दिया जा रहा है, साथ ही बड़ी संख्या में जीसी स्वीप \ संग्रह, और बड़ी संख्या में पृष्ठ दोषों के परिणामस्वरूप शारीरिक स्मृति सीमाएं पहुंच गई हैं। मैं केवल यह मान सकता हूं कि जब भौतिक स्मृति \ बहुत अधिक समाप्त हो जाती है, तो यह ट्रिगर्स पीढ़ी के झाड़ू और प्रचार को ट्रिगर करता है जिससे बड़ी मात्रा में पेज्ड-आउट मेमोरी को छुआ जा सकता है जिससे मृत्यु की सर्पिल हो जाती है क्योंकि स्पर्श स्मृति को पग किया जाता है और अन्य मेमोरी मजबूर किया गया है। पूरी चीज एक सूजी गड़बड़ी में समाप्त होता है। ऐसा लगता है कि बड़ी वस्तुएं लंबे समय तक रहने वाली वस्तुओं को आवंटित करती हैं जो छोटे ऑब्जेक्ट हीप में समाप्त होती हैं।

अब एक फैशन में वस्तुओं का आवंटन उन्हें बड़े वस्तु ढेर में सीधे आवंटित करेगा (जो एक ही व्यापक और बढ़ावा देने के मुद्दों कष्ट नहीं होता है) को यह तुलना:

private static void Main() 
{ 
    const int MaxNodeCount = 100000000; 
    const int LargeObjectSize = (85 * 1000); 

    LinkedList<byte[]> list = new LinkedList<byte[]>(); 

    for (long i = 0; i < MaxNodeCount; ++i) 
    { 
     list.AddLast(new byte[LargeObjectSize]); 

     if (i % 100000 == 0) 
     { 
      Console.WriteLine("{0:N0} 'approx' extra bytes allocated.", 
       ((i + 1) * LargeObjectSize)); 
     } 
    } 
} 

यह उम्मीद यानी रूप में काम करता वर्चुअल मेमोरी का उपयोग किया जाता है और फिर अंततः समाप्त हो जाता है - मेरे पर्यावरण \ 54 में 54 जीबी।

तो ऐसा प्रतीत होता है कि दीर्घकालिक छोटी वस्तुओं के द्रव्यमान को आवंटित करने से अंततः जीसी में एक दुष्चक्र का कारण बन जाएगा क्योंकि पीढ़ी के सफाई और प्रचार तब किए जाते हैं जब भौतिक स्मृति समाप्त हो जाती है - यह एक पृष्ठ-फ़ाइल मौत सर्पिल है।

अद्यतन 2

मुद्दा मैं विकल्पों में से एक नंबर \ विन्यास जो कोई सराहनीय फर्क पड़ा साथ खेला जांच कर रही जबकि:

• सर्वर जीसी मोड मजबूर।
• कम विलंबता जीसी को कॉन्फ़िगर करना।
• जीसी को अमूर्त करने की कोशिश करने के लिए जीसी को मजबूर करने के विभिन्न संयोजन।
• न्यूनतम \ अधिकतम प्रक्रिया कार्य सेट।