Windows का "memory usage" वास्तव में क्या है? — Working Set, Private Bytes, Commit और pagefile सही पढ़ना

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

तो आखिर यह ऐप वास्तव में कितने gigabyte memory use कर रहा है?

उत्तर यह है कि आपको कौन सा अंक देखना चाहिए यह इस पर निर्भर करता है कि आप वास्तव में क्या जानना चाहते हैं। अभी RAM में resident मात्रा जाननी हो, उस process को खास तौर पर allocate की गई मात्रा, वह मात्रा जिसका सिस्टम भविष्य में भी support देने का वादा कर चुका है, या केवल reserved virtual address की range — metric अलग होती है।

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

• कितना address space उपयोग में है
• कितना commit खपत हुआ है
• क्या वह अभी physical RAM में resident है
• क्या page process-private है, या shareable
• पूरा सिस्टम और कितना allocation support दे सकता है

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

.NET objects क्यों collect नहीं होते यह पता लगाने की प्रक्रिया “.NET में GC delay और memory leak अलग करना” में विस्तार से है, और VMMap तथा Process Explorer का ठोस operation “Process Explorer / Handle / VMMap व्यवहार में” में है। यह लेख दोनों की पूर्वापेक्षा पर केंद्रित है: Windows OS पक्ष के अंक कैसे पढ़ें।

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

• Working Set वे pages हैं जो अभी RAM में resident हैं। इसमें न केवल process-private pages शामिल हैं बल्कि वे pages भी जो अन्य processes से share हो सकते हैं, जैसे DLL code और memory-mapped files।¹
• Private Working Set, Working Set का वह भाग है जो अभी केवल उसी process का है। “अभी यह process अकेले जो RAM घेर रहा है” का approximation है, पर ऐप द्वारा allocate की गई कुल मात्रा नहीं।²
• Private Bytes उस process का private commit size है। यह इस से अलग metric है कि memory अभी RAM में resident है या नहीं। Win32 API structure का PagefileUsage field भी, वर्तमान Windows पर, प्रभावी रूप से वही Commit Charge दर्शाता है, और pagefile पर वास्तव में लिखे bytes नहीं।²
• Task Manager का “Committed X/Y” X को सिस्टम का वर्तमान कुल commit और Y को commit ceiling दिखाता है। X pagefile usage नहीं है। Y मोटे तौर पर RAM plus pagefile से तय होता है।³
• Reserve और Commit अलग चीजें हैं। केवल virtual address range Reserve करना उसे भविष्य के उपयोग के लिए अलग रखना है; वह RAM या commit ceiling की उतनी ही मात्रा नहीं खाता।⁴⁵
• Page fault का मतलब आवश्यक रूप से disk I/O नहीं। Soft faults RAM के भीतर हल हो सकते हैं, और hard faults pagefile, executable, memory-mapped file आदि से पढ़ते हैं।¹⁶
• Memory leak एक अकेले पाठ से नहीं, बल्कि वही workload दोहराने पर trend से तय होता है। खासकर देखें कि processing खत्म होने के बाद भी Private Bytes और उसका breakdown सीढ़ी-सीढ़ी बढ़ता रहे और उसी steady state में न लौटे।

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

flowchart TB
    accTitle: सही Windows memory metric चुनना
    accDescr: कौन सी metric देखें यह इस पर निर्भर करता है कि आप RAM residency, process-private commit, system-wide commit, या virtual address range जानना चाहते हैं
    question["Memory usage के बारे में आप क्या जानना चाहते हैं"]
    question -->|अभी RAM में मात्रा| workingSet["Working Set"]
    question -->|Process-private वादा की मात्रा| privateBytes["Private Bytes"]
    question -->|System-wide वादा की मात्रा| systemCommit["System Commit"]
    question -->|Reserved address range| virtualBytes["Virtual Bytes / Reserved"]
    workingSet --> resident["Physical RAM में residency"]
    privateBytes --> privateCommit["Process-private Commit"]
    systemCommit --> commitLimit["Commit Limit से तुलना"]
    virtualBytes --> addressSpace["Virtual address space"]

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

2. “Memory usage” को चार axes में बाँटना

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

