Windows memory की गहराई (भाग 2) — physical page का जीवन: पाँच lists और pagefile की सच्चाई

पिछले लेख, «Windows memory की गहराई (भाग 1) — वह क्षण जब virtual address physical RAM बन जाता है» में हमने उस क्षण तक पीछा किया जब page-fault handler पहली बार छुए गए Commit page पर physical page allocate करता है। तो वह physical page Working Set से निकलने के बाद कहाँ जाता है?

अक्सर व्याख्या «उसे pagefile में निकाल दिया जाता है» तक सिमट जाती है, लेकिन वास्तव में उसके पहले और बाद कई states होती हैं। Unmodified page सामग्री छोड़कर Standby में जा सकता है। Modified page पहले Modified पर writeback की प्रतीक्षा करता है। Reuse पर वह Free या Zeroed से गुज़र सकता है, और अगर वही सामग्री फिर चाहिए तो Standby से soft fault से लौट सकता है।

यह लेख PFN database को अक्ष मानकर एक physical page Active, Modified, Standby, Free और Zeroed से कैसे चलता है का पीछा करता है। संख्याओं का पढ़ना स्वयं परिचयात्मक लेख «What Does Windows’ “Memory Usage” Actually Mean? — Correctly Reading Working Set, Private Bytes, Commit, and the Page File» को मानकर चलता है।

«Windows memory की गहराई» — सभी 3 भाग

1. भाग 1: virtual address और page fault
   हम पीछा करते हैं कि Commit virtual page कब physical RAM पाता है।
2. भाग 2 (यह लेख): physical page का जीवन
   हम Working Set छोड़ने वाले page की state-transition और pagefile की भूमिका का पीछा करते हैं।
3. भाग 3: section object और copy-on-write
   हम उस mechanism का पीछा करते हैं जिससे DLL, file mapping और shared memory physical pages share करते हैं।

भाग 2 जिस प्रश्न का उत्तर देता है वह केवल एक है।

Working Set छोड़ने वाला physical page गायब होता है, disk पर जाता है, या RAM में रहता है?

इच्छित पाठक वे developers और operators हैं जो mechanism से समझना चाहते हैं कि Available ऊँचा होने पर Standby भी ऊँचा क्यों होता है, Working Set trim के बाद व्यवहार, pagefile configuration और memory compression। Prerequisites Windows 10/11 या वर्तमान Windows Server हैं, और आवश्यक पृष्ठभूमि Working Set, Commit तथा soft/hard fault की बुनियाद है। कठिनाई मध्यम है; हम PFN और page lists जैसे internal शब्द इस्तेमाल करते हैं, लेकिन focus उस पर है जो kernel debugger के बिना RAMMap और PerfMon से देखा जा सकता है।

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

शुरू में वे बिंदु हैं जिन्हें गलत पढ़ना आसान है।

• Working Set छोड़ने वाला page जरूरी नहीं तुरंत गायब हो।
  Clean page Standby पर रहता है और वही सामग्री चाहिए तो disk पढ़े बिना लौट सकता है।
• Modified page तुरंत reuse नहीं हो सकता।
  Private सामग्री pagefile में writeback हो सकने के बाद reuse योग्य होती है; mapped file, संबंधित file में writeback हो सकने के बाद; इत्यादि।
• Available में Standby शामिल है।
  Standby ऐसा cache है जो अभी सामग्री रखता है और साथ ही reuse उम्मीदवार जिसे जरूरत हो तो तुरंत लिया जा सकता है।¹
• Pagefile में लेखन ऐसा batch काम नहीं है जो RAM पूरी तरह खत्म होने के बाद ही शुरू हो।
  यह Modified list और memory pressure के अनुसार background में चलता है।²³
• Pagefile केवल «धीमी RAM» नहीं है।
  यह Commit Limit बढ़ाती है, modified private page का backing store बनती है, और crash dump support देती है।⁴
