क्या Task Manager का "Memory" स्तंभ ऐप द्वारा आवंटित कुल मेमोरी दिखाता है?

नहीं। Task Manager में कई मेमोरी स्तंभ हैं — Working Set परिवार, Private Working Set परिवार, Commit Size और अन्य — और अर्थ इस पर निर्भर करता है कि आप कौन सी स्क्रीन और स्तंभ देख रहे हैं। Working Set वे पेज हैं जो अभी RAM में निवासी हैं; Private Bytes या Commit Size उस प्रोसेस का अपना कमिटेड परिमाण है। एक अकेले "Memory" स्तंभ को ऐप द्वारा आवंटित कुल क्षमता, या लीक के आकार के रूप में न पढ़ें।

Working Set और Private Bytes में क्या अंतर है?

Working Set उस प्रोसेस को दिखने वाले उन पेजों की मात्रा है जो अभी भौतिक RAM में निवासी हैं, जिनमें DLL कोड और मेमोरी-मैप्ड फ़ाइल जैसे साझायोग्य पेज शामिल हैं। Private Bytes केवल उसी प्रोसेस द्वारा प्रयुक्त कमिटेड मेमोरी की मात्रा है, चाहे वह अभी RAM में निवासी हो या नहीं। इसलिए दोनों कभी बराबर नहीं होते, और कोई एक हमेशा बड़ा भी नहीं रहता।

क्या Task Manager का "Committed 18/32GB" मतलब है कि 18GB पेज फ़ाइल पर लिखा गया?

नहीं। बायाँ अंक वह कुल commit है जिसे पूरा सिस्टम अभी पृष्ठांकित करने का वादा कर रहा है; दायाँ अंक वह commit छत है जिसे सिस्टम सहारा दे सकता है। छत मोटे तौर पर RAM प्लस पेज फ़ाइल से तय होती है, पर बायाँ कुल वास्तव में पेज फ़ाइल पर नहीं बैठा होता। अधिकांश कमिटेड पेज RAM में हैं, और कुछ कमिटेड पेजों को अभी तक भौतिक पेज मिला ही नहीं। वहीं EXE, DLL और मेमोरी-मैप्ड फ़ाइल जैसे पेज, जिन्हें मूल फ़ाइल से फिर लोड किया जा सकता है, Working Set जितना Private Commit नहीं बढ़ाते।

क्या खाली RAM होते हुए भी OutOfMemory हो सकता है?

हाँ। आवंटन भौतिक RAM के अलावा अन्य कारणों से भी विफल हो सकता है — 32-बिट प्रोसेस का वर्चुअल पता स्थान खत्म होना, आवश्यक आकार की सतत खाली पता श्रेणी का अभाव, सिस्टम commit छत, या Job Object व रनटाइम की अपनी सीमाएँ। विशेषकर 64-बिट Windows पर 32-बिट प्रोसेस आमतौर पर 2GB उपयोगकर्ता-मोड वर्चुअल पता स्थान तक सीमित है, जब तक वह Large Address Aware न हो।

क्या पेज फ़ाइल बंद करने से Windows तेज़ होता है?

सामान्य नियम के रूप में यह नहीं माना जा सकता। पेज फ़ाइल बंद करने से सिस्टम की commit छत गिरती है, अप्रयुक्त संशोधित पेज RAM से निकालना कठिन होता है, और क्रैश डंप कैसे कॉन्फ़िगर किए जा सकते हैं इस पर असर पड़ता है। पेज फ़ाइल का आकार शिखर commit charge और आवश्यक क्रैश डंप मापकर तय होना चाहिए — बिना आधार के बंद करने की सेटिंग नहीं।

क्या ऊँचा Page Faults/sec मतलब सिस्टम में मेमोरी कम है?

केवल इससे नहीं बताया जा सकता। पेज फॉल्ट में सॉफ्ट फॉल्ट शामिल हैं, जो RAM के Standby पेज या दूसरे प्रोसेस से साझा पेज से हल हो सकते हैं, और हार्ड फॉल्ट, जो डिस्क से पढ़ते हैं। Page Faults/sec अकेले देखने के बजाय Pages Input/sec, Page Reads/sec, Available MBytes, डिस्क विलंब और प्रसंस्करण समय को एक ही समयरेखा पर साथ देखें।

Windows का "मेमोरी उपयोग" वास्तव में क्या है? — Working Set, Private Bytes, Commit और पेज फ़ाइल सही पढ़ना

4 Aug 2026 01:00 · Go Komura · Windows, Windows विकास, मेमोरी प्रबंधन, Working Set, Private Bytes, Commit, पेज फ़ाइल, प्रदर्शन निगरानी, समस्या निवारण, Sysinternals

Task Manager किसी प्रोसेस की “Memory” 1.2GB दिखाता है। पर Process Explorer Working Set 1.5GB और Private Bytes 2.4GB दिखाता है, और VMMap का Size और बड़ा है। पूरे सिस्टम को देखें तो “Committed 19.6/31.8GB” लिखा है।

तो आखिर यह ऐप वास्तव में कितने गीगाबाइट मेमोरी उपयोग कर रहा है?

उत्तर यह है कि आपको कौन सा अंक देखना चाहिए यह इस पर निर्भर करता है कि आप वास्तव में क्या जानना चाहते हैं। अभी RAM में निवासी मात्रा जाननी हो, उस प्रोसेस को विशेष रूप से आवंटित मात्रा, वह मात्रा जिसका सिस्टम भविष्य में भी सहारा देने का वादा कर चुका है, या केवल आरक्षित वर्चुअल पतों की श्रेणी — मेट्रिक अलग होती है।

Windows मेमोरी मेट्रिक भ्रमित इसलिए करते हैं कि वे सभी एक ही शब्द “मेमोरी” के नीचे दिखते हैं, जबकि वास्तव में ये अलग अक्ष मापते हैं।

कितना पता स्थान उपयोग में है
कितना commit खपत हुआ है
क्या वह अभी भौतिक RAM में निवासी है
क्या पेज प्रोसेस-निजी है, या साझायोग्य
पूरा सिस्टम और कितना आवंटन सहारा दे सकता है

यह लेख Windows 10/11 और वर्तमान Windows Server पर बढ़ती ऐप मेमोरी या सिस्टम-व्यापी मेमोरी कमी जाँचने वालों के लिए है, और Working Set, Private Working Set, Private Bytes, Commit, Virtual Bytes, पेज फ़ाइल, Available तथा पेज फॉल्ट के संबंध एक चित्र में जोड़ता है।

.NET ऑब्जेक्ट क्यों एकत्र नहीं होते यह पता लगाने की प्रक्रिया “.NET में GC विलंब और मेमोरी लीक अलग करना” में विस्तार से है, और VMMap तथा Process Explorer का ठोस संचालन “Process Explorer / Handle / VMMap व्यवहार में” में है। यह लेख दोनों की पूर्वापेक्षा पर केंद्रित है: Windows OS पक्ष के अंक कैसे पढ़ें।

1. निष्कर्ष पहले

Working Set वे पेज हैं जो अभी RAM में निवासी हैं। इसमें न केवल प्रोसेस-निजी पेज शामिल हैं बल्कि वे पेज भी जो अन्य प्रोसेस से साझा हो सकते हैं, जैसे DLL कोड और मेमोरी-मैप्ड फ़ाइलें।¹
Private Working Set, Working Set का वह भाग है जो अभी केवल उसी प्रोसेस का है। “अभी यह प्रोसेस अकेले जो RAM घेर रहा है” का सन्निकटन है, पर ऐप द्वारा आवंटित कुल मात्रा नहीं।²
Private Bytes उस प्रोसेस का निजी commit परिमाण है। यह इस से अलग मेट्रिक है कि मेमोरी अभी RAM में निवासी है या नहीं। Win32 API संरचना का PagefileUsage क्षेत्र भी, वर्तमान Windows पर, प्रभावी रूप से वही Commit Charge दर्शाता है, और पेज फ़ाइल पर वास्तव में लिखे बाइट नहीं।²
Task Manager का “Committed X/Y” X को सिस्टम का वर्तमान कुल commit और Y को commit छत दिखाता है। X पेज फ़ाइल उपयोग नहीं है। Y मोटे तौर पर RAM प्लस पेज फ़ाइल से तय होता है।³
Reserve और Commit अलग चीजें हैं। केवल वर्चुअल पता श्रेणी Reserve करना उसे भविष्य के उपयोग के लिए अलग रखना है; वह RAM या commit छत की उतनी ही मात्रा नहीं खाता।⁴⁵
पेज फॉल्ट का मतलब आवश्यक रूप से डिस्क I/O नहीं। सॉफ्ट फॉल्ट RAM के भीतर हल हो सकते हैं, और हार्ड फॉल्ट पेज फ़ाइल, एक्ज़ीक्यूटेबल, मेमोरी-मैप्ड फ़ाइल आदि से पढ़ते हैं।¹⁶
मेमोरी लीक एक अकेले पाठ से नहीं, बल्कि वही भार दोहराने पर प्रवृत्ति से तय होता है। विशेषकर देखें कि प्रसंस्करण समाप्त होने के बाद भी Private Bytes और उसका विवरण सीढ़ी-सीढ़ी बढ़ता रहे और उसी स्थिर अवस्था में न लौटे।

एक वाक्य में: Working Set “अभी RAM में मात्रा” है, Private Bytes “इस प्रोसेस को विशेष रूप से वादा की गई मात्रा” है, और Commit “पूरे सिस्टम ने जो वादा किया” है।