flowchart TB
    accTitle: एक page classify करने के चार स्वतंत्र axes
    accDescr: Virtual address state, committed page का backing, physical RAM residency, और अन्य processes से shareability अलग-अलग जाँचें
    page["एक page को चार axes पर देखें"]
    page --> address["Address state"]
    address --> addressValues["Free / Reserved / Committed"]
    page --> backing["Backing"]
    backing --> backingValues["Page-file-backed / File-backed"]
    page --> residentAxis["RAM residency"]
    residentAxis --> residentValues["Resident / Not resident"]
    page --> sharing["Shareability"]
    sharing --> sharingValues["Private / Shareable"]

चित्र 2: एक ही page पर भी address state, backing, residency और shareability स्वतंत्र तय होती हैं।

Mapped Free, Reserved और Committed के साथ एक address state नहीं — वह region की श्रेणी है। Mapped view के pages भी Committed हो सकते हैं। इसी तरह Private backing medium नहीं बल्कि shareability का classification है। इसलिए backing को Page-file-backed या File-backed, और shareability को Private या Shareable, अलग पढ़ें।

इन चार axes को मिलाकर representative metrics का संबंध इस प्रकार है।

flowchart TB
    accTitle: Page types का मुख्य memory metrics से map
    accDescr: Resident private pages, nonresident private pages, resident shared pages और reserved-only range किन metrics में आते हैं
    privateResident["Private, committed, RAM-resident"]
    privateNonresident["Private, committed, RAM-nonresident"]
    sharedResident["Shared page, RAM-resident"]
    reservedOnly["Reserved, committed नहीं"]
    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 अलग page समूह गिनते हैं, इसलिए सरल inclusion नहीं।

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

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

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

3. Virtual address space — Reserve और Commit अलग चीजें हैं

3.1. Virtual address physical RAM address नहीं है

हर process का अपना private virtual address space होता है। ऐप जो pointer सँभालता है वह सीधे physical RAM location नहीं दर्शाता; Windows page table से virtual address को physical page या file पर data से जोड़ता है।⁷

इसका परिणाम: 64GB RAM लगे PC पर भी किसी 32-bit process का virtual address space आमतौर पर उससे बहुत छोटा होता है। उलटा, 64-bit process का virtual address space physical RAM से बड़ा होना भी सामान्य है।

3.2. Reserved का मतलब केवल “address reserve कर लिया”

VirtualAlloc का MEM_RESERVE भविष्य के उपयोग के लिए contiguous virtual address range reserve करता है। इस चरण में pages से कोई physical storage जुड़ा नहीं, और range पढ़ी-लिखी नहीं जा सकती।⁴⁵

उदाहरण के लिए database या runtime भविष्य की वृद्धि के लिए 8GB address range Reserve करे तो भी केवल इससे 8GB RAM या 8GB Private Bytes नहीं खर्च होते।

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

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

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

flowchart TB
    accTitle: Reserve से Commit और RAM residency तक तीन चरण
    accDescr: Virtual address reserve करना, page commit करना, और पहली access पर physical page सौंपकर Working Set में आने का प्रवाह
    reserve["MEM_RESERVE - address range reserve"]
    reserve -.-> virtualMetric["Virtual Bytes परिवार में झलकता"]
    reserve -->|MEM_COMMIT| committed["Committed - page protection के अनुसार accessible"]
    committed -.-> commitMetric["Private Bytes / System Commit में झलकता"]
    committed -->|पहली access, demand-zero fault| resident["Physical page सौंपा, RAM-resident"]
    resident -.-> workingSetMetric["Working Set में झलकता"]
    committed -.->|कभी access न हो तो| nonresident["Committed पर resident नहीं"]

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

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

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

Memory allocation सफल है या नहीं, यह केवल खाली RAM से तय नहीं होता।

• Process ने अपना virtual address space खत्म कर दिया
• आवश्यक आकार की contiguous खाली address range नहीं
• System-wide Commit Charge Commit Limit तक पहुँच गया
• Job Object, container, runtime या library की अपनी limit है
• वह 32-bit process है
• Native heap fragmented है