• Pagefile बंद करने से memory leak ठीक नहीं होता।
  Commit Limit गिरता है, और RAM का प्रभावी उपयोग तथा dump पकड़ने की क्षमता खो सकती है।

एक वाक्य में: Windows page त्यागने से पहले जाँचता है कि वह फिर चाहिए हो सकता है या नहीं, और क्या कोई जगह है जहाँ से original सामग्री restore की जा सके।

2. PFN database — physical-RAM पक्ष की ledger

भाग 1 में देखा PTE virtual page से physical page का translation दर्शाता था। वह ledger जो इसे physical-page पक्ष से देखती है और पीछा करती है «यह RAM page अभी किस काम में है» PFN database है। PFN का अर्थ Page Frame Number है: page इकाइयों में क्रमांकित physical RAM।

एक PFN entry अवधारणात्मक रूप से निम्न जानकारी track करती है।

• Physical page की वर्तमान state
• Reference count और share count
• संबंधित PTE
• क्या वह modified है
• वह किस page list से संबंधित है
• NUMA node और priority संबंधी जानकारी

WinDbg में !pfn किसी खास PFN की जानकारी दिखाता है, और !memusage physical-memory usage तथा प्रत्येक page list के योग दिखाता है।⁵⁶ बिना kernel debugger के वही संसार देखने के लिए Sysinternals RAMMap उपलब्ध है। Use Counts उद्देश्य और page list दिखाता है, Priority Summary priority के अनुसार Standby, और Physical Pages per-page usage।⁷

3. पाँच states को एक चित्र में जोड़ना

यह लेख physical page के प्रवाह को निम्न पाँच states के रूप में सरल मानता है। सख्ती से, वर्तमान Windows में यहाँ न खींची गई states और lists हैं — priority के अनुसार Standby, Transition, Bad और अन्य — और Active किसी एक «Active list» से कम, valid PTE के माध्यम से Working Set आदि से referenced होने की state को दर्शाता है। फिर भी ऐप की memory व्यवहार पढ़ने के लिए यह चित्र पर्याप्त उपयोगी है।

चित्र 1: Working Set में referenced page clean हो तो Standby में और dirty हो तो Modified में जाता है। वही सामग्री लौट सकती है; दूसरा उपयोग page को सीधे reuse करता है या zero चाहिए वाले allocation के लिए Free/Zeroed से गुज़रता है।

flowchart LR
    zeroed["Zeroed\nशून्य किया"] -->|पहला Touch| active["Active / Valid\nWorking Set में referenced"]
    active -->|clean trim| standby["Standby\nसामग्री सहित reuse उम्मीदवार"]
    active -->|dirty trim| modified["Modified\nWriteback की प्रतीक्षा"]
    modified -->|लेखन पूरा| standby
    standby -->|Soft fault से वापसी| active
    standby -->|पुरानी पहचान छोड़ें| free["Free\nअभी zero नहीं"]
    standby -->|सीधे दूसरे काम में| active
    free -->|Zero वाली allocation के लिए| zeroed

इस चित्र का सबसे महत्वपूर्ण बिंदु यह है कि Working Set छोड़ना और सामग्री खोना एक ही बात नहीं हैं। साथ ही, जब Standby page दूसरे काम के लिए लिया जाता है, वह जरूरी नहीं क्रम से Free/Zeroed से गुज़रे। अगर उसे user mode को नए demand-zero private page के रूप में सौंपा जाएगा, पुरानी सामग्री मिटानी होगी; अगर पूरा page overwrite होगा, जैसे file पढ़ने का destination, Standby पहचान हटाकर page सीधे reuse हो सकता है।

4. Active / Valid — वह physical page जिसे अभी reference किया जा सकता है

Active/Valid page valid PTE के माध्यम से process के Working Set या system space से referenced होता है। CPU सामान्य address-translation से पहुँचता है, इसलिए access स्वयं को page fault की जरूरत नहीं।