flowchart TB
    accTitle: सही Windows मेमोरी मेट्रिक चुनना
    accDescr: कौन सी मेट्रिक देखें यह इस पर निर्भर करता है कि आप RAM निवास, प्रोसेस-निजी commit, सिस्टम-व्यापी commit, या वर्चुअल पता श्रेणी जानना चाहते हैं
    question["मेमोरी उपयोग के बारे में आप क्या जानना चाहते हैं"]
    question -->|अभी RAM में मात्रा| workingSet["Working Set"]
    question -->|प्रोसेस-निजी वादा की मात्रा| privateBytes["Private Bytes"]
    question -->|सिस्टम-व्यापी वादा की मात्रा| systemCommit["System Commit"]
    question -->|आरक्षित पता श्रेणी| virtualBytes["Virtual Bytes / Reserved"]
    workingSet --> resident["भौतिक RAM में निवास"]
    privateBytes --> privateCommit["प्रोसेस-निजी Commit"]
    systemCommit --> commitLimit["Commit Limit से तुलना"]
    virtualBytes --> addressSpace["वर्चुअल पता स्थान"]

चित्र 1: “मेमोरी ऊँची है” प्रेक्षण को पहले चार अलग प्रश्नों में तोड़ें।

2. “मेमोरी उपयोग” को चार अक्षों में बाँटना

शुरू में Windows मेमोरी को “एक छड़” नहीं, चार अक्षों पर सोचें।

flowchart TB
    accTitle: एक पेज वर्गीकृत करने के चार स्वतंत्र अक्ष
    accDescr: वर्चुअल पता अवस्था, कमिटेड पेज का बैकिंग, भौतिक RAM निवास, और अन्य प्रोसेस से साझायोग्यता अलग-अलग जाँचें
    page["एक पेज को चार अक्षों पर देखें"]
    page --> address["पता अवस्था"]
    address --> addressValues["Free / Reserved / Committed"]
    page --> backing["बैकिंग"]
    backing --> backingValues["Page-file-backed / File-backed"]
    page --> residentAxis["RAM निवास"]
    residentAxis --> residentValues["Resident / Not resident"]
    page --> sharing["साझायोग्यता"]
    sharing --> sharingValues["Private / Shareable"]

चित्र 2: एक ही पेज पर भी पता अवस्था, बैकिंग, निवास और साझायोग्यता स्वतंत्र तय होती हैं।

Mapped Free, Reserved और Committed के साथ एक पता अवस्था नहीं — वह क्षेत्र की श्रेणी है। मैप्ड व्यू के पेज भी Committed हो सकते हैं। इसी तरह Private बैकिंग माध्यम नहीं बल्कि साझायोग्यता का वर्गीकरण है। इसलिए बैकिंग को Page-file-backed या File-backed, और साझायोग्यता को Private या Shareable, अलग पढ़ें।

इन चार अक्षों को मिलाकर प्रतिनिधि मेट्रिक का संबंध इस प्रकार है।

पेज अवस्था	Working Set	Private Working Set	Private Bytes	Virtual Bytes परिवार
प्रोसेस-निजी, कमिटेड, RAM-निवासी	शामिल	शामिल	शामिल	शामिल
प्रोसेस-निजी, कमिटेड, RAM-अनिवासी	शामिल नहीं	शामिल नहीं	शामिल	शामिल
DLL या मैप्ड फ़ाइल का साझा पेज, RAM-निवासी	शामिल	सामान्यतः शामिल नहीं	सामान्यतः शामिल नहीं	शामिल
आरक्षित पर कमिटेड नहीं	शामिल नहीं	शामिल नहीं	शामिल नहीं	शामिल हो सकता है
अप्रयुक्त पता श्रेणी	शामिल नहीं	शामिल नहीं	शामिल नहीं	आमतौर पर शामिल नहीं

flowchart TB
    accTitle: पेज प्रकारों का मुख्य मेमोरी मेट्रिक से मानचित्र
    accDescr: निवासी निजी पेज, अनिवासी निजी पेज, निवासी साझा पेज और केवल-आरक्षित श्रेणी किन मेट्रिक में आते हैं
    privateResident["निजी, कमिटेड, RAM-निवासी"]
    privateNonresident["निजी, कमिटेड, RAM-अनिवासी"]
    sharedResident["साझा पेज, RAM-निवासी"]
    reservedOnly["आरक्षित, कमिटेड नहीं"]
    workingSet["Working Set"]
    privateWorkingSet["Private Working Set"]
    privateBytes["Private Bytes"]
    virtualBytes["Virtual Bytes परिवार"]
    privateResident --> workingSet
    privateResident --> privateWorkingSet
    privateResident --> privateBytes
    privateResident --> virtualBytes
    privateNonresident --> privateBytes
    privateNonresident --> virtualBytes
    sharedResident --> workingSet
    sharedResident --> virtualBytes
    reservedOnly --> virtualBytes

चित्र 3: Working Set और Private Bytes अलग पेज समूह गिनते हैं, इसलिए सरल अंतर्वेशन नहीं।

यहाँ महत्वपूर्ण यह है कि Working Set और Private Bytes सरल अंतर्वेशन संबंध में नहीं हैं।

Private Bytes में वे पेज शामिल हैं जो प्रोसेस-निजी हैं पर अभी RAM में निवासी नहीं। दूसरी ओर Working Set में साझा पेज — DLL कोड और साझा मेमोरी — शामिल हैं जिन्हें Private Bytes गिनता ही नहीं। इसलिए प्रोसेस और क्षण के अनुसार Working Set Private Bytes से बड़ा हो सकता है, या उलटा।

साथ ही कई प्रोसेस के Working Set जोड़ने से वही भौतिक पेज — जैसे साझा DLL — एक से अधिक बार गिना जा सकता है। “हर प्रोसेस के Working Set का योग = उपयोग में RAM” आवश्यक रूप से सत्य नहीं।

3. वर्चुअल पता स्थान — Reserve और Commit अलग चीजें हैं

3.1. वर्चुअल पता भौतिक RAM पता नहीं है

हर प्रोसेस का अपना निजी वर्चुअल पता स्थान होता है। ऐप जो पॉइंटर सँभालता है वह सीधे भौतिक RAM स्थान नहीं दर्शाता; Windows पेज टेबल से वर्चुअल पते को भौतिक पेज या फ़ाइल पर डेटा से जोड़ता है।⁷

इसका परिणाम: 64GB RAM लगे PC पर भी किसी 32-बिट प्रोसेस का वर्चुअल पता स्थान आमतौर पर उससे बहुत छोटा होता है। उलटा, 64-बिट प्रोसेस का वर्चुअल पता स्थान भौतिक RAM से बड़ा होना भी सामान्य है।

3.2. Reserved का मतलब केवल “पता आरक्षित कर लिया”

VirtualAlloc का MEM_RESERVE भविष्य के उपयोग के लिए सतत वर्चुअल पता श्रेणी आरक्षित करता है। इस चरण में पेजों से कोई भौतिक संग्रह जुड़ा नहीं, और श्रेणी पढ़ी-लिखी नहीं जा सकती।⁴⁵

उदाहरण के लिए डेटाबेस या रनटाइम भविष्य की वृद्धि के लिए 8GB पता श्रेणी Reserve करे तो भी केवल इससे 8GB RAM या 8GB Private Bytes नहीं खर्च होते।

3.3. Committed “जरूरत पड़ने पर सहारा देने” का वादा है

MEM_COMMIT वह क्रिया है जो वर्चुअल पेज को Committed अवस्था में लाती है और Windows से आवश्यक बैकिंग देने का वादा करवाती है। पढ़ना, लिखना या निष्पादन वास्तव में अनुमत है या नहीं, यह पेज सुरक्षा — PAGE_READONLY, PAGE_READWRITE, PAGE_EXECUTE, PAGE_NOACCESS आदि — अलग तय करती है, इसलिए Committed होना स्वयं “पढ़ने-लिखने योग्य” नहीं है। कमिट होते ही सिस्टम के Commit Charge में गिना जाता है, पर वास्तविक भौतिक पेज पहली पहुँच तक न सौंपा जाए। पहली बार छुआ पेज शून्य-आरंभ होता है, demand-zero fault से गुजरता है, और Working Set में आता है।⁵¹

इसलिए “आवंटित” कहने पर भी वास्तव में ये तीन चरण हैं।

flowchart TB
    accTitle: Reserve से Commit और RAM निवास तक तीन चरण
    accDescr: वर्चुअल पता आरक्षित करना, पेज कमिट करना, और पहली पहुँच पर भौतिक पेज सौंपकर Working Set में आने का प्रवाह
    reserve["MEM_RESERVE - पता श्रेणी आरक्षित"]
    reserve -.-> virtualMetric["Virtual Bytes परिवार में झलकता"]
    reserve -->|MEM_COMMIT| committed["Committed - पेज सुरक्षा के अनुसार पहुँचयोग्य"]
    committed -.-> commitMetric["Private Bytes / System Commit में झलकता"]
    committed -->|पहली पहुँच, demand-zero fault| resident["भौतिक पेज सौंपा, RAM-निवासी"]
    resident -.-> workingSetMetric["Working Set में झलकता"]
    committed -.->|कभी पहुँच न हो तो| nonresident["कमिटेड पर निवासी नहीं"]

चित्र 4: Reserve, Commit और पहली पहुँच अलग घटनाएँ हैं, और प्रत्येक अलग मेट्रिक हिलाती है।

ये तीन चरण क्रमशः Virtual Bytes परिवार, Private Bytes और Working Set के अंक अलग-अलग हिलाते हैं।