64-bit Windows पर भी 32-bit process का user-mode virtual address space, IMAGE_FILE_LARGE_ADDRESS_AWARE न set हो तो आमतौर पर 2GB है। वह flag set 32-bit ऐप 64-bit Windows पर 4GB तक उपयोग कर सकता है।⁸

इसलिए “PC में 20GB खाली RAM है, फिर भी 32-bit ऐप लगभग 1.6GB पर fail” विरोधाभास नहीं। यह RAM समस्या न होकर address space fragmentation या कठोर limit हो सकती है।

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

Working Set process के virtual address space में वे pages हैं जो अभी physical RAM में resident हैं।¹

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

• Process का अपना heap और stack
• EXE और DLL code तथा read-only data
• Memory-mapped files
• Shared memory
• Copy-on-write के बाद उस process के private बने pages
• Runtime और विभिन्न libraries द्वारा छुए pages

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

पहले से committed page पर पहली access Working Set अकेले बढ़ा सकती है जबकि Private Bytes अपरिवर्तित रहे। बड़े file को memory-map कर क्रम से पढ़ने पर भी file-backed pages Working Set में आते हैं और Private Bytes लगभग नहीं बढ़ता।

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

इसलिए Working Set गिरना जरूरी नहीं “ऐप ने free किया”, और बढ़ना जरूरी नहीं “ऐप ने नया allocate किया”।

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

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

4.2. Working Set में shared pages शामिल हैं

यदि 10 processes एक ही DLL के code pages share करें, वह page प्रत्येक के Working Set में दिख सकता है, जबकि physical RAM पर केवल एक copy है। Working Set योग installed RAM से अधिक हो तो तुरंत समस्या नहीं।

“अभी यह process अकेले जो RAM घेर रहा है” के निकट जाना हो तो Private Working Set देखें। फिर भी यह “उस process ने जो सारी memory allocate की” नहीं — यह सख्ती से अभी resident private pages है।

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

EmptyWorkingSet या SetProcessWorkingSetSize से process के Working Set से pages निकाले जा सकते हैं। पर यह commit free करने या heap references छोड़ने की क्रिया नहीं। दिखने वाला RAM usage गिरता है जबकि Private Bytes अपरिवर्तित रहता है, और अगली access page faults की झड़ी ला सकती है।⁹

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

5. Private Bytes — process का private commit size

Private Bytes उस process के लिए खास तौर पर committed virtual memory की मात्रा है। यह वह Commit Charge है जो दूसरे processes से share नहीं हो सकता, और अभी RAM में resident है या नहीं इससे फर्क नहीं पड़ता। Microsoft की PROCESS_MEMORY_COUNTERS_EX में PrivateUsage इसी मान के अनुरूप है।¹⁰²

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

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

• HeapAlloc, malloc, new आदि द्वारा प्रयुक्त native heap का commit
• VirtualAlloc से सीधे committed Private Data
• .NET GC heap का committed क्षेत्र
• Thread stack का वह भाग जो वास्तव में committed है
• Copy-on-write view (FILE_MAP_COPY) map करते समय पूरे view के लिए reserved Commit Charge
• Libraries और device SDK द्वारा internally रखे private buffers

FILE_MAP_COPY से बने copy-on-write view में हर page अंततः private हो सकता है, इसलिए mapping समय Windows पूरे view को pagefile से back देने जितना Commit Charge reserve करता है। इसलिए कोई write private copy बनाए उससे पहले ही System Commit और process का Commit Charge (Private Bytes) पूरे view जितना बढ़ सकता है।¹¹

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

ऐप की दृष्टि से memory “free” होने पर भी runtime या heap allocator वह क्षेत्र OS को Decommit न कर भविष्य के reuse के लिए रख सकता है। तब ऐप के भीतर reuse योग्य होते हुए भी Private Bytes ऊँचा रहता है।

यह ऊँचा इसलिए भी रह सकता है कि बड़े क्षेत्र का केवल भाग जीवित है, fragmentation है, या cache/pool अपनी ceiling तक गर्म हो चुका है।

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