हालाँकि कोई guarantee नहीं कि page Active रहेगा। Available memory बनाए रखने के लिए memory manager Working Set आकार, page हाल में कितना इस्तेमाल हुआ, और ऐसे कारक देखता है, और उम्मीदवार pages trim करता है। Microsoft का Working Set दस्तावेज़ भी बताता है कि available memory बनाने के लिए memory manager Working Set से pages हटाता है।⁸

4.1. Trim free करना नहीं है

Working Set trim मुख्यतः valid PTE से तुरंत referenced होने की resident state बदलता है। निम्न चार को अलग घटनाएँ मानें।

• Working Set से हटाना
• Commit free करना
• Virtual address range free करना
• Original data खोना

EmptyWorkingSet या किसी tool का «Trim Working Set» चलाना VirtualFree या heap free का विकल्प नहीं है। अगर आप उसी page को फिर छूते हैं, वह Standby से soft fault या backing store से hard fault से लौटता है। इसलिए «मैंने Working Set छोटा किया» का अर्थ «मैंने leak ठीक किया» नहीं है।

5. Clean page Standby में जाता है

Page Working Set से निकलने के बाद भी, अगर उसकी सामग्री अभी original file से मेल खाती है या उसके पास पहले से सुरक्षित backing store है, उसे Standby पर रखा जा सकता है। Representative उदाहरण:

• Unmodified EXE/DLL code
• Unmodified memory-mapped file
• पहले से writeback हुआ private page
• File cache में बची data

Standby page पिछली सामग्री से अपना संबंध रखता है। जब वही process या दूसरी process उस सामग्री को चाहती है, अगर page अभी reuse नहीं हुआ, PTE फिर जोड़ने वाला soft fault उसे restore करने के लिए काफी है।

दूसरी ओर, अगर दूसरे allocation को physical page चाहिए, पुरानी Standby पहचान छोड़कर page reuse हो सकता है। अगर reuse destination zero initialization चाहिए वाला user-mode private page है, Zeroed page तैयार होता है; अगर पूरा page file सामग्री आदि से overwrite होगा, उसे बिना zero किए सीधे पुनः सौंपा जा सकता है।

यही दोहरापन Standby के cache और Available दोनों होने का कारण है।

5.1. Available में Standby क्यों शामिल है

MEMORYSTATUSEX.ullAvailPhys उस physical memory को दर्शाता है जिसे disk पर लिखे बिना तुरंत reuse किया जा सकता है, और वह Standby, Free तथा Zeroed का योग है।¹

flowchart LR
    accTitle: Available बनाने वाली तीन page lists
    accDescr: Available physical memory Standby, Free और Zeroed का योग है; Working Set में referenced Active pages शामिल नहीं हैं
    standby["Standby（सामग्री रखने वाला reuse उम्मीदवार）"] --> avail["Available（available physical memory）"]
    free["Free（unused, zero नहीं）"] --> avail
    zeroed["Zeroed（unused और zero）"] --> avail
    active["Active（Working Set में referenced）"] -.->|शामिल नहीं| avail

चित्र 2: Available Standby, Free और Zeroed का योग है। वह Standby जो अभी सामग्री रखता है भी «available» गिना जाता है।

इसलिए Task Manager में «Free कम है, फिर भी Cached/Standby ऊँचा है और Available पर्याप्त» दिखना विरोधाभास नहीं है। Windows खाली RAM को बेकार नहीं छोड़ता; वह हाल में इस्तेमाल files और code Standby पर छोड़ता है ताकि जरूरत हो तो cache के रूप में जल्दी reuse हों, और दूसरे काम को चाहिए तो ले लेता है।

यह निष्कर्ष न निकालें कि «Free कम है, इसलिए तुरंत memory कम है»; Available, Commit, hard fault और processing latency साथ देखें।

6. Dirty page Modified पर प्रतीक्षा करता है

