Windows-এর "মেমরি ব্যবহার" আসলে কী বোঝায়? — Working Set, Private Bytes, Commit ও পেজ ফাইল সঠিকভাবে পড়া
· Go Komura · Windows, Windows ডেভেলপমেন্ট, মেমরি ব্যবস্থাপনা, Working Set, Private Bytes, Commit, পেজ ফাইল, পারফরম্যান্স মনিটরিং, সমস্যা সমাধান, Sysinternals
Task Manager কোনো প্রক্রিয়ার “Memory” ১.২GB দেখায়। অথচ Process Explorer Working Set ১.৫GB ও Private Bytes ২.৪GB দেখায়, আর 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 পাশের সংখ্যা কীভাবে পড়বেন।
১. আগে উপসংহার
- Working Set এখন RAM-এ নিবাসী পেজের সেট। শুধু প্রক্রিয়া-নিজস্ব পেজ নয়, অন্য প্রক্রিয়ার সাথে ভাগযোগ্য পেজও ধরে, যেমন DLL কোড ও মেমরি-ম্যাপড ফাইল।1
- Private Working Set হলো Working Set-এর সেই অংশ যা এখন শুধু সেই প্রক্রিয়ার। “এখন এই প্রক্রিয়া একা যে RAM দখল করে” তার আনুমানিক, কিন্তু অ্যাপ যে মোট বরাদ্দ করেছে তা নয়।2
- Private Bytes সেই প্রক্রিয়ার নিজস্ব কমিট পরিমাণ। এখন RAM-এ নিবাসী কি না তার থেকে আলাদা মेट্রিক। Win32 API স্ট্রাকচারের
PagefileUsageক্ষেত্রও বর্তমান Windows-এ কার্যত একই Commit Charge দেখায়, পেজ ফাইলে সত্যি লেখা বাইট নয়।2 - Task Manager-এর “Committed X/Y” X-কে সিস্টেমের বর্তমান মোট কমিট ও Y-কে কমিট সিলিং দেখায়। X পেজ ফাইল ব্যবহার নয়। Y মোটামুটি RAM প্লাস পেজ ফাইলে নির্ধারিত।3
- Reserve ও Commit আলাদা জিনিস। শুধু ভার্চুয়াল অ্যাড্রেস রেঞ্জ Reserve করা ভবিষ্যতের জন্য আলাদা রাখা; RAM বা কমিট সিলিং সমপরিমাণ খরচ করে না।45
- পেজ ফল্ট মানেই ডিস্ক I/O নয়। সফট ফল্ট RAM-এর ভেতরে সমাধান হয়, হার্ড ফল্ট পেজ ফাইল, এক্সিকিউটেবল, মেমরি-ম্যাপড ফাইল ইত্যাদি থেকে পড়ে।16
- মেমরি লিক একবারের পাঠ থেকে নয়, একই লোড বারবার করলে ঢাল থেকে বিচার হয়। বিশেষ করে দেখুন প্রক্রিয়াকরণ শেষেও Private Bytes ও ভাঙন ধাপে ধাপে বাড়ে কি না, একই স্থির অবস্থায় ফেরে না।
এক বাক্যে: Working Set “এখন RAM-এ পরিমাণ”, Private Bytes “এই প্রক্রিয়াকে বিশেষভাবে প্রতিশ্রুত পরিমাণ”, আর Commit “পুরো সিস্টেম যে পরিমাণ প্রতিশ্রুতি দিয়েছে”।
flowchart TB
accTitle: সঠিক Windows মেমরি মेट্রিক বেছে নেওয়া
accDescr: কোন মेट্রিক দেখবেন তা নির্ভর করে RAM নিবাস, প্রক্রিয়া-নিজস্ব কমিট, সিস্টেম-ব্যাপী কমিট, না ভার্চুয়াল অ্যাড্রেস রেঞ্জ জানতে চান
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["ভার্চুয়াল অ্যাড্রেস স্পেস"]
চিত্র ১: “মেমরি বেশি” পর্যবেক্ষণকে আগে চার আলাদা প্রশ্নে ভাঙুন।
২. “মেমরি ব্যবহার” চার অক্ষে ভাঙা
শুরুতে 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"]
চিত্র ২: এক পেজেও অ্যাড্রেস অবস্থা, ব্যাকিং, নিবাস ও ভাগযোগ্যতা আলাদা নির্ধারিত।
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
চিত্র ৩: 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” সবসময় সত্য নয়।
৩. ভার্চুয়াল অ্যাড্রেস স্পেস — Reserve ও Commit আলাদা
৩.১. ভার্চুয়াল অ্যাড্রেস ফিজিক্যাল RAM অ্যাড্রেস নয়
প্রতিটি প্রক্রিয়ার নিজস্ব প্রাইভেট ভার্চুয়াল অ্যাড্রেস স্পেস আছে। অ্যাপ যে পয়েন্টার নিয়ে কাজ করে তা সরাসরি ফিজিক্যাল RAM অবস্থান দেখায় না; Windows পেজ টেবিল দিয়ে ভার্চুয়াল অ্যাড্রেস ফিজিক্যাল পেজ বা ফাইলের ডেটার সাথে ম্যাপে করে।7
ফলে ৬৪GB RAM লাগানো PC-তেও কোনো ৩২-বিট প্রক্রিয়ার ভার্চুয়াল অ্যাড্রেস স্পেস সাধারণত তার চেয়ে অনেক ছোট। উল্টো, ৬৪-বিট প্রক্রিয়ার ভার্চুয়াল অ্যাড্রেস স্পেস ফিজিক্যাল RAM-এর চেয়ে বড় হওয়াও সাধারণ।
৩.২. Reserved মানে শুধু “অ্যাড্রেস আটকে রাখা”
VirtualAlloc-এর MEM_RESERVE ভবিষ্যতের জন্য ধারাবাহিক ভার্চুয়াল অ্যাড্রেস রেঞ্জ রিজার্ভ করে। এই পর্যায়ে পেজের সাথে ফিজিক্যাল স্টোরেজ যুক্ত নয়, আর রেঞ্জ পড়া-লেখা যায় না।45
যেমন ডেটাবেস বা রানটাইম ভবিষ্যৎ বৃদ্ধির জন্য ৮GB অ্যাড্রেস রেঞ্জ Reserve করলেও শুধু তাতে ৮GB RAM বা ৮GB Private Bytes খরচ হয় না।
৩.৩. Committed “দরকার হলে ধরব” প্রতিশ্রুতি
MEM_COMMIT ভার্চুয়াল পেজকে Committed অবস্থায় আনে এবং Windows-কে প্রয়োজনীয় ব্যাকিং দেওয়ার প্রতিশ্রুতি করায়। পড়া, লেখা বা এক্সিকিউশন সত্যি অনুমোদিত কি না পেজ প্রোটেকশন — PAGE_READONLY, PAGE_READWRITE, PAGE_EXECUTE, PAGE_NOACCESS ইত্যাদি — আলাদা ঠিক করে, তাই Committed হওয়া নিজে “পড়া-লেখাযোগ্য” নয়। কমিট মুহূর্তে সিস্টেমের Commit Charge-এ গণনা হয়, কিন্তু আসল ফিজিক্যাল পেজ প্রথম অ্যাক্সেস পর্যন্ত নাও দেওয়া হতে পারে। প্রথমবার ছোঁয়া পেজ শূন্য-আরম্ভ হয়, demand-zero fault পেরিয়ে Working Set-এ ঢোকে।51
তাই দুদিকেই “বরাদ্দ” বললেও আসলে এই তিন ধাপ।
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["কমিটেড কিন্তু অনিবাসী"]
চিত্র ৪: Reserve, Commit ও প্রথম অ্যাক্সেস আলাদা ঘটনা, আর প্রত্যেকে আলাদা মेट্রিক নাড়ায়।
এই তিন ধাপ যথাক্রমে Virtual Bytes পরিবার, Private Bytes ও Working Set-এর সংখ্যা আলাদা নাড়ায়।
৩.৪. খালি RAM থাকলেও OutOfMemory কেন হয়
মেমরি অ্যালোকেশন সফল কি না শুধু খালি RAM দিয়ে ঠিক হয় না।
- প্রক্রিয়া ভার্চুয়াল অ্যাড্রেস স্পেস শেষ করেছে
- প্রয়োজনীয় আকারের ধারাবাহিক খালি অ্যাড্রেস রেঞ্জ নেই
- সিস্টেম-ব্যাপী Commit Charge Commit Limit-এ পৌঁছেছে
- Job Object, কন্টেইনার, রানটাইম বা লাইব্রেরির নিজস্ব সীমা আছে
- সেটি ৩২-বিট প্রক্রিয়া
- নেটিভ হিপ খণ্ডিত
৬৪-বিট Windows-এও ৩২-বিট প্রক্রিয়ার ইউজার-মোড ভার্চুয়াল অ্যাড্রেস স্পেস IMAGE_FILE_LARGE_ADDRESS_AWARE না থাকলে সাধারণত ২GB। সেই ফ্ল্যাগ থাকা ৩২-বিট অ্যাপ ৬৪-বিট Windows-এ ৪GB পর্যন্ত ব্যবহার করতে পারে।8
তাই “PC-তে ২০GB খালি RAM আছে, তবু ৩২-বিট অ্যাপ প্রায় ১.৬GB-এ ব্যর্থ” বিরোধ নয়। RAM সমস্যা না হয়ে অ্যাড্রেস স্পেস খণ্ডন বা শক্ত সীমায় ধাক্কা হতে পারে।
৪. Working Set — এখন RAM-এ পেজ
Working Set প্রক্রিয়ার ভার্চুয়াল অ্যাড্রেস স্পেসের সেই পেজ যা এখন ফিজিক্যাল RAM-এ নিবাসী।1
এই সেটে এগুলো মেশানো।
- প্রক্রিয়ার নিজস্ব হিপ ও স্ট্যাক
- EXE ও DLL কোড এবং শুধু-পড়া ডেটা
- মেমরি-ম্যাপড ফাইল
- শেয়ার্ড মেমরি
- copy-on-write-এর পর সেই প্রক্রিয়ার প্রাইভেট হওয়া পেজ
- রানটাইম ও নানা লাইব্রেরি যে পেজ ছুঁয়েছে
৪.১. 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-এ গণনা"]
চিত্র ৫: Working Set নিবাস অনুসারে ওঠে-নামে, কিন্তু একই পেজের কমিট থাকলে Private Bytes কমে না।
৪.২. Working Set-এ শেয়ার্ড পেজ আছে
১০টি প্রক্রিয়া একই DLL-এর কোড পেজ ভাগ করলে সেই পেজ প্রতিটির Working Set-এ দেখা যেতে পারে, অথচ ফিজিক্যাল RAM-এ এক কপি। Working Set যোগফল লাগানো RAM ছাড়িয়ে গেলেই অবিলম্বে সমস্যা নয়।
“এখন এই প্রক্রিয়া একা যে RAM দখল করে” তার কাছাকাছি যেতে Private Working Set দেখুন। তবু এটি “সেই প্রক্রিয়া যে মোট মেমরি বরাদ্দ করেছে” নয় — কঠোরভাবে এখন নিবাসী প্রাইভেট পেজ।
৪.৩. Working Set জোর করে ছোট করলে লিক সারে না
EmptyWorkingSet বা SetProcessWorkingSetSize দিয়ে প্রক্রিয়ার Working Set থেকে পেজ সরানো যায়। কিন্তু এটি কমিট মুক্ত বা হিপ রেফারেন্স ছেড়ে দেওয়ার অপারেশন নয়। দেখতে RAM ব্যবহার নামে, Private Bytes অপরিবর্তিত থাকে, আর পরের অ্যাক্সেসে পেজ ফল্টের ঝাঁক হতে পারে।9
Task Manager-এর সংখ্যা শুধু “মেমরি কমান” বোতাম চাপার ঠিক পরে ছোট হয় আর কাজ আবার শুরু করলেই চড়ে, তবে তা সত্যি “মুক্তি” নয়, শুধু Working Set Trim হতে পারে।
৫. Private Bytes — প্রক্রিয়ার নিজস্ব কমিট পরিমাণ
Private Bytes সেই প্রক্রিয়ার জন্য বিশেষভাবে কমিটেড ভার্চুয়াল মেমরির পরিমাণ। এটি অন্য প্রক্রিয়ার সাথে ভাগ করা যায় না এমন Commit Charge, আর এখন RAM-এ নিবাসী কি না ধরে না। Microsoft-এর PROCESS_MEMORY_COUNTERS_EX-এ PrivateUsage এই মানের সাথে মিলে।102
Win32 API-তে বিভ্রান্তিকর নামের ক্ষেত্র PagefileUsageও আছে, কিন্তু বর্তমান ডকুমেন্ট এটিকে “সেই প্রক্রিয়ার Commit Charge” বলে এবং PrivateUsage-এর সমান বলে। অর্থাৎ ২GB Private Bytes মানে “pagefile.sys-এ ২GB লেখা হয়েছে” নয়।2
Private Bytes-এ সাধারণত এগুলো প্রভাব ফেলে।
HeapAlloc,malloc,newইত্যাদির নেটিভ হিপের কমিট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) পুরো ভিউয়ের আকারে বাড়তে পারে।11
৫.১. 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["পুল, ক্যাশ, খণ্ডন"]
চিত্র ৬: অ্যাপের ভেতরে পুনর্ব্যবহারযোগ্য হওয়া আর তার Commit OS-এ ফেরানো এক নয়।
৫.২. লিকের শক্ত প্রার্থী আকৃতি
নিচের মতো বৃদ্ধি, যেখানে প্রতি লোড চক্রে মেঝে “সিঁড়ি”র মতো ওঠে, নজরদারির যোগ্য।
Private Bytes
^
| ________
| ______|
| ______|
|_____|
+----------------------------> একই প্রক্রিয়াকরণের পুনরাবৃত্তি
তবু সিঁড়ি আকৃতি প্রথম JIT, ফন্ট, ছবি ডিকোডার, কানেকশন পুল বা ক্যাশ ওয়ার্ম-আপের কয়েক চক্র বৃদ্ধি হতে পারে, তারপর স্থির। গুরুত্বপূর্ণ বাড়ছে নয়, স্থির অবস্থায় মিলছে না।
৬. 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-এর চেয়ে একটু ছোট হয়।36
flowchart TB
accTitle: System Commit Charge ও Commit Limit-এর সম্পর্ক
accDescr: প্রতি-প্রক্রিয়া, শেয়ার্ড সেকশন ও কার্নেল কমিট বর্তমান মান 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
চিত্র ৭: X বর্তমান প্রতিশ্রুত পরিমাণ, Y সেই প্রতিশ্রুতি ধরার সিলিং — পেজ ফাইল ব্যবহারের প্রদর্শন নয়।
System Commit Charge-এ শুধু প্রতি প্রক্রিয়ার Private Bytes যোগফল নয়, পেজ-ফাইল-ব্যাকড শেয়ার্ড সেকশনের Commit ও কার্নেলের খরচ করা Commitও আছে। তাই প্রতি-প্রক্রিয়া Private Bytes যোগফল একা X পুরো ব্যাখ্যা করে না।
৬.১. Commit Charge পেজ ফাইল ব্যবহার নয়
১৬GB RAM, ১৬GB পেজ ফাইল, Committed 20/31GB সিস্টেম ভাবুন।
সেই ২০GB মানে “পেজ ফাইলে ২০GB লেখা” নয়। এটি সেই মোট যার জন্য Windows প্রাইভেট লেখযোগ্য পেজ ইত্যাদিতে, দরকার হলে, RAM বা পেজ ফাইল ব্যাকিং দেওয়ার প্রতিশ্রুতি দিচ্ছে।
সেই মুহূর্তে এমন অবস্থা মেশানো থাকতে পারে:
- অধিকাংশ RAM-এ নিবাসী
- কিছু পেজ ফাইলে পেজ-আউট
- কিছু কমিটেড কিন্তু প্রথম অ্যাক্সেস হয়নি
- কিছু কার্নেল পাশের কমিট হিসেবে খরচ
আসল পেজ ফাইল ব্যবহার দেখতে চাইলে Commit থেকে আলাদা Paging File(*)\% Usage দেখুন। Microsoft-এর নিজস্ব উপাদানও বলে উচ্চ পেজ ফাইল ব্যবহার একা পারফরম্যান্স সমস্যা নয়, Commit Limit পৌঁছানো, Modified Page List ও আসল পেজিং I/O-এর সাথে বিচার করতে হয়।6
৬.২. Commit Limit-এর কাছে কী হয়
System Commit Charge Commit Limit-এ পৌঁছালে নতুন কমিট অনুরোধ ধরা যায় না। তাতে প্রক্রিয়া মেমরি অ্যালোকেশন ব্যর্থতা, অ্যাপ ক্র্যাশ ও সিস্টেম অপ্রতিক্রিয়াশীল হয়।3
এখানে “খালি RAM”-এর চেয়ে Commit-এর X/Y গুরুত্বপূর্ণ। Working Set Trim করে RAM খালি করলেও Commit Charge নিজে না কমলে Commit Limit পৌঁছানো সমাধান হয় না।
৬.৩. পেজ ফাইলের তিন ভূমিকা
পেজ ফাইল প্রধানত এই ভূমিকা রাখে।
- Commit Limit বাড়ানো
- কম ব্যবহৃত পরিবর্তিত পেজ RAM থেকে পেজ-আউট হতে দেওয়া
- কনফিগারেশন অনুসারে সিস্টেম ক্র্যাশ ডাম্প ধরা
পেজ ফাইল বন্ধ করা সরল নয় যে “ডিস্ক I/O সবসময় কমে আর সব দ্রুত হয়”। বরং এটি Commit Limit নামায়, পরিবর্তিত কিন্তু এখন অপ্রয়োজনীয় পেজ RAM-এ রাখে, আর ক্র্যাশে প্রয়োজনীয় ডাম্প তোলা অসম্ভব করতে পারে।36
উপযুক্ত পেজ ফাইল আকার শুধু লাগানো RAM থেকে ঠিক হয় না। Microsoft নিজেই বলে সাধারণীকরণ যায় না, কারণ পিক System Commit Charge ও প্রয়োজনীয় ক্র্যাশ ডাম্পের ধরন সিস্টেমভেদে আলাদা।6
৭. ফিজিক্যাল RAM-এর ভাঙন — শুধু কম Available দিয়ে বিচার নয়
ফিজিক্যাল RAM শুধু ইউজার প্রক্রিয়ার Working Set-এ ব্যবহৃত হয় না।
- প্রতি প্রক্রিয়ার Working Set
- সিস্টেম ফাইল ক্যাশ
- Standby, Modified, Free, Zeroed ইত্যাদি পেজ তালিকা
- কার্নেলের Paged Pool / Nonpaged Pool
- ডিভাইস ড্রাইভার ধরে রাখা মেমরি
- মেমরি কম্প্রেশন স্টোর
- GPU ও অন্য ডিভাইসের সাথে ভাগ বা তাদের জন্য রিজার্ভ অঞ্চল
- হার্ডওয়্যার-রিজার্ভ মেমরি
৭.১. Available-এ পুনর্ব্যবহারযোগ্য ক্যাশও আছে
Windows-এর Available MBytes শুধু সম্পূর্ণ অব্যবহৃত RAM নয়। এটি Free ও Zeroed-এর সাথে সেই Standby পেজও ধরে যা দরকারে পুনর্ব্যবহারযোগ্য।12
- 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
চিত্র ৮: Available-এ সম্পূর্ণ খালি মেমরিই নয়, দরকারে পুনর্ব্যবহারযোগ্য Standbyও আছে।
“খালি RAM বাড়াতে সব ক্যাশ ফেলা” সবসময় জয় নয়। দরকারি ডেটা Standby-তে থাকলে পুনরায় অ্যাক্সেস ডিস্ক না পড়ে দ্রুত Working Set-এ ফেরাতে পারে।
তাই Task Manager-এ Free কম হলেও Available যথেষ্ট আর হার্ড পেজ ফল্ট বা ডিস্ক অপেক্ষা সমস্যা না হলে, Windows হয়তো RAM ক্যাশ হিসেবে কার্যকর ব্যবহার করছে।
৭.২. বড় প্রক্রিয়া নেই তবু RAM কমলে
প্রতি প্রক্রিয়ার Private Working Set যোগ করেও অব্যাখ্যাত মেমরি খরচ অস্বাভাবিক নয়।
- ফাইল ক্যাশ ও মেমরি-ম্যাপড ফাইল
- Nonpaged Pool / Paged Pool
- ড্রাইভার লক করা পেজ
- শেয়ার্ড পেজ
- মেমরি কম্প্রেশন
- ভার্চুয়ালাইজেশন বা GPU সংক্রান্ত বরাদ্দ
এ ক্ষেত্রে প্রক্রিয়া তালিকা তাকিয়ে না থেকে Sysinternals-এর RAMMap-এ Use Counts, Processes, Priority Summary ও File Summary দেখুন। RAMMap ফিজিক্যাল মেমরি উদ্দেশ্য, পেজ তালিকা ও ফাইল অনুসারে ভাঙার অফিসিয়াল টুল।13
শুধু Nonpaged Pool বাড়তে থাকলে ইউজার-মোড অ্যাপের Private Bytes নয়, ড্রাইভার বা কার্নেল পাশের লিক সন্দেহের সময়।
৮. পেজ ফল্ট — বেশি সংখ্যা নিজেই অস্বাভাবিক নয়
Page Fault হয় যখন প্রক্রিয়া এমন পেজে অ্যাক্সেস করে যা এখন তার Working Set-এ নেই। নামে “Fault” থাকলেও এটি ব্যতিক্রমী ব্যর্থতা নয় — ভার্চুয়াল মেমরি চালানোর স্বাভাবিক যন্ত্র।1
৮.১. সফট পেজ ফল্ট
ডিস্ক না পড়ে সমাধান হয়।
- পেজ এখনো Standby বা Transition-এ
- একই শেয়ার্ড পেজ অন্য প্রক্রিয়ার Working Set-এ আগেই আছে
- কমিটেড পেজে প্রথম অ্যাক্সেস ও শূন্য পেজ দেওয়া
- মেমরি ম্যানেজারের আগে-পড়া ইতিমধ্যে RAM-এ এনেছে
তাই বড় \Memory\Page Faults/sec মানেই ডিস্ক I/O বা লেটেন্সি হচ্ছে নয়।
৮.২. হার্ড পেজ ফল্ট
ডিস্কের 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
চিত্র ৯: শুধু “Page Fault” নামে ডিস্ক I/O হয়েছে কি না বলা যায় না।
Microsoft হার্ড ফল্ট মাপার কাউন্টারে \Memory\Pages/sec, \Memory\Page Reads/sec ও \Memory\Pages Input/sec তালিকা করে। এগুলো উঁচু হলেই মেমরি কম নয়, তাই Available MBytes, ডিস্ক লেটেন্সি ও আসল সাড়া সময়ের সাথে সম্পর্ক করুন।6
৮.৩. এক কম্বল সীমা বসাবেন না
“১০০০ Page Faults/sec-এর উপরে অস্বাভাবিক” ধরনের স্থির মান স্টোরেজ, পেজ আকার, ওয়ার্কলোড ও অ্যাক্সেস স্থানীয়তায় অর্থ বদলায়।
বাস্তবে এগুলো একই সময়রেখায় রাখুন।
Memory\Available MBytesMemory\Pages Input/secMemory\Page Reads/sec- লক্ষ্য ডিস্কের Read latency / Queue
- লক্ষ্য প্রক্রিয়ার Working Set ও Private Bytes
- অ্যাপের প্রক্রিয়াকরণ সময়, টাইমআউট ও UI সাড়া
লোড বাড়ার সাথে Available নামে, Pages Input/sec ও ডিস্ক অপেক্ষা বাড়ে, আর প্রক্রিয়াকরণ সময়ও খারাপ হয়, তবে ফিজিক্যাল মেমরি চাপে পেজিং সন্দেহের ভিত্তি জোড়ে।
৯. কোন স্ক্রিন বা টুলে কী দেখবেন
| কী জানতে চান | আগে দেখার মेट্রিক | প্রধান টুল |
|---|---|---|
| লক্ষ্য প্রক্রিয়া এখন RAM-এ কত রাখে | Working Set | Task Manager, Process Explorer, Get-Process |
| তার প্রাইভেট অংশ — প্রক্রিয়া-নিজস্ব RAM | Private Working Set / Working Set - Private | Task Manager Details কলাম, Process Explorer, PerfMon |
| লক্ষ্য প্রক্রিয়ার নিজস্ব কমিট | Private Bytes / Commit Size | Process Explorer, PerfMon, VMMap, Get-Process |
| প্রক্রিয়ার ভার্চুয়াল অ্যাড্রেস রেঞ্জ | Virtual Bytes / Size | Process Explorer, VMMap, Get-Process |
| সিস্টেমের মোট কমিট অবশিষ্ট | 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"]
চিত্র ১০: আগে পরিসর ও সময়রেখা ঠিক করলে ঠিক যত টুল দরকার, তার বেশি বা কম নয়।
৯.১. 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 সংস্করণ ও প্রদর্শন ভাষায় কলাম নাম কিছুটা আলাদা, তাই কলামের অর্থ নিশ্চিত করে তারপর রেকর্ড করুন।
৯.২. 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-এর সাথে মিলে।141516
একাধিক ইনস্ট্যান্স থাকা অ্যাপে নাম নয়, PID দিয়ে তাড়া করুন। দীর্ঘ নজরদারিতে পুনরারম্ভে PID বদলালে শুরুর সময়, সার্ভিস নাম ইত্যাদি রেকর্ড করুন যাতে লক্ষ্য ভুল না হয়।
৯.৩. 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 * দিয়ে স্থানীয় নাম দেখুন।
৯.৪. VMMap ও RAMMap-এর ভূমিকা গুলিয়ে ফেলবেন না
- VMMap: এক প্রক্রিয়ার ভার্চুয়াল মেমরি ও Working Set Heap, Image, Mapped File, Private Data, Managed Heap ইত্যাদিতে ভাঙে
- RAMMap: পুরো সিস্টেমের ফিজিক্যাল RAM উদ্দেশ্য, পেজ তালিকা, প্রক্রিয়া ও ফাইলে ভাঙে
“এই প্রক্রিয়ার Private Bytes কীতে বেড়েছে” VMMap-এর কাজ; “প্রক্রিয়া তালিকা যে RAM ব্যাখ্যা করে না তা কীতে ব্যবহৃত” RAMMap-এর।1713
১০. সংখ্যার মিলিয়ে লক্ষণ পড়া
| দেখা আকৃতি | প্রথম অনুমান | পরে যা দেখবেন |
|---|---|---|
| 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-এর কাছে | সিস্টেম-ব্যাপী কমিট চাপ | শীর্ষ Private Bytes ভোক্তা, Paged/Nonpaged Pool, পেজ ফাইল সেটিং |
| Available কম, Pages Input/sec ও ডিস্ক লেটেন্সি উঁচু | ফিজিক্যাল RAM চাপ ও হার্ড পেজিং | শীর্ষ Working Set ভোক্তা, RAMMap, ওয়ার্কলোড সম্পর্ক |
| RAM ব্যবহার উঁচু কিন্তু বড় প্রক্রিয়া নেই | ক্যাশ, শেয়ার্ড পেজ, কার্নেল পুল, ড্রাইভার, কম্প্রেশন ইত্যাদি | RAMMap, Pool Nonpaged/Paged Bytes |
| খালি RAM আছে, তবু শুধু ৩২-বিট অ্যাপ ব্যর্থ | ভার্চুয়াল অ্যাড্রেস স্পেস সিলিং বা খণ্ডন | VMMap-এর Free/Reserved, এক্সিকিউটেবলের LAA সেটিং |
| Private Bytes উঁচু কিন্তু পুনরাবৃত্ত প্রক্রিয়াকরণে বাড়ে না | সম্ভবত উঁচু ওয়াটারমার্ক ধরে রাখা পুল বা ক্যাশ | তার সীমা, পুনর্ব্যবহার আচরণ, পিকের পর স্থিরতা |
এই সারণির সবচেয়ে জরুরি কথা: একক মান নয়, মিলিয়ে পড়ুন।
১১. মেমরি লিক তদন্তের ব্যবহারিক পদ্ধতি
১১.১. আগে পুনরুৎপাদন শর্ত ও স্থির বিন্দু ঠিক করুন
“কয়েক দিনে বাড়ে” একা তুলনা হয় না।
- শুরুর পর ওয়ার্ম-আপ কতটা ধরবেন
- এক চক্রের অপারেশনে কী
- এক চক্রের পর কত সেকেন্ড অপেক্ষা
- ক্যাশ সিলিংয়ে পৌঁছাতে কত চক্র
- সুস্থ ও সমস্যাযুক্ত বিল্ডে একই ইনপুট ব্যবহার করা যায় কি না
সব ঠিক করুন।
১১.২. প্রক্রিয়া ও সিস্টেম একসাথে রেকর্ড করুন
অন্তত এগুলো একই সময়চিহ্নে লগ রাখুন।
- লক্ষ্যের Working Set
- লক্ষ্যের Private Bytes
- লক্ষ্যের Virtual Bytes
- সিস্টেমের Committed Bytes / Commit Limit
- Available MBytes
- Pages Input/sec
- হ্যান্ডেল সংখ্যা, থ্রেড সংখ্যা
- অপারেশন বা প্রক্রিয়াকৃত আইটেম সংখ্যা
প্রক্রিয়ার Private Bytes স্থির অথচ সিস্টেম Commit বাড়তে থাকলে অন্য প্রক্রিয়া, কার্নেল, ড্রাইভার ও শেয়ার্ড সেকশন পর্যন্ত পরিসর বাড়াতে হবে।
১১.৩. আগে ঠিক করুন কোন “মাত্রা” বাড়ছে
- শুধু Working Set: নিবাসী পেজ, শেয়ার্ড বা ফাইল-জাত, Trim ও পুনরায় লোড
- Private Bytes: প্রক্রিয়া-নিজস্ব কমিট
- শুধু Virtual Bytes: Reserve, ম্যাপিং, অ্যাড্রেস স্পেস খণ্ডন
- শুধু System Commit: অন্য প্রক্রিয়া ও কার্নেল পাশসহ
- Nonpaged Pool: ড্রাইভার/কার্নেল পাশ
- Handles / GDI / USER: মেমরি ছাড়া সম্পদ লিক
এই ক্রম বাদ দিয়ে সোজা ডাম্প নিলে ভুল লক্ষ্যে তথ্যের পাহাড় পড়তে হয়।
১১.৪. ভাঙনে এগোবেন
- নেটিভ প্রক্রিয়া: 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 পর্যন্ত কতটা সরু করা যায় তাতে পরের তদন্ত খরচ বদলায়।17
১১.৫. সংশোধনের পর একই শর্তে ঢাল তুলনা করুন
সংশোধনের আগে-পরে পিক মান আলাদা হওয়া যথেষ্ট নয়। শুরুর মান আলাদা হলে তুলনা সহজে উল্টে যায়।
- একই শুরু অবস্থা
- একই ইনপুট
- একই অপারেশন সংখ্যা
- একই অপেক্ষা সময়
- একই নমুনা অন্তরাল
— আর প্রতি চক্রের পর মেঝে মান ও ঢাল তুলনা করুন। লিক সংশোধনের প্রমাণ “সর্বোচ্চ ছোট হয়েছে” নয়, একই লোড পুনরাবৃত্তি করলেও বৃদ্ধি এখন মিলছে।
১২. সাধারণ ভুলধারণা আবার বলা
ভুলধারণা ১: Task Manager-এর Memory = অ্যাপের মোট বরাদ্দ
আবার বলা: কোন কলাম তা দেখুন। Working Set পরিবার হলে এখন RAM-এ নিবাসী পরিমাণ; Commit Size পরিবার হলে সেই প্রক্রিয়ার নিজস্ব কমিট।
ভুলধারণা ২: Private Bytes = পেজ ফাইলে বাইট
আবার বলা: Private Bytes প্রাইভেট Commit Charge। এটি যুক্তিগত প্রতিশ্রুতি, যাতে এখন RAM-এ পেজ ও দরকারে পেজ ফাইলে ধরা পেজ দুটোই আছে।
ভুলধারণা ৩: Commit X/Y = পেজ ফাইল ব্যবহার / পেজ ফাইল ধারণক্ষমতা
আবার বলা: X সিস্টেম-ব্যাপী Commit Charge, Y Commit Limit। পেজ ফাইল Y বাড়ায়, কিন্তু X সরাসরি ডিস্ক ব্যবহার হয় না।
ভুলধারণা ৪: উচ্চ Page Faults/sec = ডিস্কে সোয়াপ হচ্ছে
আবার বলা: এতে সফট ফল্টও আছে। ডিস্ক I/O সত্যি জড়িত কি না Pages Input/sec, Page Reads/sec ও ডিস্ক লেটেন্সি দিয়ে দেখুন।
ভুলধারণা ৫: কম Free RAM = মেমরি কম
আবার বলা: Available, Standby, হার্ড পেজিং ও সাড়া সময় দেখুন। পুনর্ব্যবহারযোগ্য ক্যাশে RAM ভরা স্বাভাবিক।
ভুলধারণা ৬: Working Set ছোট করা = মেমরি লিক সেরেছে
আবার বলা: শুধু পেজ RAM থেকে সরানো হতে পারে। Private Bytes ও হিপের ভেতর ধারণ সত্যি কমেছে কি না দেখুন।
ভুলধারণা ৭: Private Bytes বাড়া = লিক নিশ্চিত
আবার বলা: একই ওয়ার্কলোড পুনরাবৃত্তিতে মিলে কি না, কোন ধরনের মেমরি বেড়েছে, আর মুক্তযোগ্য ক্যাশ কি না — তা দেখেই বিচার সম্ভব।
১৩. সারসংক্ষেপ
- Windows-এর “মেমরি ব্যবহার” এক সংখ্যা নয়। অ্যাড্রেস স্পেস, কমিট, 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?
শুধু এই প্রশ্ন তদন্তের প্রবেশ অনেক সঠিক করে।
সম্পর্কিত নিবন্ধ
- .NET-এ GC বিলম্ব ও মেমরি লিক আলাদা করা — বাড়তি মেমরি পর্যবেক্ষণ, তুলনা ও প্রমাণের ব্যবহারিক পদ্ধতি
- Process Explorer / Handle / VMMap ব্যবহারিকভাবে — হ্যাং, লিক ও “ফাইল ব্যবহৃত” এখনকার স্টেট থেকে তাড়া
- শেয়ার্ড মেমরির ফাঁদ ও ব্যবহারিক সেরা অনুশীলন
- Windows I/O-এর গভীরতা（পর্ব ৪）— Cache Manager: আপনার WriteFile আসলে ডিস্কে কখন পৌঁছায়?
- শিল্প ক্যামেরা অ্যাপের দীর্ঘ-চক্র ক্র্যাশ তদন্ত - হ্যান্ডেল লিক (পর্ব ১)
সম্পর্কিত পরামর্শ ক্ষেত্র
KomuraSoft LLC Windows অ্যাপ মেমরি বৃদ্ধি, দীর্ঘ চলার পর পারফরম্যান্স পতন, ৩২-বিট প্রক্রিয়ায় OutOfMemory, আর শুধু গ্রাহক পরিবেশে ঘটে এমন মেমরি ঘাটতির জন্য PerfMon, VMMap, RAMMap, WinDbg ও .NET নির্ণয় টুল মিলিয়ে মূল কারণ তদন্ত সামলায়। আমরা শুধু “মেমরি বেশি”তে থামি না — কোন অঞ্চল, কোন অপারেশনে, কেন বেড়েছে, আর কোথা থেকে রেফারেন্স বা ধারণ হচ্ছে তা আলাদা করি।
তথ্যসূত্র
-
Microsoft Learn, Working Set। প্রক্রিয়ার Working Set এখন ফিজিক্যাল মেমরিতে নিবাসী পেজের সেট, শেয়ার্ড পেজসহ; সফট ও হার্ড পেজ ফল্টের পার্থক্য; Transition পেজ; এবং Working Set থেকে পেজ সরানো সম্পর্কে। ↩ ↩2 ↩3 ↩4 ↩5
-
Microsoft Learn, PROCESS_MEMORY_COUNTERS_EX2 structure। WorkingSetSize, PrivateWorkingSetSize, PrivateUsage ও SharedCommitUsage-এর সংজ্ঞা, এবং PagefileUsage ও PrivateUsage দুটোই প্রক্রিয়ার Commit Charge দেখানো সম্পর্কে। ↩ ↩2 ↩3 ↩4
-
Microsoft Learn, Introduction to page files। পেজ ফাইল পরিবর্তিত পেজ সরানো, সিস্টেম ক্র্যাশ ডাম্প ও System Commit Limit সম্প্রসারণ ধরে; System Commit Charge ও Commit Limit-এর সংজ্ঞা; এবং Task Manager ও পারফরম্যান্স কাউন্টারে মাপ সম্পর্কে। ↩ ↩2 ↩3 ↩4
-
Microsoft Learn, Page State। ভার্চুয়াল পেজের Free, Reserved ও Committed অবস্থা, এবং Reserved পেজে ফিজিক্যাল স্টোরেজ না থাকা ও অ্যাক্সেস অযোগ্য হওয়া সম্পর্কে। ↩ ↩2
-
Microsoft Learn, VirtualAlloc function। MEM_RESERVE ও MEM_COMMIT-এর পার্থক্য; কমিট সিস্টেমের সামগ্রিক মেমরি ও পেজ ফাইলে চার্জ হওয়া; এবং আসল ফিজিক্যাল পেজ কখনো প্রথম অ্যাক্সেস পর্যন্ত বরাদ্দ না হওয়া সম্পর্কে। ↩ ↩2 ↩3
-
Microsoft Learn, How to determine the appropriate page file size for 64-bit versions of Windows। পেজ ফাইল আকার পিক Commit Charge ও ক্র্যাশ ডাম্প প্রয়োজনে নির্ভর; হার্ড পেজ ফল্ট শুধু পেজ ফাইল থেকে নয় EXE, DLL ও মেমরি-ম্যাপড ফাইল থেকেও পড়ে; এবং সংশ্লিষ্ট পারফরম্যান্স কাউন্টার সম্পর্কে। ↩ ↩2 ↩3 ↩4 ↩5 ↩6
-
Microsoft Learn, Virtual Address Space। প্রতিটি প্রক্রিয়ার স্বাধীন ভার্চুয়াল অ্যাড্রেস স্পেস ও পেজ টেবিল থাকা, এবং ভার্চুয়াল অ্যাড্রেস নিজে ফিজিক্যাল অ্যাড্রেস না হওয়া সম্পর্কে। ↩
-
Microsoft Learn, Memory Limits for Windows and Windows Server Releases। ৩২-বিট প্রক্রিয়ার ইউজার-মোড ভার্চুয়াল অ্যাড্রেস স্পেস সাধারণত ২GB, আর ৬৪-বিট Windows-এ IMAGE_FILE_LARGE_ADDRESS_AWARE অনুসারে ২GB বা ৪GB হওয়া সম্পর্কে। ↩
-
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 ফিজিক্যাল মেমরি ব্যবহার উদ্দেশ্য, পেজ তালিকা, প্রক্রিয়া, অগ্রাধিকার, ফিজিক্যাল পেজ ও ফাইল অনুসারে বিশ্লেষণ সম্পর্কে। ↩ ↩2
-
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) দেখানো, এবং বিস্তারিত মেমরি মানচিত্র সম্পর্কে। ↩ ↩2
সম্পর্কিত নিবন্ধ
কাছাকাছি বিষয়ে গভীরে যেতে একই ট্যাগযুক্ত সাম্প্রতিক নিবন্ধ।
Windows মেমরির গভীরতা (পর্ব ২) — একটি ভৌত পেজের জীবন: পাঁচটি তালিকা ও পেজ ফাইলের সত্য
এই নিবন্ধ PFN ডেটাবেস, Standby, Modified, মেমরি সংকোচন ও পেজ ফাইল জুড়ে Working Set ছাড়ার পর একটি ভৌত পেজ কোথায় যায় তা ব্যাখ্যা করে।
ঘুম থেকে জাগলে ভাঙে যে অ্যাপ — Windows পাওয়ার ইভেন্টের কাজ ও যে ব্যবসায়িক অ্যাপ তা সহ্য করে
ল্যাপটপ খুললেন আর ব্যবসায়িক অ্যাপের সংযোগ মৃত — কারণ ঘুম ধরে না নেওয়া ডিজাইন। এই নিবন্ধ WM_POWERBROADCAST নোটিফিকেশন প্রবাহ, Modern Sta...
DllMain ও লোডার লক — DLL ইনিশিয়ালাইজেশনে "কিছুই করবেন না" বলা হয় তার আসল কারণ
DllMain থেকে LoadLibrary ডাকা বা অন্য থ্রেডের সাথে সিঙ্ক্রোনাইজ করা যায় না কেন। প্রাথমিক উৎস থেকে এই নিবন্ধ ব্যাখ্যা করে লোডার লক প্রতিট...
"Not Responding" আসলে কী — Windows কীভাবে অ্যাপ হ্যাং ধরে, আর যে ডিজাইন হ্যাং করে না
Windows-এর "Not Responding" এমন যন্ত্র যেখানে OS বিচার করে উইন্ডো ৫ সেকেন্ড মেসেজ তোলেনি আর তাকে ঘোস্ট উইন্ডো দিয়ে বদলায়। এই নিবন্ধ সেই...
WPR/WPA বাস্তবে — "পুরো PC ধীর"-এর সিস্টেম-ব্যাপী পারফরম্যান্স অনুসন্ধানের ভূমিকা
Task Manager যে "পুরো PC ধীর" বা "স্টার্টআপ ধীর" পারফরম্যান্স সমস্যা ধরতে পারে না, WPR/WPA দিয়ে OS-ব্যাপী ETW ট্রেস ধরে পড়ে অনুসন্ধান ক...
সম্পর্কিত বিষয়
এই পৃষ্ঠাগুলো বিষয়টিকে সেবা ও সিদ্ধান্তের বৃহত্তর প্রেক্ষাপটে স্থাপন করে।
Windows-এর প্রযুক্তিগত বিষয়
Windows ডেভেলপমেন্ট, বাগ তদন্ত ও বিদ্যমান সম্পদ ব্যবহারের প্রবেশদ্বার।
এই বিষয়ের সাথে সম্পর্কিত সেবা
নিবন্ধটি নিচের সেবাগুলোর সাথে সরাসরি সম্পর্কিত।
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" কি মানে ১৮GB পেজ ফাইলে লেখা হয়েছে?
- না। বাঁদিকের সংখ্যা পুরো সিস্টেম এখন যে কমিট প্রতিশ্রুতি দিচ্ছে তার মোট; ডানদিক সিস্টেম যে কমিট সিলিং ধরতে পারে। সিলিং মোটামুটি RAM প্লাস পেজ ফাইলে নির্ধারিত, কিন্তু বাঁদিকের সবটা পেজ ফাইলে বসে নেই। অধিকাংশ কমিটেড পেজ RAM-এ, আর কিছু কমিটেড পেজে এখনো ফিজিক্যাল পেজই দেওয়া হয়নি। অন্যদিকে EXE, DLL ও মেমরি-ম্যাপড ফাইলের মতো মূল ফাইল থেকে আবার পড়া যায় এমন পেজ Working Set যত বাড়ায় Private Commit তত বাড়ায় না।
- খালি RAM থাকলেও OutOfMemory হতে পারে?
- হ্যাঁ। ফিজিক্যাল RAM ছাড়াও অ্যালোকেশন ব্যর্থ হতে পারে — ৩২-বিট প্রক্রিয়ার ভার্চুয়াল অ্যাড্রেস স্পেস শেষ, প্রয়োজনীয় আকারের ধারাবাহিক খালি অ্যাড্রেস রেঞ্জের অভাব, সিস্টেম কমিট সিলিং, বা Job Object ও রানটাইমের নিজস্ব সীমা। বিশেষ করে ৬৪-বিট Windows-এ ৩২-বিট প্রক্রিয়া সাধারণত ২GB ইউজার-মোড ভার্চুয়াল অ্যাড্রেস স্পেসে সীমাবদ্ধ, Large Address Aware না হলে।
- পেজ ফাইল বন্ধ করলে Windows কি দ্রুত হয়?
- সাধারণ নিয়ম হিসেবে ধরা যায় না। পেজ ফাইল বন্ধ করলে সিস্টেমের কমিট সিলিং নামে, অব্যবহৃত পরিবর্তিত পেজ RAM থেকে সরানো কঠিন হয়, আর ক্র্যাশ ডাম্প কনফিগারেশনেও প্রভাব পড়ে। পেজ ফাইলের আকার পিক কমিট চার্জ ও প্রয়োজনীয় ক্র্যাশ ডাম্প মেপে ঠিক করা উচিত — ভিত্তি ছাড়া বন্ধ করার সেটিং নয়।
- উচ্চ Page Faults/sec কি মানে সিস্টেমে মেমরি কম?
- শুধু তাতে বলা যায় না। পেজ ফল্টে সফট ফল্ট আছে, যা RAM-এর Standby পেজ বা অন্য প্রক্রিয়ার সাথে ভাগ করা পেজ থেকে সমাধান হয়, আর হার্ড ফল্ট, যা ডিস্ক থেকে পড়ে। Page Faults/sec একা না দেখে Pages Input/sec, Page Reads/sec, Available MBytes, ডিস্ক লেটেন্সি ও প্রক্রিয়াকরণ সময় একই সময়রেখায় একসাথে দেখুন।