1. वही processing उतनी ही बार दोहराएँ
2. Processing के बाद उतना ही समय wait करें
3. जाँचें कि Private Bytes उसी स्तर पर लौटता है, या स्थिर मान पर थम जाता है
4. VMMap या heap dump से देखें कौन सा क्षेत्र या type बढ़ा

flowchart TB
    accTitle: free या GC के बाद Private Bytes न गिरने का कारण
    accDescr: Allocator ऐप की अब-unnecessary क्षेत्र OS को लौटाए या reuse के लिए रखे, इस पर Private Bytes अलग बदलता है
    release["ऐप free / GC से क्षेत्र free करता है"]
    release --> decision{"क्या allocator इसे OS को लौटाता है"}
    decision -->|Decommit / Release| returned["Commit Charge घटता है"]
    returned --> lower["Private Bytes गिरता है"]
    decision -->|Reuse के लिए रखता है| retained["क्षेत्र committed रहता है"]
    retained --> high["Private Bytes ऊँचा थमता है"]
    retained --> reasons["Pool, cache, fragmentation"]

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

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

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

Private Bytes
  ^
  |                    ________
  |             ______|
  |      ______|
  |_____|
  +----------------------------> उसी processing की repetition

फिर भी सीढ़ी आकार पहली बार JIT, font, image decoder, connection pool या cache warm-up की कुछ cycle वृद्धि हो सकती है, जिसके बाद स्थिर हो। महत्व बढ़ने का नहीं, steady state में न समाहित होने का है।

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

Task Manager के [Performance] → [Memory] टैब पर “Committed X/Y” system-wide metric है।

• X: System Commit Charge — वह committed memory जिसका Windows अभी पूरे सिस्टम में support देने का वादा कर रहा है
• Y: System Commit Limit — वह ceiling जिसे सिस्टम support दे सकता है

Commit Limit मोटे तौर पर physical RAM plus सभी pagefiles के योग से तय होता है। Pagefile न हो तो installed RAM से थोड़ा छोटा निकलता है।³⁶

flowchart TB
    accTitle: System Commit Charge और Commit Limit का संबंध
    accDescr: Per-process, shared section और kernel commit वर्तमान मान X बनाते हैं, physical RAM और pagefile ceiling Y support देते हैं
    processCommit["हर process का Private Commit"] --> charge["System Commit Charge - X"]
    sharedCommit["Pagefile से backed shared section का Commit"] --> charge
    kernelCommit["Kernel Commit"] --> charge
    physicalRam["Physical RAM"] --> limit["System Commit Limit - Y"]
    pageFiles["Pagefile"] --> limit
    charge -->|X, Y से अधिक नहीं हो सकता| limit

चित्र 7: X वर्तमान वादा की मात्रा है और Y वह ceiling जो उस वादे को support दे सकती है — यह pagefile usage का प्रदर्शन नहीं।

System Commit Charge में हर process के Private Bytes का योग ही नहीं, pagefile-backed shared section का Commit और kernel द्वारा खपत Commit भी शामिल है। इसलिए per-process Private Bytes का योग अकेले X पूरी तरह नहीं समझाता।

6.1. Commit Charge pagefile usage नहीं है

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

वह 20GB मतलब “pagefile पर 20GB लिखा” नहीं। यह वह कुल है जिसका Windows private writable pages आदि के लिए, जरूरत पड़ने पर, RAM या pagefile backing देने का वादा कर रहा है।

उस क्षण ये states मिली हो सकती हैं:

• अधिकांश RAM में resident है
• कुछ pagefile पर paged-out है
• कुछ committed है पर पहली access अभी नहीं हुई
• कुछ kernel पक्ष के commit के रूप में खपत है

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

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

System Commit Charge Commit Limit तक पहुँचे तो नए commit requests support नहीं जा सकते। इससे process memory allocation failure, ऐप crash और सिस्टम unresponsive होना आता है।³

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

6.3. Pagefile की तीन भूमिकाएँ

Pagefile मुख्यतः ये भूमिकाएँ निभाती है।

1. Commit Limit बढ़ाना
2. कम उपयोग वाले modified pages RAM से page-out होने देना
3. Configuration के अनुसार सिस्टम crash dump support देना