जब ऐप page पर लिखता है, वह सामग्री original backing store से मेल नहीं खाती। उस dirty page को दूसरे काम के लिए overwrite करना data खो देगा। इसलिए Working Set से निकाला modified page Modified पर writeback की प्रतीक्षा करता है।

Writeback destination page के type पर निर्भर करता है।

Microsoft का pagefile दस्तावेज़ भी बताता है कि disk पर पहले से मौजूद .dll, .exe और साधारण files को pagefile में फिर लिखने की जरूरत नहीं, और original disk copy बिना modified data pagefile का उम्मीदवार बनता है।²

6.1. Modified Page Writer

Modified Page Writer एक सिस्टम worker है जो memory manager द्वारा track किए गए, pagefile से backed dirty pages scan करता है और उन्हें pagefile में लिखता है।³ Mapped file पक्ष पर Mapped Page Writer जैसे पथ हैं, जो file system और cache manager के साथ मिलकर संबंधित file में writeback करते हैं।

यहाँ महत्वपूर्ण यह है कि लेखन «RAM 0 bytes होने तक कुछ न करना» योजना नहीं है। Windows भविष्य में reuse योग्य pages background में तैयार करता है, Modified list, Available, pagefile की स्थिति आदि के अनुसार। जब writeback पूरा हो और अन्य valid references न हों, page अपनी सामग्री के साथ Standby में आगे बढ़ता है।

flowchart TB
    accTitle: Modified page के writeback पथ
    accDescr: Working Set छोड़ने वाला modified page Modified list पर प्रतीक्षा करता है; private page के लिए, अगर pagefile configure है, Modified Page Writer उसे pagefile में लिखता है, और mapped file का page Mapped Page Writer आदि संबंधित data file में writeback करता है, फिर सामग्री के साथ Standby में जाता है
    dirty["Working Set छोड़ा modified page"] --> modified["Modified list पर writeback की प्रतीक्षा"]
    modified -->|"Private page（pagefile configure होने पर）"| mpw["Modified Page Writer pagefile में लिखता है"]
    modified -->|Mapped file का page| mapped["Mapped Page Writer आदि संबंधित file में writeback करता है"]
    mpw --> standby["Writeback के बाद, सामग्री के साथ Standby"]
    mapped --> standby

चित्र 3: Writeback destination page के type से तय होता है, और दोनों पथ background में चलते हैं। Pagefile बंद सिस्टम पर private-page पक्ष का writeback destination नहीं होता, इसलिए modified private pages RAM में रहते हैं।

6.2. Page output और pagefile-specific I/O अलग करना

निम्न counters आसानी से उलझते हैं; पुष्टि करें कि उनका अर्थ क्या है।

• Memory\\Page Writes/sec: Physical memory खाली करने के लिए issued paging write I/O की संख्या
• Memory\\Pages Output/sec: उन writes से disk पर लिखे pages की संख्या
• Memory\\Page Reads/sec: Hard fault हल करने के लिए issued disk-read I/O की संख्या
• Memory\\Pages Input/sec: उन reads से RAM में आए pages की संख्या

ध्यान दें कि Page Writes/sec और Pages Output/sec ऐसे counters नहीं जो अकेले pagefile पहचानें। वे file-backed dirty pages writeback करने वाले पथ पर भी बढ़ सकते हैं, जैसे mapped files। उलटा, input पक्ष भी pagefile, DLL, EXE और memory-mapped files में भेद नहीं करता।² अगर आप pagefile.sys specific I/O पहचानना चाहते हैं, इन चार counters से अकेले अनुमान न लगाएँ; ETW/WPA से File I/O और Disk I/O record करें और FileObject तथा FileName मिलाकर लक्ष्य file पुष्टि करें।⁹

एक और बिंदु: पहले pagefile में लिखना तुरंत disk से वापस पढ़ना नहीं है। अगर page access नहीं होता, writeback हुए page को RAM से हटाकर physical memory अधिक इस्तेमाल होने वाले pages को दी जा सकती है।

