2009-04-29 3 views
12

का विकास और डिबगिंग मेरे पास एक सी # ऐप है जो 32-बिट लाइब्रेरी से लिंक होना चाहिए और अधिकतम मेमोरी संभव (इमेजिंग ऐप) का उपयोग करने की आवश्यकता है; हम XP64 डेस्कटॉप पर ऐप चलाते हैं, इस प्रकार हम WOW64 का उपयोग कर रहे हैं, x86 के लिए विजुअल स्टूडियो में लक्ष्यीकरण लक्ष्य बनाते हैं (और editbin /largeaddressaware पोस्ट-बिल्ड कर रहे हैं)। हम कुछ समस्याओं का सामना कर रहे हैं:मेम-होगिंग सी # ऐप्स

  • दृश्य स्टूडियो में निर्मित डिबगर, हम केवल कभी स्मृति के 2GB (~ एप्लिकेशन को 1.5gb, प्लस भूमि के ऊपर)

  • से चल रहा है उपयोग कर सकते हैं कमांड लाइन, ऐप 3 जीबी मेमोरी देख सकता है, लेकिन माइक्रोसॉफ्ट दस्तावेज कहेंगे कि हमें 4 जीबी देखना चाहिए।

किसी को मुझे बताओ कैसे पूर्ण 4GB कि मंच इसे देने के लिए सक्षम होना चाहिए देखने के लिए एक WOW64 सी # अनुप्रयोग पाने के लिए कर सकते हैं?

इसके अलावा, क्या कोई मुझे बता सकता है कि /largeaddressaware बिट का पालन करने के लिए विजुअल स्टूडियो (वीएस 2008, अन्यथा वीएस 9 0 के रूप में जाना जाता है) डीबगर कैसे प्राप्त करें और ऐप मेमोरी को 2 जीबी तक सीमित करना बंद करें?

मैं वीएस 80 और वीएस 9 0 में वही व्यवहार देखता हूं; .NET Framework 3.5, 3.0, और 2.0 के बीच भी कोई अंतर नहीं है। यहां एक छोटा सी # प्रोग्राम है जो समस्याओं को दिखाता है; x86, editbin /largeaddressaware के लिए निर्माण करें, फिर सी # के लिए उपलब्ध स्मृति में अंतर देखने के लिए कमांड लाइन से चलाए गए अंतर्निहित डीबगर बनाम चलाएं।

namespace MemoryAllocTest 
{ 
class Program 
{ 
    static void Main(string[] args) 
    { 
     const int allocSize = 1024 * 1024; 
     List<byte[]> myMem = new List<byte[]>(); 
     UInt64 totalAlloc = 0; 

     while (true) 
     { 
      myMem.Add(new byte[allocSize]); 
      totalAlloc += allocSize; 
      Console.WriteLine("{0} allocs: {1}MB total", 
      myMem.Count, totalAlloc/(1024 * 1024)); 
     } 
    } 
} 
} 
+0

क्या आप एमएसआईएल एक्सई फाइलों पर एडिटबिन चला सकते हैं? –

उत्तर

2

Microsoft से:

प्रक्रियाओं और अनुप्रयोगों के वर्चुअल ऐड्रेस स्पेस अभी भी 2 GB तक सीमित है जब तक/3GB स्विच ini फ़ाइल में प्रयोग किया जाता है। जब सिस्टम में भौतिक रैम 16 जीबी और से अधिक/3 जीबी स्विच का उपयोग किया जाता है, तो ऑपरेटिंग सिस्टम अतिरिक्त RAM को अनदेखा कर देगा जब तक कि/3 जीबी स्विच हटा नहीं जाता है। यह के बढ़ते आकार की वजह से कर्नेल को पृष्ठ तालिका प्रविष्टियों का समर्थन करने के लिए आवश्यक है। धारणा है कि व्यवस्थापक होगा बल्कि चुपचाप और स्वचालित रूप से/3 जीबी कार्यक्षमता खोना नहीं होगा; इसलिए, के लिए व्यवस्थापक को स्पष्ट रूप से इस सेटिंग को बदलने की आवश्यकता है। /3GB स्विच प्रक्रिया शीर्षक में IMAGE_FILE_LARGE_ADDRESS_AWARE का उपयोग करता है एक आवेदन करने के लिए वर्चुअल ऐड्रेस स्पेस के 3 जीबी आवंटित करता है। यह स्विच अनुप्रयोगों को 1 जीबी 2 जीबी से ऊपर अतिरिक्त वर्चुअल एड्रेस स्पेस को संबोधित करने की अनुमति देता है।

+0

/3 जीबी स्विच (4 जीटी ट्यूनिंग पैरा के रूप में जाना जाता है) 64-बिट ओएस के लिए लागू नहीं है। यह भी देखें: http://msdn.microsoft.com/en-us/library/aa366778.aspx –

2

क्या आप .NET का सटीक संस्करण उपयोग कर रहे हैं? This Connect report एक ही समस्या के बारे में है (जहां तक ​​मैं बता सकता हूं), .NET 2.0 पर देखा गया लेकिन .NET 2.0SP1 में तय किया गया।