3.4. खाली RAM होते हुए भी OutOfMemory क्यों होता है

मेमोरी आवंटन सफल है या नहीं, यह केवल खाली RAM से तय नहीं होता।

प्रोसेस ने अपना वर्चुअल पता स्थान खत्म कर दिया
आवश्यक आकार की सतत खाली पता श्रेणी नहीं
सिस्टम-व्यापी Commit Charge Commit Limit तक पहुँच गया
Job Object, कंटेनर, रनटाइम या लाइब्रेरी की अपनी सीमा है
वह 32-बिट प्रोसेस है
नेटिव हीप खंडित है

64-बिट Windows पर भी 32-बिट प्रोसेस का उपयोगकर्ता-मोड वर्चुअल पता स्थान, IMAGE_FILE_LARGE_ADDRESS_AWARE न सेट हो तो आमतौर पर 2GB है। वह ध्वज सेट 32-बिट ऐप 64-बिट Windows पर 4GB तक उपयोग कर सकता है।⁸

इसलिए “PC में 20GB खाली RAM है, फिर भी 32-बिट ऐप लगभग 1.6GB पर विफल” विरोधाभास नहीं। यह RAM समस्या न होकर पता स्थान खंडन या कठोर सीमा हो सकती है।

4. Working Set — अभी RAM में पेज

Working Set प्रोसेस के वर्चुअल पता स्थान में वे पेज हैं जो अभी भौतिक RAM में निवासी हैं।¹

इस समूह में ये मिले-जुले हैं।

प्रोसेस का अपना हीप और स्टैक
EXE और DLL कोड तथा केवल-पढ़ने डेटा
मेमोरी-मैप्ड फ़ाइलें
साझा मेमोरी
copy-on-write के बाद उस प्रोसेस के निजी बने पेज
रनटाइम और विभिन्न लाइब्रेरी द्वारा छुए पेज

4.1. बढ़ता Working Set जरूरी नहीं कि अधिक आवंटन हो

पहले से कमिटेड पेज पर पहली पहुँच Working Set अकेले बढ़ा सकती है जबकि Private Bytes अपरिवर्तित रहे। बड़े फ़ाइल को मेमोरी-मैप कर क्रम से पढ़ने पर भी फ़ाइल-बैक्ड पेज Working Set में आते हैं और Private Bytes लगभग नहीं बढ़ता।

उलटा, Windows मेमोरी दबाव पर Working Set Trim करे तो Working Set अकेला सिकुड़ता है जबकि ऐप तार्किक रूप से वही मेमोरी रखता है। बाद में फिर छूने पर पेज फॉल्ट से लौटता है।

इसलिए Working Set गिरना जरूरी नहीं “ऐप ने मुक्त किया”, और बढ़ना जरूरी नहीं “ऐप ने नया आवंटित किया”।

flowchart TB
    accTitle: केवल Working Set के उठने-गिरने का विशिष्ट प्रवाह
    accDescr: वही कमिटेड पेज पहली पहुँच पर RAM में आता है, Trim पर अनिवासी होता है, पुनः पहुँच पर लौटता है, जबकि Private Bytes पूरे समय गिना जाता रहता है
    committed["वही कमिटेड पेज"]
    committed -->|पहली पहुँच| resident["RAM-निवासी"]
    resident -->|मेमोरी दबाव पर Trim| nonresident["निवासी नहीं"]
    nonresident -->|पुनः पहुँच पर पेज फॉल्ट| resident
    resident -.-> inWorkingSet["Working Set में शामिल"]
    nonresident -.-> outsideWorkingSet["Working Set में शामिल नहीं"]
    committed -.-> privateBytes["कमिटेड रहते Private Bytes में गिना"]

चित्र 5: Working Set निवास के साथ उठता-गिरता है, पर उसी पेज का commit रहते Private Bytes नहीं घटता।

4.2. Working Set में साझा पेज शामिल हैं

यदि 10 प्रोसेस एक ही DLL के कोड पेज साझा करें, वह पेज प्रत्येक के Working Set में दिख सकता है, जबकि भौतिक RAM पर केवल एक प्रति है। Working Set योग स्थापित RAM से अधिक हो तो तुरंत समस्या नहीं।

“अभी यह प्रोसेस अकेले जो RAM घेर रहा है” के निकट जाना हो तो Private Working Set देखें। फिर भी यह “उस प्रोसेस ने जो सारी मेमोरी आवंटित की” नहीं — यह सख्ती से अभी निवासी निजी पेज है।

4.3. Working Set जबरन घटाने से लीक नहीं सुधरता

EmptyWorkingSet या SetProcessWorkingSetSize से प्रोसेस के Working Set से पेज निकाले जा सकते हैं। पर यह commit मुक्त करने या हीप संदर्भ छोड़ने की क्रिया नहीं। दिखने वाला RAM उपयोग गिरता है जबकि Private Bytes अपरिवर्तित रहता है, और अगली पहुँच पेज फॉल्ट की झड़ी ला सकती है।⁹

यदि Task Manager का अंक केवल “मेमोरी घटाएँ” बटन दबाने के तुरंत बाद सिकुड़े और काम फिर शुरू करते ही चढ़ जाए, तो यह वास्तविक “मुक्ति” नहीं, केवल Working Set Trim हो सकता है।

5. Private Bytes — प्रोसेस का निजी commit परिमाण

Private Bytes उस प्रोसेस के लिए विशेष रूप से कमिटेड वर्चुअल मेमोरी की मात्रा है। यह वह Commit Charge है जो दूसरे प्रोसेस से साझा नहीं हो सकता, और अभी RAM में निवासी है या नहीं इससे फर्क नहीं पड़ता। Microsoft की PROCESS_MEMORY_COUNTERS_EX में PrivateUsage इसी मान के अनुरूप है।¹⁰²

Win32 API में भ्रमित करने वाला क्षेत्र PagefileUsage भी है, पर वर्तमान दस्तावेज़ इसे “उस प्रोसेस का Commit Charge” परिभाषित करता है और कहता है कि यह PrivateUsage के बराबर है। अर्थात् 2GB Private Bytes का मतलब “pagefile.sys पर 2GB लिखा गया” नहीं है।²

Private Bytes पर आमतौर पर ये असर डालते हैं।

HeapAlloc, malloc, new आदि द्वारा प्रयुक्त नेटिव हीप का commit
VirtualAlloc से सीधे कमिटेड Private Data
.NET GC हीप का कमिटेड क्षेत्र
थ्रेड स्टैक का वह भाग जो वास्तव में कमिटेड है
copy-on-write व्यू (FILE_MAP_COPY) मैप करते समय पूरे व्यू के लिए आरक्षित Commit Charge
लाइब्रेरी और डिवाइस SDK द्वारा आंतरिक रूप से रखे निजी बफ़र

FILE_MAP_COPY से बने copy-on-write व्यू में हर पेज अंततः निजी हो सकता है, इसलिए मैपिंग समय Windows पूरे व्यू को पेज फ़ाइल से सहारा देने जितना Commit Charge आरक्षित करता है। इसलिए कोई लेखन निजी प्रति बनाए उससे पहले ही System Commit और प्रोसेस का Commit Charge (Private Bytes) पूरे व्यू जितना बढ़ सकता है।¹¹

5.1. `free` या GC के बाद Private Bytes क्यों नहीं गिरता

ऐप की दृष्टि से मेमोरी “मुक्त” होने पर भी रनटाइम या हीप आवंटक वह क्षेत्र OS को Decommit न कर भविष्य के पुनः उपयोग के लिए रख सकता है। तब ऐप के भीतर पुनः उपयोग योग्य होते हुए भी Private Bytes ऊँचा रहता है।

यह ऊँचा इसलिए भी रह सकता है कि बड़े क्षेत्र का केवल भाग जीवित है, खंडन है, या कैश/पूल अपनी छत तक गर्म हो चुका है।

इसलिए ऊँचा Private Bytes अकेले लीक सिद्ध नहीं करता। देखना चाहिए समय के साथ तुलना:

वही प्रसंस्करण उतनी ही बार दोहराएँ
प्रसंस्करण के बाद उतना ही समय प्रतीक्षा करें
जाँचें कि Private Bytes उसी स्तर पर लौटता है, या स्थिर मान पर थम जाता है
VMMap या हीप डंप से देखें कौन सा क्षेत्र या प्रकार बढ़ा

flowchart TB
    accTitle: free या GC के बाद Private Bytes न गिरने का कारण
    accDescr: आवंटक ऐप की अब-अनावश्यक क्षेत्र OS को लौटाए या पुनः उपयोग के लिए रखे, इस पर Private Bytes अलग बदलता है
    release["ऐप free / GC से क्षेत्र मुक्त करता है"]
    release --> decision{"क्या आवंटक इसे OS को लौटाता है"}
    decision -->|Decommit / Release| returned["Commit Charge घटता है"]
    returned --> lower["Private Bytes गिरता है"]
    decision -->|पुनः उपयोग के लिए रखता है| retained["क्षेत्र कमिटेड रहता है"]
    retained --> high["Private Bytes ऊँचा थमता है"]
    retained --> reasons["पूल, कैश, खंडन"]

चित्र 6: ऐप के भीतर पुनः उपयोग योग्य होना और उसका Commit OS को लौटना एक नहीं।

5.2. लीक का मजबूत उम्मीदवार पैटर्न

नीचे जैसा वृद्धि, जहाँ हर भार चक्र पर फर्श “सीढ़ी” की तरह ऊपर चढ़े, ध्यान देने योग्य है।