7. Standby, Free और Zeroed में अंतर

7.1. Standby

वह state जो अभी पिछली सामग्री से संबंध रखती है।

• अगर वही सामग्री चाहिए, soft fault से लौट सकती है
• अगर दूसरे काम को चाहिए, पुरानी पहचान छोड़कर reuse हो सकती है
• Priority के अनुसार Standby lists हैं

7.2. Free

पिछली सामग्री से valid संबंध खो चुका है, और page allocatable है। हालाँकि पुराना bit pattern अभी page में रह सकता है। उसे जैसा है वैसा user mode को देना पिछली process की जानकारी leak करने का जोखिम है।

7.3. Zeroed

सामग्री zero है, और page नए user-mode page के रूप में सुरक्षित सौंपा जा सकता है। भाग 1 का demand-zero fault available Zeroed page पाकर PTE से बाँधने का representative मामला था। Free से Zeroed की तैयारी माँग और सिस्टम state के अनुसार होती है।

इसलिए भले «Free» और «Zeroed» दोनों unused दिखें, security-संबंधी तैयारी में वे भिन्न हैं।

8. Memory compression store — RAM के अंदर एक और destination बनाना

Windows 10 से, memory pressure होने पर memory manager कुछ मामलों में कम-इस्तेमाल pages को तुरंत disk पर लिखने के बजाय RAM में compress कर सकता है। Compressed pages का वह संग्रह compression store है।

प्रारंभिक Windows 10 implementation में compression store System process के Working Set में गिना जाता था, लेकिन वर्तमान Windows पर वह debugger process lists में dedicated Memory Compression process के रूप में दिखता है। इसलिए वर्तमान compression मात्रा जाँचते समय केवल System process के Working Set का पीछा न करें। उद्देश्य स्वयं — अधिक ऐप physical memory में रखना और disk I/O घटाना — नहीं बदला।¹⁰¹¹

फिर भी निम्न बिंदु याद रखें।

• Compressed pages अभी भी RAM इस्तेमाल करते हैं
• Compression और decompression की CPU लागत है
• Compression Commit वादा मिटाता नहीं
• «हमेशा compress करें, फिर pagefile» का निश्चित क्रम नहीं है
• Policy page के type, pressure और access history से बदलती है

Task Manager का «उपयोग में (compressed)» यह नहीं कहता कि compression ने physical memory पूरी खाली कर दी। Compression store ऐसी सुविधा नहीं जो pagefile unnecessary बनाए; वह RAM और storage के बीच I/O घटाने के लिए CPU इस्तेमाल करने वाला एक विकल्प जोड़ता है।

9. Pagefile की वास्तविक भूमिका

Pagefile की कम से कम तीन भूमिकाएँ हैं।

flowchart LR
    accTitle: Pagefile की तीन भूमिकाएँ
    accDescr: Pagefile Commit Limit बढ़ाती है, कम-access modified private pages का backing store बनती है, और सिस्टम crash dump का पात्र बनती है
    pagefile["Pagefile"] --> limit["Commit Limit बढ़ाना（ceiling पक्ष का अंतर）"]
    pagefile --> backing["Modified private pages का backing store"]
    pagefile --> dump["सिस्टम crash dump का पात्र"]

चित्र 4: Pagefile की भूमिका केवल «धीमी RAM» नहीं है। Usage 0 होने पर भी वह ceiling और dump support देती है।

9.1. Commit Limit बढ़ाना

सिस्टम का Commit Limit मोटे तौर पर RAM plus सभी pagefiles के योग से तय होता है। बिना pagefile Commit Limit installed RAM से थोड़ा छोटा स्तर तक गिरता है। जब Commit Total ceiling तक पहुँचता है, नया Commit fail होता है और abnormal ऐप termination या सिस्टम समस्या तक जा सकता है।⁴

यह «अभी pagefile.sys में कितने GB लिखे हैं» से अलग बात है। Pagefile Commit वादे को support देने वाला ceiling पक्ष का अंतर भी है।