अपने 64 मशीनों 2.0SP1 (या बाद में) पर है, यह एक कोशिश के लायक है नहीं है, तो ...

+0

पॉइंटर के लिए धन्यवाद - लेकिन कोई भाग्य नहीं! मेरे पास 3.5sp1 है और सभी संस्करण समर्थित/शामिल हैं (2.0, 3.0, 3.5) सभी 3 जीबी व्यवहार दिखाते हैं .... ड्रैट। –

+0

और उत्सुकता से, 3.5sp1 पर सभी महत्वपूर्ण एड-ऑन केबी फिक्स XP64 पर लागू नहीं होता है। –

1

आप पोस्ट कर सकते हैं जहां यह संकेत मिलता है कि आप सभी 4 जीबी देख सकते हैं?शायद यहाँ ऊह,: दिलचस्प जानकारी at this link

एड्रेसेबल मेमोरी में अंतर

पहली बात सबसे डेवलपर्स नोटिस कि 64 बिट प्रोसेसर शारीरिक और आभासी स्मृति की मात्रा में बड़ी छलांग प्रदान करना है यह संबोधित किया जा सकता है।

* 32-bit applications on 32-bit platforms can address up to 2 GB 
* 32-bit applications built with the /LARGEADDRESSAWARE:YES linker flag 
32-बिट Windows XP या Windows Server 2003 विशेष/3GB बूट विकल्प 3 जीबी तक पता कर सकते हैं के साथ पर

। यह कर्नेल को केवल 1 जीबी तक सीमित करता है जो कुछ ड्राइवरों और/या सेवाओं को असफल होने का कारण बन सकता है।

* 32-bit applications built with the /LARGEADDRESSAWARE:YES linker flag 
विंडोज विस्टा, के 32-बिट संस्करणों पर और ऑपरेटिंग सिस्टम विंडोज सर्वर कोड नाम "सूंडवाले" के 32-बिट संस्करण, पर

संख्या बूट विन्यास द्वारा निर्दिष्ट करने के लिए स्मृति को पता कर सकते हैं डेटा (बीसीडी) तत्व वृद्धि यूसरवा। IncreaseUserVa का मूल्य 2048, डिफ़ॉल्ट से 3072 तक है (जो से मेल खाता है जो /3 जीबी बूट विकल्प द्वारा Windows XP पर कॉन्फ़िगर किया गया है)। 4 जीबी का शेष कर्नेल को आवंटित किया गया है और परिणामस्वरूप ड्राइवर और सेवा कॉन्फ़िगरेशन विफल हो सकता है।

बीसीडी के बारे में अधिक जानकारी के लिए, एमएसडीएन पर बूट कॉन्फ़िगरेशन डेटा देखें।

* 32-bit applications on 64-bit platforms can address up to 2 GB, or up 

4 जीबी/LARGEADDRESSAWARE के साथ 4 जीबी: हाँ लिंकर ध्वज। * 64-बिट अनुप्रयोगों को संबोधित करने के लिए 43 बिट्स का उपयोग करते हैं, जो 8 टीबी अनुप्रयोगों के लिए आभासी पता प्रदान करता है और 8 टीबी कर्नेल के लिए आरक्षित है।

तो हाँ, ऐसा प्रतीत होता है कि आपको (XP64 लक्ष्य पर) 4 जीबी देखने में सक्षम होना चाहिए।

2

मैंने पोस्ट से अपना सरल नमूना ऐप बनाया, इसे क्रैश किया और इसे WinDbg संलग्न किया।

!address -summary आपको प्रक्रिया के लिए प्रभावी उपयोगकर्ता मोड पता स्थान दिखाएगा।

0:003> !address -summary 
TEB fffdd000 in range fffdb000 fffde000 
TEB fffda000 in range fffd8000 fffdb000 
TEB fffd7000 in range fffd5000 fffd8000 
TEB fffaf000 in range fffad000 fffb0000 
ProcessParametrs 004c2b40 in range 004c0000 00535000 
Environment 004c1978 in range 004c0000 00535000 

-------------------- Usage SUMMARY -------------------------- 
    TotSize (  KB) Pct(Tots) Pct(Busy) Usage 
    e7d2e000 (3798200) : 90.56% 98.77% : RegionUsageIsVAD 
    1547b000 ( 348652) : 08.31% 00.00% : RegionUsageFree 
    2887000 ( 41500) : 00.99% 01.08% : RegionUsageImage 
    3ff000 ( 4092) : 00.10% 00.11% : RegionUsageStack 
      0 (  0) : 00.00% 00.00% : RegionUsageTeb 
    1c0000 ( 1792) : 00.04% 00.05% : RegionUsageHeap 
      0 (  0) : 00.00% 00.00% : RegionUsagePageHeap 
     1000 (  4) : 00.00% 00.00% : RegionUsagePeb 
      0 (  0) : 00.00% 00.00% : RegionUsageProcessParametrs 
      0 (  0) : 00.00% 00.00% : RegionUsageEnvironmentBlock 
     **Tot: ffff0000 (4194240 KB)** Busy: eab75000 (3845588 KB) 