Pagefile बंद करना सरल मामला नहीं कि “disk I/O हमेशा घटे और सब तेज़ हो”। बल्कि यह Commit Limit गिराता है, modified पर अभी unnecessary pages RAM में रहने देता है, और crash पर आवश्यक dump लेना असंभव बना सकता है।³⁶

उपयुक्त pagefile आकार installed RAM अकेले से तय नहीं होता। Microsoft स्वयं कहता है कि इसे generalize नहीं किया जा सकता, क्योंकि peak System Commit Charge और आवश्यक crash dump का type सिस्टम-से-सिस्टम भिन्न है।⁶

7. Physical RAM का breakdown — केवल कम Available से निर्णय न करें

Physical RAM केवल user process के Working Set से नहीं भरता।

• हर process का Working Set
• सिस्टम file cache
• Standby, Modified, Free, Zeroed जैसी page lists
• Kernel का Paged Pool / Nonpaged Pool
• Device drivers द्वारा रखी memory
• Memory compression store
• GPU और अन्य devices से shared या उनके लिए reserved क्षेत्र
• Hardware-reserved memory

7.1. Available में reuse योग्य cache भी है

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

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

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

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

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

इसलिए Task Manager में Free कम हो पर Available पर्याप्त हो और hard page fault या disk wait समस्या न बनें, तो Windows RAM को cache के रूप में प्रभावी उपयोग कर रहा हो सकता है।

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

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

• File cache और memory-mapped files
• Nonpaged Pool / Paged Pool
• Drivers द्वारा locked pages
• Shared pages
• Memory compression
• Virtualization या GPU संबंधित allocations

इस स्थिति में process list घूरते रहने के बजाय Sysinternals के RAMMap में Use Counts, Processes, Priority Summary और File Summary देखें। RAMMap physical memory को उद्देश्य, page list और file के अनुसार तोड़ने का आधिकारिक उपकरण है।¹³

यदि केवल Nonpaged Pool बढ़ता रहे, तो user-mode ऐप के Private Bytes के बजाय driver या kernel पक्ष leak संदेह का समय है।

8. Page fault — ऊँची संख्या स्वयं असामान्य नहीं

Page Fault तब होता है जब process ऐसे page पर पहुँचे जो अभी उसके Working Set में नहीं। नाम में “Fault” होने पर भी यह exceptional failure नहीं — virtual memory चलाने की सामान्य व्यवस्था है।¹

8.1. Soft page fault

ये disk पढ़े बिना हल होते हैं।

• Page अभी Standby या Transition में है
• वही shared page दूसरे process के Working Set में पहले से है
• Committed page पर पहली access और zero page सौंपा जाना
• Memory manager की ahead-read पहले ही उसे RAM में ला चुकी

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

8.2. Hard page fault

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

• .exe या .dll का code और data
• Memory-mapped file
• Pagefile

flowchart TB
    accTitle: Soft और hard page fault की शाखा
    accDescr: Working Set में न होने वाले page पर पहुँचने पर storage I/O unnecessary हो तो soft, आवश्यक हो तो hard page fault
    access["Working Set में न होने वाले page पर पहुँच"] --> storageIo{"क्या storage I/O चाहिए"}
    storageIo -->|नहीं - Standby, shared, demand-zero आदि| soft["Soft page fault"]
    soft --> resident["Disk पढ़े बिना Working Set में आता"]
    storageIo -->|हाँ| hard["Hard page fault"]
    hard --> source{"कहाँ से पढ़ा जाता है"}
    source --> image["EXE / DLL"]
    source --> mapped["Memory-mapped file"]
    source --> pagefile["Pagefile"]
    image --> loaded["Load के बाद Working Set में"]
    mapped --> loaded
    pagefile --> loaded

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

Microsoft hard faults मापने के counters में \Memory\Pages/sec, \Memory\Page Reads/sec और \Memory\Pages Input/sec गिनाता है। ये ऊँचे हों तो भी memory कम होना जरूरी नहीं, इसलिए Available MBytes, disk latency और वास्तविक response time से correlate करें।⁶

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

“1000 Page Faults/sec से ऊपर असामान्य” जैसा स्थिर मान storage, page size, workload और access locality से अर्थ बदलता है।

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