9.2. Modified private pages support देना

अगर कम-access modified private pages pagefile से backed हों, उन physical pages को RAM से हटाकर अक्सर इस्तेमाल code और data को दिया जा सकता है।⁴ Pagefile बंद करने से ऐसे pages RAM से निकालने का विकल्प घटता है। सिर्फ यह नहीं कहा जा सकता कि «तेज़ है क्योंकि page-out नहीं होता»।

9.3. सिस्टम crash dump support देना

सिस्टम crash पर Memory.dmp बनाने के लिए ऐसी pagefile या dedicated dump file चाहिए जो चुनी dump method support दे सके।² Full memory dump, kernel memory dump और automatic memory dump आवश्यक मात्रा में भिन्न हैं।

जहाँ crash जाँचे जाते हैं, केवल जगह बचाने के लिए pagefile मिटाना यह मतलब हो सकता है कि सबसे ज्यादा जरूरत पर सबूत न हों। संग्रह विधियों के लिए «An Introduction to Collecting Windows Crash Dumps - WER/ProcDump/WinDbg» भी देखें।

10. सही आकार एकसमान नहीं है

Pagefile आकार «RAM का 1.5 गुना» जैसे निश्चित सूत्र अकेले से तय नहीं करना चाहिए। Microsoft बताता है कि उपयुक्त आकार निम्न दो बिंदुओं पर सिस्टम के अनुसार भिन्न है और generalize नहीं हो सकता।²

1. Peak System Commit Charge
2. आपको चाहिए सिस्टम crash dump

व्यवहार में इस क्रम में सोचें।

10.1. System-managed को आधार मानकर शुरू करें

Windows default system-managed है। वह installed RAM, Commit माँग, crash-dump आवश्यकताओं आदि के अनुसार बढ़ता-घटता है। विशेष बाधा या माप परिणाम न हो तो यहीं से शुरू करना सुरक्षित चुनाव है।

10.2. Representative load पर peak Commit मापें

PerfMon में निम्न counters लंबे समय एकत्र करें।

• Memory\\Committed Bytes
• Memory\\Commit Limit
• Memory\\% Committed Bytes In Use
• Memory\\Modified Page List Bytes
• Paging File(*)\\% Usage
• Memory\\Available MBytes
• Memory\\Page Reads/sec
• Memory\\Page Writes/sec

संग्रह अवधि में वास्तविक peak शामिल करें — month-end processing, backup, build, कई users एक साथ, इत्यादि।

ऊँचा pagefile usage प्रतिशत अकेले storage-performance समस्या सिद्ध नहीं करता। हालाँकि ceiling से चिपकना insufficient capacity की चेतावनी है। साथ देखें कि Commit ceiling के पास है या नहीं, बहुत Modified प्रतीक्षा कर रहा है या नहीं, और disk saturated है या नहीं।²

10.3. पहले dump आवश्यकता तय करें

तय करें कि full memory dump चाहिए, kernel memory dump काफी है, या dedicated dump file इस्तेमाल करेंगे। अगर निश्चित आकार पर बदलें, उसे न केवल peak Commit बल्कि dump आवश्यकता भी पूरी करनी चाहिए।

11. स्वयं देखें

11.1. RAMMap में page lists देखना

RAMMap Administrator के रूप में शुरू करें और पहले Use Counts खोलें।⁷ देखने योग्य मद निम्न हैं।

• Active
• Standby
• Modified
• Modified no write
• Free
• Zeroed

Priority Summary से पुष्टि हो सकती है कि Standby priority से बँटा है। Processes प्रत्येक process का Working Set दिखाता है; File Summary और File Details RAM में file data का पीछा कराते हैं।