Private Bytes
  ^
  |                    ________
  |             ______|
  |      ______|
  |_____|
  +----------------------------> उसी प्रसंस्करण की पुनरावृत्ति

फिर भी सीढ़ी आकार पहली बार JIT, फ़ॉन्ट, छवि डिकोडर, कनेक्शन पूल या कैश वार्म-अप की कुछ चक्र वृद्धि हो सकती है, जिसके बाद स्थिर हो। महत्व बढ़ने का नहीं, स्थिर अवस्था में न समाहित होने का है।

6. System Commit — “Committed X/Y” वास्तव में क्या है

Task Manager के [Performance] → [Memory] टैब पर “Committed X/Y” सिस्टम-व्यापी मेट्रिक है।

X: System Commit Charge — वह कमिटेड मेमोरी जिसका Windows अभी पूरे सिस्टम में सहारा देने का वादा कर रहा है
Y: System Commit Limit — वह छत जिसे सिस्टम सहारा दे सकता है

Commit Limit मोटे तौर पर भौतिक RAM प्लस सभी पेज फ़ाइलों के योग से तय होता है। पेज फ़ाइल न हो तो स्थापित RAM से थोड़ा छोटा निकलता है।³⁶

flowchart TB
    accTitle: System Commit Charge और Commit Limit का संबंध
    accDescr: प्रति-प्रोसेस, साझा सेक्शन और कर्नेल commit वर्तमान मान X बनाते हैं, भौतिक RAM और पेज फ़ाइल छत Y सहारा देते हैं
    processCommit["हर प्रोसेस का Private Commit"] --> charge["System Commit Charge - X"]
    sharedCommit["पेज फ़ाइल से बैक्ड साझा सेक्शन का Commit"] --> charge
    kernelCommit["कर्नेल Commit"] --> charge
    physicalRam["भौतिक RAM"] --> limit["System Commit Limit - Y"]
    pageFiles["पेज फ़ाइल"] --> limit
    charge -->|X, Y से अधिक नहीं हो सकता| limit

चित्र 7: X वर्तमान वादा की मात्रा है और Y वह छत जो उस वादे को सहारा दे सकती है — यह पेज फ़ाइल उपयोग का प्रदर्शन नहीं।

System Commit Charge में हर प्रोसेस के Private Bytes का योग ही नहीं, पेज-फ़ाइल-बैक्ड साझा सेक्शन का Commit और कर्नेल द्वारा खपत Commit भी शामिल है। इसलिए प्रति-प्रोसेस Private Bytes का योग अकेले X पूरी तरह नहीं समझाता।

6.1. Commit Charge पेज फ़ाइल उपयोग नहीं है

16GB RAM, 16GB पेज फ़ाइल, और Committed 20/31GB वाले सिस्टम पर विचार करें।

वह 20GB मतलब “पेज फ़ाइल पर 20GB लिखा” नहीं। यह वह कुल है जिसका Windows निजी लिखने योग्य पेज आदि के लिए, जरूरत पड़ने पर, RAM या पेज फ़ाइल बैकिंग देने का वादा कर रहा है।

उस क्षण ये अवस्थाएँ मिली हो सकती हैं:

अधिकांश RAM में निवासी है
कुछ पेज फ़ाइल पर पेज-आउट है
कुछ कमिटेड है पर पहली पहुँच अभी नहीं हुई
कुछ कर्नेल पक्ष के commit के रूप में खपत है

वास्तविक पेज फ़ाइल उपयोग देखना हो तो Commit से अलग Paging File(*)\% Usage जाँचें। Microsoft की अपनी सामग्री भी कहती है कि ऊँचा पेज फ़ाइल उपयोग अकेले प्रदर्शन समस्या नहीं, और इसे Commit Limit पहुँचने, Modified Page List और वास्तविक पेजिंग I/O के साथ जाँचना चाहिए।⁶

6.2. Commit Limit के निकट क्या होता है

System Commit Charge Commit Limit तक पहुँचे तो नए commit अनुरोध सहारे नहीं जा सकते। इससे प्रोसेस मेमोरी आवंटन विफलता, ऐप क्रैश और सिस्टम अनुत्तरदायी होना आता है।³

यहाँ “खाली RAM” से अधिक Commit का X/Y मायने रखता है। Working Set Trim कर RAM खाली करने पर भी Commit Charge स्वयं न घटे तो Commit Limit पहुँचना हल नहीं होता।

6.3. पेज फ़ाइल की तीन भूमिकाएँ

पेज फ़ाइल मुख्यतः ये भूमिकाएँ निभाती है।

Commit Limit बढ़ाना
कम उपयोग वाले संशोधित पेज RAM से पेज-आउट होने देना
कॉन्फ़िगरेशन के अनुसार सिस्टम क्रैश डंप सहारा देना

पेज फ़ाइल बंद करना सरल मामला नहीं कि “डिस्क I/O हमेशा घटे और सब तेज़ हो”। बल्कि यह Commit Limit गिराता है, संशोधित पर अभी अनावश्यक पेज RAM में रहने देता है, और क्रैश पर आवश्यक डंप लेना असंभव बना सकता है।³⁶

उपयुक्त पेज फ़ाइल आकार स्थापित RAM अकेले से तय नहीं होता। Microsoft स्वयं कहता है कि इसे सामान्यीकृत नहीं किया जा सकता, क्योंकि शिखर System Commit Charge और आवश्यक क्रैश डंप का प्रकार सिस्टम-से-सिस्टम भिन्न है।⁶

7. भौतिक RAM का विवरण — केवल कम Available से निर्णय न करें

भौतिक RAM केवल उपयोगकर्ता प्रोसेस के Working Set से नहीं भरता।

हर प्रोसेस का Working Set
सिस्टम फ़ाइल कैश
Standby, Modified, Free, Zeroed जैसी पेज सूचियाँ
कर्नेल का Paged Pool / Nonpaged Pool
डिवाइस ड्राइवर द्वारा रखी मेमोरी
मेमोरी संपीड़न स्टोर
GPU और अन्य डिवाइस से साझा या उनके लिए आरक्षित क्षेत्र
हार्डवेयर-आरक्षित मेमोरी

7.1. Available में पुनः उपयोग योग्य कैश भी है

Windows का Available MBytes केवल पूरी तरह अप्रयुक्त RAM नहीं। यह मेट्रिक Free और Zeroed के साथ उन Standby पेजों को भी शामिल करती है जिन्हें जरूरत पर पुनः उपयोग किया जा सकता है।¹²

Free: पेज जो अभी किसी उद्देश्य को आवंटित नहीं
Zeroed: पेज जिन्हें दूसरे प्रोसेस को सुरक्षित सौंपने के लिए शून्य किया गया
Standby: पेज जो Working Set छोड़ चुके पर सामग्री अभी RAM में कैश है
Modified: पेज जिनकी सामग्री बदली और पुनः उपयोग से पहले उपयुक्त बैकिंग पर लिखना आवश्यक है

flowchart TB
    accTitle: Working Set और पेज सूचियों के बीच आवाजाही
    accDescr: अपरिवर्तित पेज Standby पर और संशोधित पेज Modified पर जाते हैं, फिर पुनः पहुँच, लेखन-वापसी और पुनः उपयोग
    workingSet["Working Set - उपयोग में"]
    workingSet -->|अपरिवर्तित पेज हटाया| standby["Standby - सामग्री सहित पुनः उपयोग उम्मीदवार"]
    workingSet -->|संशोधित पेज हटाया| modified["Modified - लेखन-वापसी की प्रतीक्षा"]
    modified -->|लेखन-वापसी पूर्ण| standby
    standby -->|पुनः पहुँच| workingSet
    standby -->|अन्य उद्देश्य के लिए पुनः उपयोग| reused["अन्य उद्देश्य को आवंटित"]
    free["Free - अप्रयुक्त"] -->|शून्य किया| zeroed["Zeroed - नए आवंटन के लिए उपलब्ध"]
    zeroed -->|आवंटन के बाद पहुँच| workingSet
    standby -.-> available["Available में शामिल"]
    free -.-> available
    zeroed -.-> available

चित्र 8: Available में पूरी तरह खाली मेमोरी ही नहीं, जरूरत पर पुनः उपयोग योग्य Standby भी शामिल है।

“खाली RAM बढ़ाने के लिए सारा कैश फेंकना” हमेशा लाभ नहीं। जरूरी डेटा Standby पर हो तो पुनः पहुँच डिस्क पढ़े बिना शीघ्र Working Set में लौटा सकती है।

इसलिए Task Manager में Free कम हो पर Available पर्याप्त हो और हार्ड पेज फॉल्ट या डिस्क प्रतीक्षा समस्या न बनें, तो Windows RAM को कैश के रूप में प्रभावी उपयोग कर रहा हो सकता है।

7.2. जब कोई बड़ा प्रोसेस न हो फिर भी RAM घटे

हर प्रोसेस के Private Working Set जोड़ने पर भी अस्पष्टीकृत मेमोरी खपत असामान्य नहीं।

फ़ाइल कैश और मेमोरी-मैप्ड फ़ाइलें
Nonpaged Pool / Paged Pool
ड्राइवर द्वारा लॉक पेज
साझा पेज
मेमोरी संपीड़न
वर्चुअलाइज़ेशन या GPU संबंधित आवंटन

इस स्थिति में प्रोसेस सूची घूरते रहने के बजाय Sysinternals के RAMMap में Use Counts, Processes, Priority Summary और File Summary देखें। RAMMap भौतिक मेमोरी को उद्देश्य, पेज सूची और फ़ाइल के अनुसार तोड़ने का आधिकारिक उपकरण है।¹³