• Memory\Available MBytes
• Memory\Pages Input/sec
• Memory\Page Reads/sec
• लक्ष्य disk पर Read latency / Queue
• लक्ष्य process का Working Set और Private Bytes
• ऐप का processing time, timeout और UI response

Workload बढ़ने के साथ Available गिरे, Pages Input/sec और disk wait बढ़े, और processing time भी बिगड़े, तो physical memory pressure से paging का संदेह आधार मिलता है।

9. कौन सी स्क्रीन या tool किसके लिए

flowchart TB
    accTitle: Windows memory investigation tools चुनना
    accDescr: लक्ष्य एक process है या पूरा सिस्टम, एक क्षण या time series, और runtime के भीतर holding खोजना है या नहीं, इस पर tool निर्भर करता है
    question["आप क्या अलग करना चाहते हैं"]
    question --> processScope{"क्या लक्ष्य एक process है"}
    processScope -->|हाँ| processTime{"एक क्षण या time series"}
    processTime -->|एक-क्षण breakdown| vmmap["VMMap"]
    processTime -->|Time series| perfmon["PerfMon / PowerShell"]
    processScope -->|पूरा सिस्टम| systemView{"Physical RAM breakdown या timeline"}
    systemView -->|Physical RAM breakdown| rammap["RAMMap"]
    systemView -->|CPU, I/O और wait सहित timeline| wpa["WPR / WPA"]
    question --> runtime{"क्या runtime के भीतर holding खोजना है"}
    runtime -->|.NET heap| dotnet["dotnet-dump / PerfView"]
    runtime -->|Native heap| native["WinDbg / Application Verifier"]

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

9.1. Task Manager

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

• [Processes] या [Details]: अलग process के Working Set परिवार और Commit Size परिवार
• [Performance] → [Memory]: System-wide In use, Available, Committed, Cached, Paged pool, Non-paged pool

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

9.2. PowerShell से time series पकड़ना

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

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 के अनुरूप है।¹⁴¹⁵¹⁶

एकाधिक instances वाले ऐप में नाम नहीं, PID से पीछा करें। लंबे monitoring में restart से PID बदले तो start time, service नाम आदि दर्ज करें ताकि लक्ष्य न चूके।

9.3. PerfMon से सिस्टम और process एक timeline पर

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

\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