परीक्षण के रूप में काफी बड़ी local file एक बार पढ़ें, पठन समाप्त करें, फिर Refresh। उस file के pages File Summary या Standby पक्ष पर रह सकते हैं। वही file फिर पढ़ना अभी reuse न हुए pages बिना disk I/O, या कम I/O से restore कर सकता है। परिणाम memory pressure, antivirus और file आकार से बदलते हैं, इसलिए एक संख्या-समूह से अधिक state-transition की दिशा देखें।

ध्यान दें कि RAMMap का Empty मेनू सिस्टम state कृत्रिम रूप से बदलता है। Standby को production performance सुधार के रूप में साफ़ न करें; केवल अलग test environment पर इस्तेमाल करें।

11.2. Testlimit से Commit और Touch अलग करना

Testlimit Sysinternals tool है जो memory, handles, process, thread आदि की resource कमी simulate करता है। पहले अपने पास binary पर निम्न चलाएँ और दिखाई गई version तथा usage पुष्टि करें।

.\\testlimit64.exe -?

निम्न Testlimit v5.24 को लक्ष्य करता है। आधिकारिक v5.24 syntax में -m [MB] निर्दिष्ट मात्रा memory allocate करता है, -d [MB] allocate और Touch, -e [seconds] allocation interval है, और -c [count] allocation संख्या है। -c अंतिम specify करें। अगर स्थानीय दिखता भिन्न हो, उस usage को प्राथमिकता दें।¹²

फिर disposable VM पर छोटा आज़माएँ।

# -m 64: 64 MiB allocate, -e 1: 1-second interval, -c 8: 8 बार बाद रुकें
.\\testlimit64.exe -m 64 -e 1 -c 8

# वही संख्या और interval, -d से प्रत्येक क्षेत्र Touch
.\\testlimit64.exe -d 64 -e 1 -c 8

चलते समय निम्न एक साथ record करें।

• Task Manager का «Committed X/Y»
• RAMMap का Active, Modified और Standby
• Memory\\Committed Bytes
• Memory\\Commit Limit
• Memory\\Available MBytes
• Memory\\Modified Page List Bytes

अगर वास्तव में Commit exhaustion reproduce करें, host PC पर न करें; snapshot वाले VM पर संख्या चरणबद्ध बढ़ाएँ। Ceiling तक auto-allocate करने वाला run स्क्रीन जमा सकता है, processes abnormal terminate कर सकता है, और logs खो सकता है। उद्देश्य OS अस्थिर करना नहीं; यह देखना है कि Commit Limit के पास पहुँचने पर नया Commit fail होता है।

12. व्यवहार में बचने योग्य चार गलत पठन

12.1. «Standby ऊँचा है, इसलिए memory leak»

Standby reuse योग्य cache है और Available में शामिल है। Leak का निर्णय इस से करें कि load खत्म होने के बाद भी process-private Commit baseline और allocation breakdown बढ़ते रहते हैं या नहीं।

12.2. «Working Set काटना leak ठीक कर देगा»

Trim केवल residency बदलता है; वह Commit या virtual allocation free नहीं करता। पुनः access पर page fault से लौटता है।

12.3. «Pagefile usage 0 है, इसलिए unnecessary»

Pagefile न केवल वर्तमान लेखन मात्रा बल्कि Commit Limit और crash dump support देती है। केवल रोज़मर्रा usage से हटाने का निर्णय peak अंतर और failure पर सबूत खो देता है।

12.4. «पहले memory compression, फिर हमेशा pagefile»

Compression निश्चित serial pipeline नहीं है। Windows page के type, compression efficiency, CPU load, memory pressure और backing store मौजूद है या नहीं के अनुसार dynamically चुनता है।

13. सारांश