यदि केवल Nonpaged Pool बढ़ता रहे, तो उपयोगकर्ता-मोड ऐप के Private Bytes के बजाय ड्राइवर या कर्नेल पक्ष लीक संदेह का समय है।

8. पेज फॉल्ट — ऊँची संख्या स्वयं असामान्य नहीं

Page Fault तब होता है जब प्रोसेस ऐसे पेज पर पहुँचे जो अभी उसके Working Set में नहीं। नाम में “Fault” होने पर भी यह असाधारण विफलता नहीं — वर्चुअल मेमोरी चलाने की सामान्य व्यवस्था है।¹

8.1. सॉफ्ट पेज फॉल्ट

ये डिस्क पढ़े बिना हल होते हैं।

पेज अभी Standby या Transition में है
वही साझा पेज दूसरे प्रोसेस के Working Set में पहले से है
कमिटेड पेज पर पहली पहुँच और शून्य पेज सौंपा जाना
मेमोरी मैनेजर की आगे-पढ़ पहले ही उसे RAM में ला चुकी

इसलिए बड़ा \Memory\Page Faults/sec जरूरी नहीं कि डिस्क I/O या विलंब हो रहा हो।

8.2. हार्ड पेज फॉल्ट

इनमें डिस्क पर Backing Store से सामग्री पढ़नी पड़ती है। स्रोत केवल पेज फ़ाइल नहीं।

.exe या .dll का कोड और डेटा
मेमोरी-मैप्ड फ़ाइल
पेज फ़ाइल

flowchart TB
    accTitle: सॉफ्ट और हार्ड पेज फॉल्ट की शाखा
    accDescr: Working Set में न होने वाले पेज पर पहुँचने पर संग्रहण I/O अनावश्यक हो तो सॉफ्ट, आवश्यक हो तो हार्ड पेज फॉल्ट
    access["Working Set में न होने वाले पेज पर पहुँच"] --> storageIo{"क्या संग्रहण I/O चाहिए"}
    storageIo -->|नहीं - Standby, साझा, demand-zero आदि| soft["सॉफ्ट पेज फॉल्ट"]
    soft --> resident["डिस्क पढ़े बिना Working Set में आता"]
    storageIo -->|हाँ| hard["हार्ड पेज फॉल्ट"]
    hard --> source{"कहाँ से पढ़ा जाता है"}
    source --> image["EXE / DLL"]
    source --> mapped["मेमोरी-मैप्ड फ़ाइल"]
    source --> pagefile["पेज फ़ाइल"]
    image --> loaded["लोड के बाद Working Set में"]
    mapped --> loaded
    pagefile --> loaded

चित्र 9: केवल “Page Fault” नाम से डिस्क I/O हुआ या नहीं नहीं बताया जा सकता।

Microsoft हार्ड फॉल्ट मापने के काउंटरों में \Memory\Pages/sec, \Memory\Page Reads/sec और \Memory\Pages Input/sec गिनाता है। ये ऊँचे हों तो भी मेमोरी कम होना जरूरी नहीं, इसलिए Available MBytes, डिस्क विलंब और वास्तविक प्रतिक्रिया समय से सहसंबंधित करें।⁶

8.3. एक ही कंबल सीमा न लगाएँ

“1000 Page Faults/sec से ऊपर असामान्य” जैसा स्थिर मान संग्रहण, पेज आकार, कार्यभार और पहुँच स्थानीयता से अर्थ बदलता है।

व्यवहार में इन्हें एक ही समयरेखा पर रखें।

Memory\Available MBytes
Memory\Pages Input/sec
Memory\Page Reads/sec
लक्ष्य डिस्क पर Read latency / Queue
लक्ष्य प्रोसेस का Working Set और Private Bytes
ऐप का प्रसंस्करण समय, टाइमआउट और UI प्रतिक्रिया

भार बढ़ने के साथ Available गिरे, Pages Input/sec और डिस्क प्रतीक्षा बढ़े, और प्रसंस्करण समय भी बिगड़े, तो भौतिक मेमोरी दबाव से पेजिंग का संदेह आधार मिलता है।

9. कौन सी स्क्रीन या उपकरण किसके लिए

आप क्या जानना चाहते हैं	पहले देखने योग्य मेट्रिक	मुख्य उपकरण
लक्ष्य प्रोसेस अभी RAM में कितना रखता है	Working Set	Task Manager, Process Explorer, `Get-Process`
उसका निजी भाग — प्रोसेस-निजी RAM	Private Working Set / Working Set - Private	Task Manager Details स्तंभ, Process Explorer, PerfMon
लक्ष्य प्रोसेस का निजी commit	Private Bytes / Commit Size	Process Explorer, PerfMon, VMMap, `Get-Process`
प्रोसेस की वर्चुअल पता श्रेणी	Virtual Bytes / Size	Process Explorer, VMMap, `Get-Process`
सिस्टम का कुल commit अवशेष	Committed Bytes / Commit Limit	Task Manager [Performance], PerfMon
भौतिक RAM का पुनः उपयोग अवशेष	Available MBytes	Task Manager, PerfMon
Standby, Modified और फ़ाइल कैश का विवरण	पेज सूची / उद्देश्य विवरण	RAMMap
Private Bytes में क्या बढ़ा	Heap / Private Data / Managed Heap आदि	VMMap, WinDbg, रनटाइम-विशिष्ट डंप
डिस्क सहित पेजिंग	Pages Input/sec, Page Reads/sec, डिस्क विलंब	PerfMon, WPR/WPA

flowchart TB
    accTitle: Windows मेमोरी जाँच उपकरण चुनना
    accDescr: लक्ष्य एक प्रोसेस है या पूरा सिस्टम, एक क्षण या समय श्रृंखला, और रनटाइम के भीतर धारण खोजना है या नहीं, इस पर उपकरण निर्भर करता है
    question["आप क्या अलग करना चाहते हैं"]
    question --> processScope{"क्या लक्ष्य एक प्रोसेस है"}
    processScope -->|हाँ| processTime{"एक क्षण या समय श्रृंखला"}
    processTime -->|एक-क्षण विवरण| vmmap["VMMap"]
    processTime -->|समय श्रृंखला| perfmon["PerfMon / PowerShell"]
    processScope -->|पूरा सिस्टम| systemView{"भौतिक RAM विवरण या समयरेखा"}
    systemView -->|भौतिक RAM विवरण| rammap["RAMMap"]
    systemView -->|CPU, I/O और प्रतीक्षा सहित समयरेखा| wpa["WPR / WPA"]
    question --> runtime{"क्या रनटाइम के भीतर धारण खोजना है"}
    runtime -->|.NET हीप| dotnet["dotnet-dump / PerfView"]
    runtime -->|नेटिव हीप| native["WinDbg / Application Verifier"]

चित्र 10: पहले दायरा और समयरेखा तय करने से ठीक उतना उपकरण मिलता है जितना चाहिए, न अधिक न कम।

9.1. Task Manager

Task Manager में स्क्रीन अलग-अलग देखें।

[Processes] या [Details]: अलग प्रोसेस के Working Set परिवार और Commit Size परिवार
[Performance] → [Memory]: सिस्टम-व्यापी In use, Available, Committed, Cached, Paged pool, Non-paged pool

केवल “Memory” नामक स्तंभ से निर्णय न करें — [Details] टैब के स्तंभ शीर्ष पर दायाँ क्लिक कर Working Set, Peak Working Set, Commit Size जैसे आवश्यक स्तंभ जोड़ें। Windows संस्करण और प्रदर्शन भाषा से स्तंभ नाम थोड़े भिन्न होते हैं, इसलिए स्तंभ का अर्थ पुष्टि कर फिर दर्ज करें।

9.2. PowerShell से समय श्रृंखला पकड़ना

लक्ष्य प्रोसेस की ID पता हो तो Get-Process से Working Set, Private Bytes और Virtual Bytes की प्रवृत्ति एक साथ पकड़ी जा सकती है।

param(
    [Parameter(Mandatory)]
    [int]$ProcessId,

    [int]$IntervalSeconds = 5,
    [int]$SampleCount = 60
)

$samples = for ($i = 0; $i -lt $SampleCount; $i++) {
    $process = Get-Process -Id $ProcessId -ErrorAction Stop

    [pscustomobject]@{
        Timestamp      = Get-Date -Format 'yyyy-MM-dd HH:mm:ss'
        ProcessId      = $process.Id
        WorkingSetMB   = [math]::Round($process.WorkingSet64 / 1MB, 1)
        PrivateBytesMB = [math]::Round($process.PrivateMemorySize64 / 1MB, 1)
        VirtualBytesMB = [math]::Round($process.VirtualMemorySize64 / 1MB, 1)
        Handles        = $process.HandleCount
        Threads        = $process.Threads.Count
    }

    Start-Sleep -Seconds $IntervalSeconds
}

$samples | Format-Table -AutoSize
$samples | Export-Csv .\memory-samples.csv -NoTypeInformation -Encoding utf8

.NET का Process.WorkingSet64 Working Set, PrivateMemorySize64 Private Bytes, और VirtualMemorySize64 Virtual Bytes के अनुरूप है।¹⁴¹⁵¹⁶

एकाधिक इंस्टेंस वाले ऐप में नाम नहीं, PID से पीछा करें। लंबे निगरानी में पुनः प्रारंभ से PID बदले तो प्रारंभ समय, सेवा नाम आदि दर्ज करें ताकि लक्ष्य न चूके।

9.3. PerfMon से सिस्टम और प्रोसेस एक समयरेखा पर