-------------------- Type SUMMARY -------------------------- 
    TotSize (  KB) Pct(Tots) Usage 
    1547b000 ( 348652) : 08.31% : <free> 
    2aa3000 ( 43660) : 01.04% : MEM_IMAGE 
    1f6a000 ( 32168) : 00.77% : MEM_MAPPED 
    e6168000 (3769760) : 89.88% : MEM_PRIVATE 

-------------------- State SUMMARY -------------------------- 
    TotSize (  KB) Pct(Tots) Usage 
    db838000 (3596512) : 85.75% : MEM_COMMIT 
    1547b000 ( 348652) : 08.31% : MEM_FREE 
    f33d000 ( 249076) : 05.94% : MEM_RESERVE 

Largest free region: Base fbfc0000 - Size 03fed000 (65460 KB) 

Tot के आधार पर: ffff0000 (4,194,240 KB) हम प्रभावी उपयोगकर्ता मोड अंतरिक्ष के 4GB है।

इसके अलावा हमारा सबसे बड़ा फ्री ब्लॉक 65,460 केबी है जो दर्शाता है कि हमें और अधिक स्मृति आवंटित करने में सक्षम होना चाहिए।

5

किसी को मुझे बताओ कैसे दृश्य स्टूडियो (वी.एस. 2008, अन्यथा रूप में VS90 जाना जाता है)/LARGEADDRESSAWARE बिट का पालन करना और 2GB तक एप्लिकेशन स्मृति सीमित रोकने के लिए डिबगर प्राप्त करने के लिए कर सकते हैं?

    निर्माण घटनाओं टैब पर
  • , सेटअप editbin /largeaware $ (TargetPath) चलाने के लिए एक postbuild कदम
  • पर: दोनों परियोजना संपत्तियों में -

यह दो चरणों की आवश्यकता डीबग टैब, विजुअल स्टूडियो होस्टिंग को सक्षम करें प्रक्रिया

इन दो चरणों के साथ, आपका sa mple प्रोग्राम 3045MB

+0

डेव, इसके लिए धन्यवाद - 'सक्षम दृश्य स्टूडियो होस्टिंग प्रक्रिया' को अनचेक करने से वास्तव में ऐप 3 जीबी तक पहुंच गया था। लेकिन 4 जीबी तक अंतिम दूरी कैसे जाए ?! फिर से धन्यवाद! –

3

पर प्रतिक्रिया देने वाले सभी लोगों के लिए धन्यवाद; यह साइट वास्तव में चट्टानों!

लगता है कि हम वास्तव में WOW64 में 4 जीबी उपयोगकर्ता स्थान प्राप्त करते हैं, लेकिन ऐसा लगता है कि कचरा कलेक्टर ओवरहेड (या शायद सुरक्षा मार्जिन) प्रबंधित कोड द्वारा आवंटित स्मृति के रूप में कचरा कलेक्टर ओवरहेड (या शायद सुरक्षा मार्जिन) आकार में आता है। WOW64 (कमांड लाइन, LARGEADDRESSAWARE के साथ) पर मेरा परीक्षण ऐप चला रहा है, मुझे 3175MB का कुल आवंटन मिलता है; 4 जीटी पैरामीटर सेट के साथ एक WIN32 XP मशीन पर चल रहा है, मुझे 2857 एमबी के कुल आवंटन मिलते हैं: इसलिए अतिरिक्त उपयोगकर्ता-मोड मेमोरी का एक पूर्ण गग सी # ऐप स्तर पर केवल ~ 318MB की वृद्धि करता है!

(मैंने आवंटन इकाई आकार को आवंटित करने के लिए मेरे परीक्षण कार्यक्रम को संशोधित किया है, जब आवंटन विफल रहता है, और 'सामान्य' एप्लिकेशन की सीमा से थोड़ा आगे जाने के प्रयास में सामरिक रूप से कचरा संग्रह को कॉल करने के लिए कॉल भी शामिल किया गया है पकड़ने में सक्षम - अगर आप मुझे संशोधित कोड पोस्ट करना चाहते हैं तो यहां एक नोट ड्रॉप करें।)

वैसे भी, सभी को धन्यवाद; ऐसा लगता है कि सिस्टम सही तरीके से काम कर रहा है लेकिन प्रबंधित वातावरण की तुलना में प्रबंधित वातावरण को अतिरिक्त स्मृति से कम सुधार मिलता है।

+0

अंतिम नोट के रूप में, मैं उल्लेख करूंगा कि जब मैं LARGEADDRESSAWARE बिट को हटा देता हूं, तो मुझे WOW64 और XP32 दोनों पर 1.9 जीबी का कुल आवंटन मिलता है। तो उत्सुकता से, 2 जीबी उपयोगकर्ता मेमोरी से 3 जीबी उपयोगकर्ता मेमोरी में जाने से सी # अनुप्रयोग स्तर पर पूरा लाभ मिलता है, फिर भी 3 जीबी उपयोगकर्ता मेमोरी से 4 जीबी उपयोगकर्ता मेमोरी (WOW64 पर्यावरण) तक की चाल केवल सी # अनुप्रयोग स्तर ~ 320 एमबी का लाभ प्राप्त करती है। ... –