एक नाम वाले कई processes हों, या monitoring के दौरान restart हो, तो केवल instance नाम — Process(name) या Process(name#N) — लक्ष्य नहीं बाँधता। हर sample में ID Process भी दर्ज करें, और केवल वही instance अपनाएँ जिसका मान आपके पीछा किए PID से मेल खाए। PID बदलने वाले restart को पार करें तो switch का समय भी अलग दर्ज करें।

Windows performance counter नाम display language से localized हो सकते हैं। PowerShell में अंग्रेज़ी नाम सीधे specify कर न मिले तो PerfMon GUI से जोड़ें, या Get-Counter -ListSet * से local नाम जाँचें।

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

• VMMap: एक process की virtual memory और Working Set को Heap, Image, Mapped File, Private Data, Managed Heap आदि में तोड़ता है
• RAMMap: पूरे सिस्टम की physical RAM को उद्देश्य, page list, process और file में तोड़ता है

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

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

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

11. Memory leak investigation की व्यावहारिक प्रक्रिया

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

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

• Start बाद warm-up कितना शामिल करें
• एक cycle के operation में क्या है
• एक cycle बाद कितने सेकंड wait
• Cache ceiling तक पहुँचने में कितने cycles
• स्वस्थ और समस्या वाले builds पर वही input प्रयोग हो सकता है या नहीं

ये सब तय करें।

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

न्यूनतम इन्हें एक ही timestamp पर log रखें।

• लक्ष्य का Working Set
• लक्ष्य का Private Bytes
• लक्ष्य का Virtual Bytes
• सिस्टम का Committed Bytes / Commit Limit
• Available MBytes
• Pages Input/sec
• Handle count, thread count
• Operation या processed item count

Process का Private Bytes स्थिर हो और सिस्टम Commit बढ़ता रहे तो अन्य processes, kernel, drivers और shared sections तक scope बढ़ाना होगा।

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

• केवल Working Set: resident pages, shared या file-generated, Trim और reload
• Private Bytes: process-private commit
• केवल Virtual Bytes: Reserve, mapping, address space fragmentation
• केवल System Commit: अन्य processes और kernel पक्ष सहित
• Nonpaged Pool: driver/kernel पक्ष
• Handles / GDI / USER: memory के अलावा resource leak

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

11.4. Breakdown की ओर बढ़ें

• Native process: VMMap, WinDbg, Application Verifier, heap tracing
• .NET: dotnet-counters, dotnet-gcdump, dotnet-dump, PerfView
• System-wide: RAMMap, PerfMon, WPR/WPA
• Kernel pool: PoolMon, WinDbg

VMMap process की committed virtual memory और उसके हर भाग को allocated Working Set type से दिखाता है। Private Bytes वृद्धि को Heap, Private Data, Managed Heap या Mapped File तक कितना सिकोड़ पाते हैं, इससे आगे की investigation लागत बहुत बदलती है।¹⁷

11.5. Fix बाद उन्हीं शर्तों पर trend तुलना करें

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

• वही start state
• वही input
• वही operation count
• वही wait time
• वही sample interval

— और हर cycle बाद floor मान तथा trend तुलना करें। Leak fix का प्रमाण “maximum छोटा हुआ” नहीं, बल्कि यह है कि वही workload दोहराने पर भी वृद्धि अब समाहित होती है।

12. आम misconceptions को फिर से कहना

Misconception 1: Task Manager की Memory = ऐप द्वारा allocate की गई कुल मात्रा

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

Misconception 2: Private Bytes = pagefile पर bytes

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

Misconception 3: Commit X/Y = pagefile usage / pagefile capacity

फिर से कहा: X system-wide Commit Charge है, Y Commit Limit। Pagefile Y बढ़ाती है, पर X सीधे disk usage नहीं बनता।

Misconception 4: ऊँचा Page Faults/sec = disk पर swap हो रहा है

फिर से कहा: इसमें soft faults भी शामिल हैं। Disk I/O वास्तव में शामिल है या नहीं, Pages Input/sec, Page Reads/sec और disk latency से देखें।

Misconception 5: कम Free RAM = memory कम है

फिर से कहा: Available, Standby, hard paging और response time देखें। Reuse योग्य cache से RAM भरना सामान्य है।

Misconception 6: Working Set सिकोड़ना = memory leak सुधरी

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

Misconception 7: Private Bytes बढ़ना = leak सिद्ध

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

13. सारांश

• Windows का “memory usage” एक अंक नहीं। Address space, commit, RAM residency और shareability अलग सोचें।
• Working Set अभी RAM में pages हैं, Private और Shared दोनों सहित। Private Working Set उनमें process-private resident pages हैं।
• Private Bytes process-private Commit Charge है; न अभी RAM में मात्रा, न pagefile पर वास्तव में लिखी मात्रा।
• Committed X/Y system-wide Commit Charge / Commit Limit है। Pagefile मुख्यतः Commit Limit, modified pages निकालना और crash dump support देती है।
• Reserved virtual address, Committed page, और वास्तव में छूकर Working Set में आया page अलग चरण हैं।
• Page Fault सामान्य operation है, और soft fault disk नहीं पढ़ता। Hard fault भी केवल pagefile से नहीं, EXE, DLL या mapped file से हो सकते हैं।
• Memory leak एक क्षण के आकार से नहीं, वही workload बाद floor मान और trend तथा breakdown से सिद्ध होता है।
• मूल पथ: अलग process के breakdown के लिए VMMap, system-wide physical RAM के लिए RAMMap, time series के लिए PerfMon, runtime के भीतर के लिए dedicated dump tools।

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

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

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

संबंधित लेख

• .NET में GC delay और memory leak अलग करना — बढ़ती memory देखने, तुलना करने और सिद्ध करने की व्यावहारिक प्रक्रिया
• Process Explorer / Handle / VMMap व्यवहार में — hang, leak, और “file in use” को अभी की अवस्था से पकड़ना
• Shared memory की गलतियाँ और व्यावहारिक best practices
• Windows I/O की गहराई（भाग 4）— Cache Manager: आपका WriteFile वास्तव में disk तक कब पहुँचता है?
• Industrial camera ऐप के long-run crash की जाँच - handle leak (भाग 1)

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

KomuraSoft LLC Windows ऐप memory वृद्धि, लंबे चलने के बाद performance गिरावट, 32-bit process में OutOfMemory, और केवल customer environment में होने वाली memory कमी के लिए PerfMon, VMMap, RAMMap, WinDbg और .NET diagnostics tools को मिलाकर root-cause investigation सँभालता है। हम केवल “memory ऊँची है” पर नहीं रुकते — कौन सा क्षेत्र, किस operation से, क्यों बढ़ा, और कहाँ से referenced या held है, यह अलग करते हैं।

• Windows ऐप विकास
• बग और कारणों की जाँच
• तकनीकी परामर्श और डिज़ाइन समीक्षा
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

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

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

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

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

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

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

क्या Task Manager का "Memory" column ऐप द्वारा allocate की गई कुल memory दिखाता है?

नहीं। Task Manager में कई memory columns हैं — Working Set परिवार, Private Working Set परिवार, Commit Size और अन्य — और अर्थ इस पर निर्भर करता है कि आप कौन सी स्क्रीन और column देख रहे हैं। Working Set वे pages हैं जो अभी RAM में resident हैं; Private Bytes या Commit Size उस process का अपना committed size है। एक अकेले "Memory" column को ऐप द्वारा allocate की गई कुल capacity, या leak के आकार के रूप में न पढ़ें।

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

Working Set उस process को दिखने वाले उन pages की मात्रा है जो अभी physical RAM में resident हैं, जिनमें DLL code और memory-mapped file जैसे shareable pages शामिल हैं। Private Bytes केवल उसी process द्वारा इस्तेमाल की गई committed memory की मात्रा है, चाहे वह अभी RAM में resident हो या नहीं। इसलिए दोनों कभी बराबर नहीं होते, और कोई एक हमेशा बड़ा भी नहीं रहता।

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

नहीं। बायाँ अंक वह कुल commit है जिसे पूरा सिस्टम अभी page करने का वादा कर रहा है; दायाँ अंक वह commit ceiling है जिसे सिस्टम back कर सकता है। Ceiling मोटे तौर पर RAM plus pagefile से तय होती है, पर बायाँ कुल वास्तव में pagefile पर नहीं बैठा होता। अधिकांश committed pages RAM में हैं, और कुछ committed pages को अभी तक physical page मिला ही नहीं। वहीं EXE, DLL और memory-mapped file जैसे pages, जिन्हें original file से फिर load किया जा सकता है, Working Set जितना Private Commit नहीं बढ़ाते।

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

हाँ। Allocation physical RAM के अलावा अन्य कारणों से भी fail हो सकता है — 32-bit process का virtual address space खत्म होना, आवश्यक आकार की contiguous खाली address range का अभाव, सिस्टम commit ceiling, या Job Object व runtime की अपनी limits। खासकर 64-bit Windows पर 32-bit process आमतौर पर 2GB user-mode virtual address space तक सीमित है, जब तक वह Large Address Aware न हो।

क्या pagefile बंद करने से Windows तेज़ होता है?

सामान्य नियम के रूप में यह नहीं माना जा सकता। Pagefile बंद करने से सिस्टम की commit ceiling गिरती है, unused modified pages RAM से निकालना कठिन होता है, और crash dump कैसे configure किए जा सकते हैं इस पर असर पड़ता है। Pagefile का आकार peak commit charge और आवश्यक crash dump मापकर तय होना चाहिए — बिना आधार के बंद करने की setting नहीं।

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

केवल इससे नहीं बताया जा सकता। Page fault में soft faults शामिल हैं, जो RAM के Standby pages या दूसरे process से shared pages से हल हो सकते हैं, और hard faults, जो disk से पढ़ते हैं। Page Faults/sec अकेले देखने के बजाय Pages Input/sec, Page Reads/sec, Available MBytes, disk latency और processing time को एक ही timeline पर साथ देखें।

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

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

Go Komura

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

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