कम से कम इन्हें साथ दर्ज करने से अलगाव बहुत आसान होता है।

\Process(<लक्ष्य>)\ID Process
\Process(<लक्ष्य>)\Working Set
\Process(<लक्ष्य>)\Working Set - Private
\Process(<लक्ष्य>)\Private Bytes
\Process(<लक्ष्य>)\Virtual Bytes

\Memory\Available MBytes
\Memory\Committed Bytes
\Memory\Commit Limit
\Memory\Pages Input/sec
\Memory\Page Reads/sec
\Memory\Pool Nonpaged Bytes
\Memory\Pool Paged Bytes

एक नाम वाले कई प्रोसेस हों, या निगरानी के दौरान पुनः प्रारंभ हो, तो केवल इंस्टेंस नाम — Process(name) या Process(name#N) — लक्ष्य नहीं बाँधता। हर नमूने में ID Process भी दर्ज करें, और केवल वही इंस्टेंस अपनाएँ जिसका मान आपके पीछा किए PID से मेल खाए। PID बदलने वाले पुनः प्रारंभ को पार करें तो स्विच का समय भी अलग दर्ज करें।

Windows प्रदर्शन काउंटर नाम प्रदर्शन भाषा से स्थानीयकृत हो सकते हैं। PowerShell में अंग्रेज़ी नाम सीधे निर्दिष्ट कर न मिले तो PerfMon GUI से जोड़ें, या Get-Counter -ListSet * से स्थानीय नाम जाँचें।

9.4. VMMap और RAMMap की भूमिकाएँ न मिलाएँ

VMMap: एक प्रोसेस की वर्चुअल मेमोरी और Working Set को Heap, Image, Mapped File, Private Data, Managed Heap आदि में तोड़ता है
RAMMap: पूरे सिस्टम की भौतिक RAM को उद्देश्य, पेज सूची, प्रोसेस और फ़ाइल में तोड़ता है

“इस प्रोसेस का Private Bytes किससे बढ़ा” VMMap का काम है; “प्रोसेस सूची जो RAM नहीं समझाती वह किस काम आई” RAMMap का।¹⁷¹³

10. अंकों के संयोजन से लक्षण पढ़ना

देखा गया पैटर्न	पहली परिकल्पना	आगे क्या जाँचें
Working Set बढ़े, Private Bytes स्थिर	मौजूदा पेज पर पहली पहुँच, साझा DLL, मैप्ड फ़ाइल, फ़ाइल कैश	VMMap का Image / Mapped File, Pages Input/sec
Private Bytes बढ़े, Working Set स्थिर	निजी Commit बढ़ा पर अनिवासी या Trim हुआ	VMMap का Heap / Private Data / Managed Heap
दोनों प्रारंभ के तुरंत बाद बढ़ें, फिर सपाट	JIT, कैश, पूल, आरंभ वार्म-अप	उसी अतिरिक्त भार पर फिर बढ़ता है या नहीं
हर भार चक्र पर Private Bytes फर्श चढ़े	लीक, असीमित कैश, या मुक्त बाद भी रखने वाला आवंटक	पहले-बाद VMMap स्नैपशॉट, हीप डंप
केवल Working Set अचानक गिरे और गतिविधि से लौटे	OS या ऐप ने Working Set Trim किया	Private Bytes, Pages Input/sec, प्रतिक्रिया समय
Committed X/Y का X, Y के निकट	सिस्टम-व्यापी commit दबाव	शीर्ष Private Bytes उपभोक्ता, Paged/Nonpaged Pool, पेज फ़ाइल सेटिंग
Available कम, Pages Input/sec और डिस्क विलंब ऊँचे	भौतिक RAM दबाव और हार्ड पेजिंग	शीर्ष Working Set उपभोक्ता, RAMMap, कार्यभार सहसंबंध
RAM उपयोग ऊँचा पर कोई बड़ा प्रोसेस नहीं	कैश, साझा पेज, कर्नेल पूल, ड्राइवर, संपीड़न आदि	RAMMap, Pool Nonpaged/Paged Bytes
खाली RAM है, फिर भी केवल 32-बिट ऐप विफल	वर्चुअल पता स्थान छत या खंडन	VMMap का Free/Reserved, एक्ज़ीक्यूटेबल की LAA सेटिंग
Private Bytes ऊँचा पर दोहरा प्रसंस्करण से नहीं बढ़ता	संभवतः ऊँचा वॉटरमार्क रखने वाला पूल या कैश	उसकी सीमा, पुनः उपयोग व्यवहार, शिखर बाद स्थिरता

इस तालिका की सबसे महत्वपूर्ण बात: अकेले मान से नहीं, संयोजन में पढ़ें।

11. मेमोरी लीक जाँच की व्यावहारिक प्रक्रिया

11.1. पहले पुनरुत्पादन शर्तें और स्थिर बिंदु तय करें

“कुछ दिनों में बढ़ता है” अकेले तुलना नहीं बनता।

प्रारंभ बाद वार्म-अप कितना शामिल करें
एक चक्र के संचालन में क्या है
एक चक्र बाद कितने सेकंड प्रतीक्षा
कैश छत तक पहुँचने में कितने चक्र
स्वस्थ और समस्या वाले बिल्ड पर वही इनपुट प्रयोग हो सकता है या नहीं

ये सब तय करें।

11.2. प्रोसेस और सिस्टम एक साथ दर्ज करें

न्यूनतम इन्हें एक ही समयचिह्न पर लॉग रखें।

लक्ष्य का Working Set
लक्ष्य का Private Bytes
लक्ष्य का Virtual Bytes
सिस्टम का Committed Bytes / Commit Limit
Available MBytes
Pages Input/sec
हैंडल संख्या, थ्रेड संख्या
संचालन या संसाधित आइटम संख्या

प्रोसेस का Private Bytes स्थिर हो और सिस्टम Commit बढ़ता रहे तो अन्य प्रोसेस, कर्नेल, ड्राइवर और साझा सेक्शन तक दायरा बढ़ाना होगा।

11.3. पहले तय करें कौन सा “आयाम” बढ़ रहा है

केवल Working Set: निवासी पेज, साझा या फ़ाइल-जनित, Trim और पुनः लोड
Private Bytes: प्रोसेस-निजी commit
केवल Virtual Bytes: Reserve, मैपिंग, पता स्थान खंडन
केवल System Commit: अन्य प्रोसेस और कर्नेल पक्ष सहित
Nonpaged Pool: ड्राइवर/कर्नेल पक्ष
Handles / GDI / USER: मेमोरी के अलावा संसाधन लीक

यह क्रम छोड़ सीधे डंप लें तो गलत लक्ष्य पर जानकारी का पहाड़ पढ़ना पड़ता है।

11.4. विवरण की ओर बढ़ें

नेटिव प्रोसेस: VMMap, WinDbg, Application Verifier, हीप ट्रेसिंग
.NET: dotnet-counters, dotnet-gcdump, dotnet-dump, PerfView
सिस्टम-व्यापी: RAMMap, PerfMon, WPR/WPA
कर्नेल पूल: PoolMon, WinDbg

VMMap प्रोसेस की कमिटेड वर्चुअल मेमोरी और उसके हर भाग को आवंटित Working Set प्रकार से दिखाता है। Private Bytes वृद्धि को Heap, Private Data, Managed Heap या Mapped File तक कितना सिकोड़ पाते हैं, इससे आगे की जाँच लागत बहुत बदलती है।¹⁷

11.5. सुधार बाद उन्हीं शर्तों पर प्रवृत्ति तुलना करें

सुधार से पहले-बाद शिखर मान भिन्न होना पर्याप्त नहीं। प्रारंभिक मान भिन्न हो तो तुलना आसानी से पलट जाती है।

वही प्रारंभ अवस्था
वही इनपुट
वही संचालन संख्या
वही प्रतीक्षा समय
वही नमूना अंतराल

— और हर चक्र बाद फर्श मान तथा प्रवृत्ति तुलना करें। लीक सुधार का प्रमाण “अधिकतम छोटा हुआ” नहीं, बल्कि यह है कि वही भार दोहराने पर भी वृद्धि अब समाहित होती है।

12. आम भ्रांतियों को फिर से कहना

भ्रांति 1: Task Manager की Memory = ऐप द्वारा आवंटित कुल मात्रा

फिर से कहा: कौन सा स्तंभ है जाँचें। Working Set परिवार हो तो अभी RAM में निवासी मात्रा; Commit Size परिवार हो तो उस प्रोसेस का निजी commit।

भ्रांति 2: Private Bytes = पेज फ़ाइल पर बाइट

फिर से कहा: Private Bytes निजी Commit Charge है। यह तार्किक वादा है जिसमें अभी RAM में पेज और जरूरत पड़ने पर पेज फ़ाइल से सहारे जाने वाले पेज दोनों शामिल हैं।

भ्रांति 3: Commit X/Y = पेज फ़ाइल उपयोग / पेज फ़ाइल क्षमता

फिर से कहा: X सिस्टम-व्यापी Commit Charge है, Y Commit Limit। पेज फ़ाइल Y बढ़ाती है, पर X सीधे डिस्क उपयोग नहीं बनता।

भ्रांति 4: ऊँचा Page Faults/sec = डिस्क पर स्वैप हो रहा है

फिर से कहा: इसमें सॉफ्ट फॉल्ट भी शामिल हैं। डिस्क I/O वास्तव में शामिल है या नहीं, Pages Input/sec, Page Reads/sec और डिस्क विलंब से देखें।

भ्रांति 5: कम Free RAM = मेमोरी कम है

फिर से कहा: Available, Standby, हार्ड पेजिंग और प्रतिक्रिया समय देखें। पुनः उपयोग योग्य कैश से RAM भरना सामान्य है।

भ्रांति 6: Working Set सिकोड़ना = मेमोरी लीक सुधरी

फिर से कहा: आपने केवल पेज RAM से निकाले हों। जाँचें कि Private Bytes और हीप के भीतर धारण वास्तव में घटे।

भ्रांति 7: Private Bytes बढ़ना = लीक सिद्ध

फिर से कहा: वही कार्यभार दोहराने पर समाहित होता है या नहीं, किस प्रकार की मेमोरी बढ़ी, और क्या वह मुक्त करने योग्य कैश है — यह जाँचने के बाद ही निर्णय संभव है।

13. सारांश

Windows का “मेमोरी उपयोग” एक अंक नहीं। पता स्थान, commit, RAM निवास और साझायोग्यता अलग सोचें।
Working Set अभी RAM में पेज हैं, Private और Shared दोनों सहित। Private Working Set उनमें प्रोसेस-निजी निवासी पेज हैं।
Private Bytes प्रोसेस-निजी Commit Charge है; न अभी RAM में मात्रा, न पेज फ़ाइल पर वास्तव में लिखी मात्रा।
Committed X/Y सिस्टम-व्यापी Commit Charge / Commit Limit है। पेज फ़ाइल मुख्यतः Commit Limit, संशोधित पेज निकालना और क्रैश डंप सहारा देती है।
Reserved वर्चुअल पता, Committed पेज, और वास्तव में छूकर Working Set में आया पेज अलग चरण हैं।
Page Fault सामान्य संचालन है, और सॉफ्ट फॉल्ट डिस्क नहीं पढ़ता। हार्ड फॉल्ट भी केवल पेज फ़ाइल से नहीं, EXE, DLL या मैप्ड फ़ाइल से हो सकते हैं।
मेमोरी लीक एक क्षण के आकार से नहीं, वही भार बाद फर्श मान और प्रवृत्ति तथा विवरण से सिद्ध होता है।
मूल पथ: अलग प्रोसेस के विवरण के लिए VMMap, सिस्टम-व्यापी भौतिक RAM के लिए RAMMap, समय श्रृंखला के लिए PerfMon, रनटाइम के भीतर के लिए समर्पित डंप उपकरण।

अगली बार Task Manager में “मेमोरी बढ़ रही है” दिखे तो पहले यह पूछें।

बढ़ रहा है Working Set, Private Bytes, Virtual Bytes, या System Commit?

केवल यही प्रश्न जाँच के प्रवेश को काफ़ी सटीक बनाता है।

संदर्भ लिंक

Microsoft Learn, Working Set. प्रोसेस के Working Set के अभी भौतिक मेमोरी में निवासी पेजों का समूह होने, साझा पेज शामिल होने; सॉफ्ट और हार्ड पेज फॉल्ट के अंतर; Transition पेज; और Working Set से पेज हटाने पर। ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, PROCESS_MEMORY_COUNTERS_EX2 structure. WorkingSetSize, PrivateWorkingSetSize, PrivateUsage और SharedCommitUsage की परिभाषाओं पर, तथा PagefileUsage और PrivateUsage दोनों के प्रोसेस के Commit Charge दर्शाने पर। ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Introduction to page files. पेज फ़ाइल के संशोधित पेज निकालने, सिस्टम क्रैश डंप और System Commit Limit विस्तार सहारा देने; System Commit Charge और Commit Limit की परिभाषाओं; तथा Task Manager और प्रदर्शन काउंटर से माप पर। ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Page State. वर्चुअल पेज की Free, Reserved और Committed अवस्थाओं पर, तथा Reserved पेज से कोई भौतिक संग्रह न जुड़ने और पहुँच अयोग्य होने पर। ↩ ↩²
Microsoft Learn, VirtualAlloc function. MEM_RESERVE और MEM_COMMIT के अंतर पर; कमिट का सिस्टम की समग्र मेमोरी और पेज फ़ाइल पर charge होने पर; और वास्तविक भौतिक पेज कभी-कभी पहली पहुँच तक न आवंटित होने पर। ↩ ↩² ↩³
Microsoft Learn, How to determine the appropriate page file size for 64-bit versions of Windows. पेज फ़ाइल आकार के शिखर Commit Charge और क्रैश डंप आवश्यकताओं पर निर्भर होने; हार्ड पेज फॉल्ट के केवल पेज फ़ाइल से नहीं, EXE, DLL और मेमोरी-मैप्ड फ़ाइल से भी पढ़ने; तथा संबंधित प्रदर्शन काउंटर पर। ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Microsoft Learn, Virtual Address Space. हर प्रोसेस के स्वतंत्र वर्चुअल पता स्थान और पेज टेबल होने, तथा वर्चुअल पता स्वयं भौतिक पता न होने पर। ↩
Microsoft Learn, Memory Limits for Windows and Windows Server Releases. 32-बिट प्रोसेस के उपयोगकर्ता-मोड वर्चुअल पता स्थान के आमतौर पर 2GB होने, और 64-बिट Windows पर IMAGE_FILE_LARGE_ADDRESS_AWARE के अनुसार 2GB या 4GB होने पर। ↩
Microsoft Learn, SetProcessWorkingSetSize function. Working Set न्यूनतम और अधिकतम मान के निवास की गारंटी न देने; Working Set खाली करने की क्षमता; और अत्यधिक सेटिंग या क्रिया के सिस्टम प्रदर्शन बिगाड़ सकने पर। ↩
Microsoft Learn, Memory Performance Information. Windows प्रदर्शन काउंटर, मेमोरी प्रबंधन API और Task Manager प्रदर्शन के बीच संबंध पर, जिसमें Process ऑब्जेक्ट का Working Set / Working Set - Private / Private Bytes, और System ऑब्जेक्ट का Committed Bytes / Commit Limit शामिल है। ↩
Microsoft Learn, MapViewOfFile function. FILE_MAP_COPY से हर पेज संभावित copy-on-write होने पर, इसलिए मैपिंग समय पूरे व्यू का Commit Charge पेज फ़ाइल से सहारा देने के लिए आरक्षित होने पर। ↩
Microsoft Learn, Understanding Node Metrics and Properties in HPC Cluster Manager. Available Physical Memory के Zeroed, Free और Standby सूचियों के योग के रूप में गणना होने, तथा प्रत्येक पेज सूची के अर्थ पर। ↩
Microsoft Sysinternals, RAMMap. Windows भौतिक मेमोरी उपयोग का उद्देश्य, पेज सूची, प्रोसेस, प्राथमिकता, भौतिक पेज और फ़ाइल के अनुसार विश्लेषण करने पर। ↩ ↩²
Microsoft Learn, Process.WorkingSet64 Property. WorkingSet64 के प्रोसेस का Working Set बाइट में लौटाने, Process ऑब्जेक्ट के Working Set प्रदर्शन काउंटर के अनुरूप होने पर। ↩
Microsoft Learn, Process.PrivateMemorySize64 Property. PrivateMemorySize64 के अन्य प्रोसेस से साझा न होने वाली प्रोसेस-निजी मेमोरी लौटाने, Private Bytes प्रदर्शन काउंटर के अनुरूप होने पर। ↩
Microsoft Learn, Process.VirtualMemorySize64 Property. VirtualMemorySize64 के प्रोसेस के लिए आवंटित वर्चुअल मेमोरी मात्रा लौटाने, Virtual Bytes प्रदर्शन काउंटर के अनुरूप होने पर। ↩
Microsoft Sysinternals, VMMap. प्रोसेस की कमिटेड वर्चुअल मेमोरी को प्रकार से तोड़ने, प्रत्येक को आवंटित भौतिक मेमोरी (Working Set) दिखाने, तथा विस्तृत मेमोरी मानचित्र पर। ↩ ↩²

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

Windows मेमोरी की गहराई (भाग 2) — भौतिक पेज का जीवन: पाँच सूचियाँ और पेज फ़ाइल की सच्चाई

यह लेख PFN डेटाबेस, Standby, Modified, मेमोरी संपीड़न और पेज फ़ाइल को जोड़कर बताता है कि Working Set छोड़ने के बाद भौतिक पेज कहाँ जाता है।

लेख पढ़ें

स्लीप से रिज़्यूम पर टूटने वाले ऐप — Windows पावर इवेंट कैसे काम करते हैं और उनसे बचने वाले व्यावसायिक ऐप कैसे बनाएँ

लैपटॉप खोला और व्यावसायिक ऐप के कनेक्शन मर चुके थे — कारण वह डिज़ाइन है जिसने स्लीप का हिसाब ही नहीं रखा। यह लेख WM_POWERBROADCAST सूचना ...

लेख पढ़ें

DllMain और Loader Lock — DLL आरंभीकरण में "कुछ न करें" कहे जाने का वास्तविक कारण

DllMain से LoadLibrary क्यों न बुलाएँ या दूसरे थ्रेड से सिंक्रोनाइज़ न करें। प्राथमिक स्रोतों से यह लेख समझाता है कि लोडर लॉक हर DLL सूचन...

लेख पढ़ें

"Not Responding" वास्तव में क्या है — Windows ऐप के हैंग का निर्णय कैसे करता है, और न हैंग करने वाले ऐप कैसे डिज़ाइन करें

Windows का "Not Responding" वह तंत्र है जिसमें OS तय करता है कि विंडो ने 5 सेकंड संदेश नहीं लिया और उसे घोस्ट विंडो से बदल देता है। यह ले...

लेख पढ़ें

WPR/WPA व्यवहार में — "पूरा PC धीमा है" की सिस्टम-व्यापी प्रदर्शन जाँच का परिचय

Task Manager जिन "पूरा PC धीमा" या "स्टार्टअप धीमा" प्रदर्शन समस्याओं का पीछा नहीं कर पाता, उन्हें WPR/WPA से OS-व्यापी ETW ट्रेस पकड़कर ...

लेख पढ़ें

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

Windows ऐप विकास

व्यावसायिक ऐप, डिवाइस एकीकरण और संचार उपकरण, आवश्यकताओं से विकास तक।

सेवा देखें संपर्क करें

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

क्या Task Manager का "Memory" स्तंभ ऐप द्वारा आवंटित कुल मेमोरी दिखाता है?: नहीं। Task Manager में कई मेमोरी स्तंभ हैं — Working Set परिवार, Private Working Set परिवार, Commit Size और अन्य — और अर्थ इस पर निर्भर करता है कि आप कौन सी स्क्रीन और स्तंभ देख रहे हैं। Working Set वे पेज हैं जो अभी RAM में निवासी हैं; Private Bytes या Commit Size उस प्रोसेस का अपना कमिटेड परिमाण है। एक अकेले "Memory" स्तंभ को ऐप द्वारा आवंटित कुल क्षमता, या लीक के आकार के रूप में न पढ़ें।
Working Set और Private Bytes में क्या अंतर है?: Working Set उस प्रोसेस को दिखने वाले उन पेजों की मात्रा है जो अभी भौतिक RAM में निवासी हैं, जिनमें DLL कोड और मेमोरी-मैप्ड फ़ाइल जैसे साझायोग्य पेज शामिल हैं। Private Bytes केवल उसी प्रोसेस द्वारा प्रयुक्त कमिटेड मेमोरी की मात्रा है, चाहे वह अभी RAM में निवासी हो या नहीं। इसलिए दोनों कभी बराबर नहीं होते, और कोई एक हमेशा बड़ा भी नहीं रहता।
क्या Task Manager का "Committed 18/32GB" मतलब है कि 18GB पेज फ़ाइल पर लिखा गया?: नहीं। बायाँ अंक वह कुल commit है जिसे पूरा सिस्टम अभी पृष्ठांकित करने का वादा कर रहा है; दायाँ अंक वह commit छत है जिसे सिस्टम सहारा दे सकता है। छत मोटे तौर पर RAM प्लस पेज फ़ाइल से तय होती है, पर बायाँ कुल वास्तव में पेज फ़ाइल पर नहीं बैठा होता। अधिकांश कमिटेड पेज RAM में हैं, और कुछ कमिटेड पेजों को अभी तक भौतिक पेज मिला ही नहीं। वहीं EXE, DLL और मेमोरी-मैप्ड फ़ाइल जैसे पेज, जिन्हें मूल फ़ाइल से फिर लोड किया जा सकता है, Working Set जितना Private Commit नहीं बढ़ाते।
क्या खाली RAM होते हुए भी OutOfMemory हो सकता है?: हाँ। आवंटन भौतिक RAM के अलावा अन्य कारणों से भी विफल हो सकता है — 32-बिट प्रोसेस का वर्चुअल पता स्थान खत्म होना, आवश्यक आकार की सतत खाली पता श्रेणी का अभाव, सिस्टम commit छत, या Job Object व रनटाइम की अपनी सीमाएँ। विशेषकर 64-बिट Windows पर 32-बिट प्रोसेस आमतौर पर 2GB उपयोगकर्ता-मोड वर्चुअल पता स्थान तक सीमित है, जब तक वह Large Address Aware न हो।
क्या पेज फ़ाइल बंद करने से Windows तेज़ होता है?: सामान्य नियम के रूप में यह नहीं माना जा सकता। पेज फ़ाइल बंद करने से सिस्टम की commit छत गिरती है, अप्रयुक्त संशोधित पेज RAM से निकालना कठिन होता है, और क्रैश डंप कैसे कॉन्फ़िगर किए जा सकते हैं इस पर असर पड़ता है। पेज फ़ाइल का आकार शिखर commit charge और आवश्यक क्रैश डंप मापकर तय होना चाहिए — बिना आधार के बंद करने की सेटिंग नहीं।
क्या ऊँचा Page Faults/sec मतलब सिस्टम में मेमोरी कम है?: केवल इससे नहीं बताया जा सकता। पेज फॉल्ट में सॉफ्ट फॉल्ट शामिल हैं, जो RAM के Standby पेज या दूसरे प्रोसेस से साझा पेज से हल हो सकते हैं, और हार्ड फॉल्ट, जो डिस्क से पढ़ते हैं। Page Faults/sec अकेले देखने के बजाय Pages Input/sec, Page Reads/sec, Available MBytes, डिस्क विलंब और प्रसंस्करण समय को एक ही समयरेखा पर साथ देखें।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।

प्रोफ़ाइल देखें संपर्क करें

सार्वजनिक लिंक

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

ब्लॉग पर लौटें

1. निष्कर्ष पहले

2. “मेमोरी उपयोग” को चार अक्षों में बाँटना

3. वर्चुअल पता स्थान — Reserve और Commit अलग चीजें हैं

3.1. वर्चुअल पता भौतिक RAM पता नहीं है

3.2. Reserved का मतलब केवल “पता आरक्षित कर लिया”

3.3. Committed “जरूरत पड़ने पर सहारा देने” का वादा है

3.4. खाली RAM होते हुए भी OutOfMemory क्यों होता है

4. Working Set — अभी RAM में पेज

4.1. बढ़ता Working Set जरूरी नहीं कि अधिक आवंटन हो

4.2. Working Set में साझा पेज शामिल हैं

4.3. Working Set जबरन घटाने से लीक नहीं सुधरता

5. Private Bytes — प्रोसेस का निजी commit परिमाण

5.1. free या GC के बाद Private Bytes क्यों नहीं गिरता

5.2. लीक का मजबूत उम्मीदवार पैटर्न

6. System Commit — “Committed X/Y” वास्तव में क्या है

6.1. Commit Charge पेज फ़ाइल उपयोग नहीं है

6.2. Commit Limit के निकट क्या होता है

6.3. पेज फ़ाइल की तीन भूमिकाएँ

7. भौतिक RAM का विवरण — केवल कम Available से निर्णय न करें

7.1. Available में पुनः उपयोग योग्य कैश भी है

7.2. जब कोई बड़ा प्रोसेस न हो फिर भी RAM घटे

8. पेज फॉल्ट — ऊँची संख्या स्वयं असामान्य नहीं

8.1. सॉफ्ट पेज फॉल्ट

8.2. हार्ड पेज फॉल्ट

8.3. एक ही कंबल सीमा न लगाएँ

9. कौन सी स्क्रीन या उपकरण किसके लिए

9.1. Task Manager

9.2. PowerShell से समय श्रृंखला पकड़ना

9.3. PerfMon से सिस्टम और प्रोसेस एक समयरेखा पर

9.4. VMMap और RAMMap की भूमिकाएँ न मिलाएँ

10. अंकों के संयोजन से लक्षण पढ़ना

11. मेमोरी लीक जाँच की व्यावहारिक प्रक्रिया

11.1. पहले पुनरुत्पादन शर्तें और स्थिर बिंदु तय करें

11.2. प्रोसेस और सिस्टम एक साथ दर्ज करें

11.3. पहले तय करें कौन सा “आयाम” बढ़ रहा है

11.4. विवरण की ओर बढ़ें

11.5. सुधार बाद उन्हीं शर्तों पर प्रवृत्ति तुलना करें

12. आम भ्रांतियों को फिर से कहना

भ्रांति 1: Task Manager की Memory = ऐप द्वारा आवंटित कुल मात्रा

भ्रांति 2: Private Bytes = पेज फ़ाइल पर बाइट

भ्रांति 3: Commit X/Y = पेज फ़ाइल उपयोग / पेज फ़ाइल क्षमता

भ्रांति 4: ऊँचा Page Faults/sec = डिस्क पर स्वैप हो रहा है

भ्रांति 5: कम Free RAM = मेमोरी कम है

भ्रांति 6: Working Set सिकोड़ना = मेमोरी लीक सुधरी

भ्रांति 7: Private Bytes बढ़ना = लीक सिद्ध

13. सारांश

संबंधित लेख

संबंधित परामर्श क्षेत्र

संदर्भ लिंक

संबंधित लेख

Windows मेमोरी की गहराई (भाग 2) — भौतिक पेज का जीवन: पाँच सूचियाँ और पेज फ़ाइल की सच्चाई

स्लीप से रिज़्यूम पर टूटने वाले ऐप — Windows पावर इवेंट कैसे काम करते हैं और उनसे बचने वाले व्यावसायिक ऐप कैसे बनाएँ

DllMain और Loader Lock — DLL आरंभीकरण में "कुछ न करें" कहे जाने का वास्तविक कारण

"Not Responding" वास्तव में क्या है — Windows ऐप के हैंग का निर्णय कैसे करता है, और न हैंग करने वाले ऐप कैसे डिज़ाइन करें

WPR/WPA व्यवहार में — "पूरा PC धीमा है" की सिस्टम-व्यापी प्रदर्शन जाँच का परिचय

संबंधित विषय

Windows के तकनीकी विषय

इस विषय से जुड़ी सेवाएँ

Windows ऐप विकास

अक्सर पूछे जाने वाले प्रश्न

लेखक की प्रोफ़ाइल

Go Komura

5.1. `free` या GC के बाद Private Bytes क्यों नहीं गिरता