• PFN database वह ledger है जो physical page के ownership, reference, modification और page-list state track करती है।
• Working Set छोड़ने वाला clean page Standby पर रहता है और वही सामग्री चाहिए तो soft fault से लौट सकता है।⁸
• Dirty page Modified पर प्रतीक्षा करता है और private हो तो pagefile में, mapped हो तो संबंधित file में writeback होता है।³
• Available Standby, Free और Zeroed का योग है; बड़ा Standby अकेले memory कमी नहीं है।¹
• Memory compression I/O घटाने के लिए RAM में pages compress करता है, लेकिन Commit और pagefile की भूमिकाएँ नहीं मिटाता।¹⁰
• Pagefile Commit Limit, modified private pages और सिस्टम crash dump support देती है।⁴²
• उपयुक्त आकार peak Commit और dump आवश्यकताओं से तय होता है; एकसमान multiplier से तय नहीं हो सकता।²
• Working Set trim और Standby साफ़ करना memory-leak सुधार नहीं हैं।

जारी भाग 3, «Section object और copy-on-write: DLL और file mapping वास्तव में क्या हैं»।

हम पीछा करते हैं कि Standby पर बचे file pages और DLL कई processes से एक ही physical page क्यों दिखते हैं।

संबंधित लेख

• Windows memory की गहराई (भाग 1) — वह क्षण जब virtual address physical RAM बन जाता है
• What Does Windows’ “Memory Usage” Actually Mean? — Correctly Reading Working Set, Private Bytes, Commit, and the Page File
• The Depths of Windows I/O (Part 4) — Cache Manager: When Does Your WriteFile Actually Reach the Disk?
• An Introduction to Collecting Windows Crash Dumps - WER/ProcDump/WinDbg
• Process Explorer / Handle / VMMap in Practice — Chasing Hangs, Leaks, and “File in Use” from the State Right Now

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

KomuraSoft LLC Windows application memory pressure, Commit exhaustion, paging, Working Set वृद्धि और crash-dump collection डिज़ाइन की जाँच करता है।

• Windows ऐप विकास
• बग और कारणों की जाँच
• मौजूदा संपत्तियों का पुनरुपयोग और माइग्रेशन
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

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

संबंधित विषय

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

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

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

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

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

क्या page Working Set छोड़ते ही pagefile में लिख दिया जाता है?

नहीं। Unmodified page अपनी सामग्री के साथ Standby में जाता है और तुरंत reuse योग्य cache बन जाता है। Modified page Modified में जाता है, और आवश्यकतानुसार pagefile या संबंधित file में writeback होने के बाद Standby जैसे reuse योग्य state में आगे बढ़ता है।

क्या Task Manager का Available Standby memory शामिल करता है?

हाँ। Windows जो available physical memory बताता है वह Standby, Free और Zeroed का योग है। Standby अभी भी पुरानी सामग्री रखता है, लेकिन क्योंकि जरूरत पड़ने पर उसे तुरंत दूसरे काम के लिए reuse किया जा सकता है, उसे available memory गिना जाता है।

क्या pagefile में लेखन तभी शुरू होता है जब RAM पूरी तरह खत्म हो जाए?

नहीं। Windows Modified list और available memory की स्थिति के अनुसार कम-access वाले modified pages background में writeback करता है। यह ऐसा सरल mechanism नहीं है जो पूर्ण समाप्ति की प्रतीक्षा करे और फिर सब कुछ एक साथ निकाल दे।

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

सामान्य नियम के रूप में यह नहीं कहा जा सकता। बंद करने से Commit Limit गिरता है, कम-access वाले modified pages RAM से निकालना कठिन होता है, और सिस्टम crash dump भी प्रभावित होते हैं। आमतौर पर उसे system-managed छोड़ते हैं और peak Commit तथा dump आवश्यकताओं को मापकर निर्णय लेते हैं।

अगर memory compression है तो क्या pagefile unnecessary है?

वह unnecessary नहीं हो जाती। Compression store I/O घटाने के लिए RAM में pages compress करता है, लेकिन compressed pages अभी भी physical memory इस्तेमाल करते हैं और Commit guarantee की जगह नहीं लेते। Compression और page-out के बीच चुनाव memory manager की dynamic policy है।

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

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

Go Komura

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

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