সংক্ষিপ্ত উত্তর
"মেমরির বাইরে" পপ-আপ বলছে যে আপনি ব্যক্তিগত প্রতিশ্রুতিবদ্ধ মেমরির সীমা ছাড়িয়ে চলেছেন — এক ধরণের ভার্চুয়াল মেমরি। এমন নয় যে আপনি র্যামের (শারীরিক মেমরি) শেষ করছেন। আপনার কতটা র্যাম পাওয়া যায় তা বিবেচ্য নয়। প্রচুর উপলভ্য র্যাম থাকা আপনাকে কমিটের সীমা অতিক্রম করতে দেয় না। প্রতিশ্রুতিবদ্ধ সীমাটি আপনার মোট র্যামের যোগ (যা ব্যবহারে থাকুক বা না থাকুক!) এর সাথে আপনার বর্তমান পৃষ্ঠাফাইল আকারের যোগফল।
বিপরীতে, কি "আপ আপ" প্রতিশ্রুতি সীমা (যা বেশিরভাগ প্রক্রিয়া-বেসরকারী ভার্চুয়াল ঠিকানা স্থান তৈরি) অগত্যা কোনও র্যাম ব্যবহার করে না! তবে ওএসগুলি এটি তৈরির অনুমতি দেয় না যতক্ষণ না এটি জানে যে এটির প্রয়োজন হলে এটি সংরক্ষণ করার কোনও জায়গা রয়েছে। সুতরাং আপনি আপনার সমস্ত র্যাম, এমনকি আপনার বেশিরভাগ র্যাম ব্যবহার না করেই প্রতিশ্রুতি সীমাতে চলে যেতে পারেন।
এজন্য আপনার কোনও পেজ ফাইল ছাড়া চালানো উচিত নয়। নোট করুন যে পেজফাইলে আসলে লিখিত হতে পারে না! তবে এটি আপনাকে "স্মৃতিশক্তি কম" এবং "মেমরির বাইরে" ত্রুটিগুলি এড়াতে দেয়।
মধ্যবর্তী উত্তর
উইন্ডোজ র্যামের বাইরে চলে যাওয়ার জন্য আসলে ত্রুটির বার্তা নেই। আপনি যা করছেন তা হ'ল "প্রতিশ্রুতিবদ্ধ সীমা"।
প্রসেস এক্সপ্লোরারের সেই সংস্করণে "সিস্টেম" গ্রাফটির নাম খারাপ নেই। এটি "কমিট চার্জ" লেবেলযুক্ত হওয়া উচিত। (সংস্করণে আমি এটি "সিস্টেম কমিট" বলেছি Bet আরও ভাল, তবে এখনও সম্পূর্ণরূপে সামঞ্জস্যপূর্ণ নয় case) কোনও ক্ষেত্রে গ্রাফের "বর্তমান" উচ্চতাটি "কমিট চার্জ" হিসাবে পাঠ্য বিভাগে নীচে দেখায় - " বর্তমান ", এবং গ্রাফের সর্বাধিক উচ্চতা" কমিট চার্জ "-" সীমাবদ্ধতা "উপস্থাপন করে।
"কমিট চার্জ" বলতে ভার্চুয়াল অ্যাড্রেস স্পেসকে বোঝায় যা পেজফাইলে সমর্থিত (যদি আপনার একটি থাকে) - অন্য কথায়, যদি এটি সমস্ত র্যামে ফিট করে না, বাকী বাকী পৃষ্ঠাফাইলে যায়। (অন্যান্য ধরণের ভ্যাস রয়েছে যা অন্য ফাইলগুলির দ্বারা সমর্থিত হয় - যাকে "ম্যাপযুক্ত" ভাস বলা হয় - বা যা সারাক্ষণ র্যামে থাকতে হবে; পরবর্তীটিকে "ননপেজেবল" বলা হয়)) "কমিট সীমা" সর্বাধিক "কমিট চার্জ" হতে পারে। এটি আপনার র্যাম আকারের সাথে পৃষ্ঠাগুলির আকারের সমান।
আপনার কাছে দৃশ্যত কোনও পেজফাইল নেই (আমি বলতে পারি কারণ আপনার প্রতিশ্রুতি সীমা আপনার র্যামের আকারের সমান), সুতরাং কমিট সীমাটি কেবল র্যাম আকার।
স্পষ্টতই বিভিন্ন প্রোগ্রাম + ওএস সর্বাধিক সম্ভাব্য কমিটের প্রায় সমস্ত ব্যবহার করেছে।
এটি কতটা র্যাম নিখরচায় বা উপলভ্য তা সরাসরি করার কিছুই নেই। হ্যাঁ, আপনার কাছে প্রায় 4.5 গিগাবাইট র্যাম পাওয়া যায়। এর অর্থ এই নয় যে আপনি কমিটের সীমা অতিক্রম করতে পারবেন। প্রতিশ্রুতিবদ্ধ মেমরি অগত্যা র্যাম ব্যবহার করে না এবং উপলব্ধ র্যামের পরিমাণের দ্বারা সীমাবদ্ধ নয়।
আপনাকে এই পৃষ্ঠায় ফাইলটি পুনরায় সক্ষম করতে হবে - এটি অনেক প্রতিশ্রুতিবদ্ধ ব্যবহার করে আমি একটি 16 গিগাবাইটের পেজফাইলে পরামর্শ দেব, কারণ আপনি ওএসকে এতটা জিনিস র্যামে রাখতে বাধ্য করতে চান না, এবং পেজ ফাইলটি যদি এটি কার্যকর হয় তবে প্রচুর ফ্রি রুম রয়েছে - অন্যথায় আরও র্যাম যুক্ত করুন। আরো বেশি. ভাল পারফরম্যান্সের জন্য আপনার কোড ও অন্যান্য স্টাফের জন্য র্যামের প্রচুর জায়গা থাকতে হবে যা পেজফাইলে ব্যাকড হয় না (তবে অন্য ফাইলগুলিতে পেজড করা যেতে পারে)।
খুব দীর্ঘ উত্তর
(তবে উইন্ডোজ ইন্টারনালের মেমরি ম্যানেজমেন্ট অধ্যায়ের চেয়ে এখনও অনেক কম ...)
মনে করুন কোনও প্রোগ্রাম 100 এমবি প্রসেস-বেসরকারী ভার্চুয়াল মেমরির বরাদ্দ করে। এটি "কমিট" বিকল্পের সাথে ভার্চুয়ালআলোক কল দিয়ে সম্পন্ন হয়। এটি "কমিট চার্জ" -তে 100 এমবি বৃদ্ধি পাবে। কিন্তু এই "বরাদ্দ" আসলে কোনও র্যাম ব্যবহার করে না! র্যাম কেবল তখনই ব্যবহৃত হয় যখন সেই নতুন-প্রতিশ্রুতিবদ্ধ ভার্চুয়াল ঠিকানা স্থানের মধ্যে প্রথমবারের জন্য অ্যাক্সেস করা হয়।
র্যাম শেষ পর্যন্ত কীভাবে ব্যবহার হয়
(যদি এটি কখনও হয়)
নতুন প্রতিশ্রুতিবদ্ধ স্থানটিতে প্রথমবারের অ্যাক্সেসটি প্রায় সর্বদা একটি মেমরি রাইটিং হবে (এটি লেখার আগে সদ্য বরাদ্দকৃত বেসরকারী ভাস পড়া প্রায় সর্বদা একটি প্রোগ্রামিং ত্রুটি, কারণ এর প্রাথমিক বিষয়বস্তুগুলি কঠোরভাবে বলা, অপরিজ্ঞাত)। তবে পড়ুন বা লিখুন, ফলস্বরূপ, আপনি নতুন বরাদ্দ করা ভাসের কোনও পৃষ্ঠায় প্রথমবার স্পর্শ করবেন, এটি একটি পৃষ্ঠা ত্রুটি । যদিও "দোষ" শব্দটি খারাপ শোনাচ্ছে তবে পৃষ্ঠার ত্রুটিগুলি ভার্চুয়াল মেমরি ওএসে সম্পূর্ণ প্রত্যাশিত এবং এমনকি প্রয়োজনীয় ইভেন্ট।
এই নির্দিষ্ট ধরণের পৃষ্ঠার ত্রুটির প্রতিক্রিয়া হিসাবে পেজার (ওএসের মেমরির ম্যানেজারের অংশ, যা আমি মাঝে মাঝে সংক্ষেপে করব "" এমএম "হিসাবে):
- র্যামের একটি শারীরিক পৃষ্ঠা বরাদ্দ করুন (আদর্শভাবে শূন্য পৃষ্ঠার তালিকা থেকে, তবে যে কোনও ক্ষেত্রে, এটি উইন্ডোজ যা বলে "উপলব্ধ" বলে তা থেকে আসে: শূন্য, নিখরচায় বা স্ট্যান্ডবাই পৃষ্ঠার তালিকাকে, পছন্দ অনুসারে);
- ভার্চুয়াল পৃষ্ঠার সাথে ফিজিকাল পৃষ্ঠা সংযুক্ত করতে একটি পৃষ্ঠার টেবিল এন্ট্রি পূরণ করুন ; এবং পরিশেষে
- পৃষ্ঠা ফল্ট ব্যতিক্রম বরখাস্ত করুন।
যার পরে মেমোরি রেফারেন্সটি দেওয়া কোডটি সেই পৃষ্ঠাটি ত্রুটি উত্থাপনকারী নির্দেশকে পুনরায় কার্যকর করবে এবং এই বারটি উল্লেখটি সফল হবে will
আমরা বলি যে পৃষ্ঠাটি প্রক্রিয়া কার্যকারী সেট এবং "র্যাম" এ "ফল্ট" হয়েছে। টাস্ক ম্যানেজারে এটি প্রক্রিয়াটির "ব্যক্তিগত কাজের সেট" এর এক পৃষ্ঠার (4 কেবি) বৃদ্ধি হিসাবে উপস্থিত হবে। এবং উপলব্ধ শারীরিক স্মৃতিতে এক পৃষ্ঠার হ্রাস। (কোনও ব্যস্ত মেশিনে পরবর্তীটি লক্ষ্য করা শক্ত হতে পারে))
দ্রষ্টব্য 1: এই পৃষ্ঠার ত্রুটিটি ডিস্ক থেকে পড়া কিছু জড়িত না। প্রতিশ্রুতিবদ্ধ ভার্চুয়াল মেমরির আগে কখনও অ্যাক্সেস করা পৃষ্ঠা ডিস্কে জীবন শুরু করে না; এটা ডিস্কে কোন জায়গা এটা পড়তে হয়েছে থেকে । এটি র্যামের পূর্বের উপলব্ধ পাতায় কেবল "উপাদানযুক্ত"। পরিসংখ্যানগতভাবে, প্রকৃতপক্ষে, বেশিরভাগ পৃষ্ঠার ত্রুটিগুলি র্যামে সমাধান করা হয়, অন্য প্রসেসগুলির জন্য ইতিমধ্যে র্যামে থাকা ভাগ করা পৃষ্ঠাগুলিতে, বা পৃষ্ঠাগুলি ক্যাশে - স্ট্যান্ডবাই বা পরিবর্তিত তালিকাগুলিতে বা এই জাতীয় "শূন্যের চাহিদা" পৃষ্ঠাগুলি হিসাবে।
দ্রষ্টব্য 2: এটি "উপলভ্য" থেকে 4096 বাইট মাত্র একটি পৃষ্ঠা নেয়। কখনও স্পর্শ-পূর্বে প্রতিশ্রুতিবদ্ধ ঠিকানার স্থানটি সাধারণত একবারে কেবলমাত্র একটি পৃষ্ঠায় ভুলভাবে চিহ্নিত করা যায়, কারণ প্রতিটি পৃষ্ঠা প্রথমবারের জন্য "ছোঁয়া" থাকে। একসাথে আরও কিছু করার ক্ষেত্রে কোনও উন্নতি, কোনও সুবিধা হবে না; এটি ঠিক সময় হিসাবে n সময় নিতে হবে। বিপরীতে, পৃষ্ঠাগুলি যখন ডিস্ক থেকে পড়তে হয় তখন কিছু পরিমাণ "রিডহেড" চেষ্টা করা হয় কারণ ডিস্কে পঠন করার সময় বেশিরভাগ সময়ই অপারেশন ওভারহেডে থাকে, প্রকৃত ডেটা স্থানান্তর নয়। "প্রতিশ্রুতিবদ্ধ" পরিমাণটি 100 এমবিতে থাকে; এক বা পৃষ্ঠাগুলি ত্রুটিযুক্ত হয়েছে বলে প্রতিশ্রুতি চার্জ হ্রাস হয় না।
নোট 3:ধরা যাক আমাদের 4 জিবি "উপলব্ধ" র্যাম রয়েছে। এর অর্থ হ'ল আমরা র্যামের বাইরে চলে আসার আগেই আমরা ইতিমধ্যে বরাদ্দকৃত তবে কখনও-আগে-রেফারেন্সযুক্ত প্রতিশ্রুতিবদ্ধ মেমরিটি প্রায় দশ মিলিয়ন বার (4 গিগাবাইট / 4096) এর আগে উল্লেখ করতে পারি। কোন মুহুর্তে, যদি ডেভিড কাটলার এবং ল পেরেজোলির উদ্দেশ্যে আমাদের একটি পৃষ্ঠাফিল থাকে তবে র্যামের দীর্ঘতম-পূর্বনির্দিষ্ট কিছু পৃষ্ঠাগুলি ডিস্কে সংরক্ষণ করা হবে এবং এরপরে সাম্প্রতিক পৃষ্ঠাগুলির ত্রুটিগুলি সমাধানে ব্যবহারের জন্য উপলব্ধ করা হবে। (আসলে ওএস তার আগে "ওয়ার্কিং সেট ট্রিমিং" এর মতো র্যাম পুনরুদ্ধার পদ্ধতি শুরু করবে এবং পেজফাইলে প্রকৃত লেখাগুলি দক্ষতার জন্য পরিবর্তিত পৃষ্ঠার তালিকায় ক্যাশেড এবং ব্যাচ করা হবে এবং ...) এর কোনওটিই এতে প্রভাব ফেলবে না "প্রতিশ্রুতিবদ্ধ" গণনা। এটি "প্রতিশ্রুতিবদ্ধ সীমা" এর সাথে প্রাসঙ্গিক। যদি সবার জন্য জায়গা না থাকে "
এবং এটি ঘটতে থাকে ...
তবে ধরা যাক আমরা আরও মিলিয়ন রেফারেন্সগুলি করিনি এবং এখনও প্রায় 4 জিবি মূল্যের পৃষ্ঠাগুলি "উপলভ্য" রয়েছে " এখন ধরা যাক একই প্রক্রিয়া - বা অন্য কোনও বিষয় নয় - অন্য ভার্চুয়ালআলোক, 200 এমবি বলার এই সময়টি করে। আবার এই 200 এমবি কমিট চার্জে যুক্ত হয় এবং এটি কোনও র্যাম উপলব্ধ থেকে সরিয়ে দেয় না। কেবল ভার্চুয়ালআলোক'এল অ্যাড্রেস স্পেসটি একই পরিমাণে র্যাম ব্যবহার করে না, এবং কম "উপলব্ধ" র্যাম থাকা আপনি ভার্চুয়ালআলোক করতে পারেন এমন ঠিকানার জায়গার পরিমাণ সীমাবদ্ধ করে না (তত বেশি পরিমাণে র্যাম থাকার কারণে এটি বাড়ায় না)।
(ঠিক আছে, ঠিক আছে ... ওভারহেডের একটি ছোট্ট বিট রয়েছে, যা প্রতিটি 2 এমবি (4 মেগাবাইটের জন্য একটি পৃষ্ঠার টেবিলের জন্য ব্যবহার করা হয় (4 এমবি যদি আপনি একটি এক্স -86, নন-পিএই সিস্টেমের হন)) পৃষ্ঠার পরিমাণ থাকে ভার্চুয়াল অ্যাড্রেস স্পেস বরাদ্দ করা হয়েছে, এবং প্রতিটি কার্যত সংগত বরাদ্দকৃত পরিসরের জন্য কয়েক দশ বাইটের একটি "ভার্চুয়াল ঠিকানা বর্ণনাকারী" রয়েছে))
এইভাবে এটি সম্ভব - এবং সাধারণ! - কেবলমাত্র অল্প পরিমাণে র্যাম ব্যবহার করার সময় প্রচুর "কমিট চার্জ" ব্যবহার করতে।
সুতরাং, যদি "প্রতিশ্রুতিবদ্ধ" ভার্চুয়াল ঠিকানার স্থানটি র্যাম ব্যবহার না করে তবে সেখানে কেন একটি সীমা থাকবে?
কারণ "কমিট চার্জ" স্টোরেজ স্পেসের সম্ভাব্য ভবিষ্যতের ব্যবহারের প্রতিনিধিত্ব করে । "প্রতিশ্রুতি সীমা" এই জাতীয় বরাদ্দগুলি ধারণের জন্য উপলব্ধ মোট স্টোরেজ (র্যাম + পৃষ্ঠাফাইল স্থান) প্রতিনিধিত্ব করে, যদি সেগুলিকে প্রকৃতপক্ষে রেফারেন্স করা হয় এবং সেখান থেকে কোনও জায়গায় সংরক্ষণ করা দরকার।
যখন এমএম একটি ভার্চুয়ালআলোক অনুরোধ অনুমোদন করে, তখন এটি প্রতিশ্রুতিবদ্ধ হয় - "প্রতিশ্রুতিবদ্ধ" - যে বরাদ্দকৃত অঞ্চলে পরবর্তী সমস্ত মেমরির প্রবেশাধিকার সফল হবে; তারা পৃষ্ঠার ত্রুটিগুলির ফলস্বরূপ হতে পারে তবে ত্রুটিগুলি সমস্ত সমাধান করা সম্ভব হবে, কারণ র্যামে বা পেজফাইলে সে সমস্ত পৃষ্ঠাগুলির বিষয়বস্তু রাখার পর্যাপ্ত সঞ্চয়স্থান রয়েছে। এমএম এটি জানেন কারণ এটি জানেন যে সেখানে কতগুলি সঞ্চয় স্থান রয়েছে (কমিট সীমা) এবং ইতিমধ্যে "প্রতিশ্রুতিবদ্ধ" (বর্তমান প্রতিশ্রুতি চার্জ) কত ছিল।
(তবে pages সমস্ত পৃষ্ঠাগুলির অগত্যা অ্যাক্সেস করা যায়নি, সুতরাং কোনও নির্দিষ্ট সময়ে প্রতিশ্রুতিবদ্ধ পরিমাণের সাথে যাওয়ার কোনও অস্তিত্বের প্রয়োজন নেই))
সুতরাং ... "সিস্টেমের স্মৃতিশক্তি বাইরে" কী?
যদি আপনি ভার্চুয়ালআলোক এবং বর্তমান কমিট চার্জ প্লাস অনুরোধকৃত বরাদ্দের আকারের চেষ্টা করেন তবে আপনাকে কমিটের সীমা ছাড়িয়ে যাবে এবং কমিটের সীমা বাড়ানোর জন্য ওএস পেজফাইলে প্রসারিত করতে পারে না ... আপনি "স্মৃতি থেকে সরিয়ে" পপ- আপ হয় এবং প্রক্রিয়াটি ভার্চুয়ালআলোক কলকে ব্যর্থ দেখায়। বেশিরভাগ প্রোগ্রামগুলি কেবল তাদের হাত উপরে ফেলে মরে যাবে point কেউ কেউ অন্ধভাবে চাপ দিয়ে ধরে ধরে নিবে যে কলটি সফল হয়েছে এবং পরে তারা যখন এই অঞ্চলটিকে তারা বরাদ্দ করেছে বলে উল্লেখ করার চেষ্টা করবে তখন ব্যর্থ হবে।
আবার (পুনরাবৃত্তির জন্য দুঃখিত): আপনার কতটা র্যাম পাওয়া যায় তা বিবেচনাধীন নয়। অপারেটিং সিস্টেম প্রতিজ্ঞা করেছেন যে র্যাম বা পৃষ্ঠাফাইল স্থান হবে প্রাপ্তিসাধ্য যখন এটি এর প্রয়োজন হতে পারে, কিন্তু যে প্রতিশ্রুতি "উপলভ্য" থেকে বিয়োগ করে না। উপলভ্য র্যাম কেবলমাত্র প্রতিশ্রুতিবদ্ধ ভিএম দ্বারা ব্যবহৃত হয় যখন এটি প্রথমবারের জন্য উল্লেখ করা হয়, যার কারণে এটি "ফল্ট ইন" হয়ে যায় ... অর্থাৎ শারীরিক স্মৃতিতে উপলব্ধি ঘটেছে। এবং কেবল ভার্চুয়াল মেমরি (= বরাদ্দ) প্রতিশ্রুতিবদ্ধ করা এটি করে না। এটি কেবল নিখরচায় ভার্চুয়াল ঠিকানার স্থান নেয় এবং এর বাইরে ব্যবহারযোগ্য ভার্চুয়াল ঠিকানার স্থান করে তোলে।
তবে "মেমরি অফ আউট" ক্ষেত্রে প্রতিশ্রুতিবদ্ধ মেমরির জন্য বরাদ্দের অনুরোধ ছিল এবং ওএস এই নতুন অনুরোধের আকারের সাথে বর্তমান কমিট চার্জ যুক্ত করেছে ... এবং দেখা গেছে যে মোট কমিট কমিটের সীমা ছাড়িয়ে বেশি । সুতরাং ওএস যদি এই নতুনটিকে অনুমোদন করে এবং তার পরে সেই সমস্ত স্থানটি রেফারেন্স করা হয়, তবে সবগুলি সংরক্ষণ করার জন্য কোনও আসল জায়গা (র্যাম + পৃষ্ঠাফাইলে) থাকবে না।
ওএস এটি অনুমতি দেয় না। এটি সবচেয়ে খারাপ অবস্থাতে রাখার জায়গা থাকার চেয়ে এটি আরও বেশি ভ্যাস বরাদ্দ করতে দেয় না - এমনকি যদি এটির সমস্ত "ফল্ট" হয়। এটিই "কমিট সীমাবদ্ধতার" উদ্দেশ্য।
আমি আপনাকে তিনবার বলি তিনবার আমি আপনাকে তিনবার বলি: "উপলভ্য" র্যামের পরিমাণ কিছু যায় আসে না। প্রতিশ্রুতিবদ্ধ ভার্চুয়াল স্পেসটি আসলে এখনও সমস্ত স্টোরেজ স্পেস ব্যবহার করছে না, তাতে কিছু আসে যায় না। উইন্ডোজ ভার্চুয়াল বরাদ্দের সাথে "প্রতিশ্রুতিবদ্ধ" করতে পারে না যদি না ভবিষ্যতে '' '' সমস্ত ত্রুটিযুক্ত হয়।
নোট করুন "ম্যাপযুক্ত" নামে আরও একটি ধরণের ভ্যাস রয়েছে যা মূলত কোড এবং বৃহত ডেটা ফাইলগুলিতে অ্যাক্সেসের জন্য ব্যবহৃত হয় তবে এটি "কমিট চার্জ" হিসাবে চার্জ করা হয় না এবং "কমিট কমিট" দ্বারা সীমাবদ্ধ হয় না। এটি কারণ এটি নিজস্ব স্টোরেজ অঞ্চল, ফাইলগুলিতে এটি "ম্যাপ করা" রয়েছে with "ম্যাপযুক্ত" ভাসের একমাত্র সীমাবদ্ধতা হ'ল ম্যাপ করা ফাইলগুলির জন্য আপনার কাছে থাকা ডিস্কের জায়গার পরিমাণ এবং এগুলিতে ম্যাপ করার জন্য আপনার প্রক্রিয়াতে বিনামূল্যে ভ্যাসের পরিমাণ।
কিন্তু যখন আমি সিস্টেমটি দেখি, আমি এখনও কমিট সীমাতে নেই?
এটি মূলত একটি পরিমাপ এবং রেকর্ড রাখার সমস্যা। ভার্চুয়ালআলোক কল ইতিমধ্যে চেষ্টা করা হয়েছে এবং ব্যর্থ হওয়ার পরে আপনি সিস্টেমটির দিকে তাকাচ্ছেন।
ধরুন আপনার কাছে প্রতিশ্রুতি সীমা মাত্র 500 এমবি ছিল এবং কিছু প্রোগ্রাম ভার্চুয়ালআলোক 600 এমবি চেষ্টা করেছিল। প্রচেষ্টা ব্যর্থ হয়। তারপরে আপনি সিস্টেমটি দেখুন এবং বলবেন "কী? এখনও 500 এমবি বাকি আছে!" আসলে ততক্ষণে আরও অনেক কিছু বাকি থাকতে পারে, কারণ প্রশ্নে প্রক্রিয়াটি সম্ভবত সেই পর্যায়ে পুরোপুরি চলে গেছে, সুতরাং এর আগে বরাদ্দকৃত সমস্ত প্রতিশ্রুতিবদ্ধ মেমরি প্রকাশ করা হয়েছে।
সমস্যাটি হ'ল আপনি সময়মতো পিছনে ফিরে তাকাতে পারবেন না এবং বরাদ্দ দেওয়ার চেষ্টা করার মুহুর্তে কমিট চার্জটি কী ছিল তা দেখতে পাচ্ছেন না । এবং আপনি জানেন না যে চেষ্টাটি কতটা জায়গার জন্য হয়েছিল। সুতরাং চেষ্টাটি কেন ব্যর্থ হয়েছে বা এটিকে কাজ করার অনুমতি দেওয়ার জন্য আরও কত "প্রতিশ্রুতিবদ্ধ সীমা" দরকার ছিল তা আপনি স্পষ্টভাবে দেখতে পারবেন না।
আমি দেখেছি "সিস্টেমের স্মৃতি কম চলছে "। ওটা কী?
উপরের ক্ষেত্রে যদি ওএস পৃষ্ঠা পৃষ্ঠাটি প্রসারিত করতে পারে (যেমন আপনি এটি ডিফল্ট "সিস্টেম পরিচালিত" সেটিংসে রেখে দেন বা আপনি এটি পরিচালনা করেন তবে আপনি প্রাথমিকের চেয়ে সর্বাধিক বৃহত্তর সেট করেছেন এবং সেখানে যথেষ্ট পরিমাণ ডিস্কের স্থান রয়েছে) এবং এই জাতীয় সম্প্রসারণ ভার্চুয়ালআলোক কল সফল হতে দেয় তারপরে কমিটের সীমাটি বাড়িয়ে দেয় ... তারপরে ... মিমি পৃষ্ঠাফাইলে প্রসারিত করে এবং ভার্চুয়ালআলোক কল সফল হয়।
এবং এটি যখন আপনি দেখেন "সিস্টেমটি স্মৃতিতে কম চলছে"। এটি একটি প্রাথমিক সতর্কতা যে জিনিসগুলি প্রশমন ছাড়াই অব্যাহত থাকলে আপনি খুব শীঘ্রই একটি "স্মৃতি থেকে দূরে" সতর্কতা দেখতে পাবেন। কিছু অ্যাপস বন্ধ করার সময়। আমি আপনার ব্রাউজার উইন্ডো দিয়ে শুরু করব।
এবং আপনি কি মনে করেন যে এটি একটি ভাল জিনিস? পেজফাইলে সম্প্রসারণ মন্দ!
না, তা নয়। দেখুন, ওএস বিদ্যমান ফাইলটিকে সত্যই "প্রসারিত" করে না। এটি কেবল নতুন মাত্রা বরাদ্দ করে। প্রভাবটি অন্য কোনও স্বতন্ত্র ফাইলগুলির মতো। পুরানো পেজফাইলে বিষয়বস্তুগুলি যেখানে রয়েছে সেখানে ঠিক থাকে; তাদের কোনও নতুন জায়গায় বা অন্য কিছুতে অনুলিপি করতে হবে না। যেহেতু বেশিরভাগ পেজফাইলে আইও পেজফাইলে আকারের তুলনায় তুলনামূলকভাবে ছোট অংশে থাকে তাই যে কোনও প্রদত্ত স্থানান্তর সীমানা ছাড়িয়ে যাওয়ার সম্ভাবনা সত্যিই খুব বিরল, তাই খণ্ড খণ্ডিত খুব বেশি ক্ষতিগ্রস্থ হয় না যদি না এটি সত্যিই অতিরিক্ত হয়।
অবশেষে, একবার এক্সটেনশনে "প্রতিশ্রুতিবদ্ধ" স্থান থাকা সমস্ত প্রক্রিয়াগুলি (ওএস শাটডাউনে যদি তাড়াতাড়ি না হয়) বন্ধ হয়ে যায়, এক্সটেন্টগুলি নিঃশব্দে মুক্তি দেওয়া হয় এবং পেজফাইলটি তার আগের আকার এবং বরাদ্দে ফিরে আসবে - যদি এটি আগে সংগত ছিল, এটি আবার তাই।
পেজফাইলে সম্প্রসারণ মঞ্জুরি তাই সম্পূর্ণ নিখরচায় সুরক্ষার নেট হিসাবে কাজ করে: আপনি যদি এটির অনুমতি দেন তবে সিস্টেমটিকে কখনই এর প্রয়োজন হয় না, সিস্টেমটি নিয়মিত পেজফাইলে "প্রসারিত এবং চুক্তি করবে না" যেমনটি প্রায়শই দাবি করা হয়, তাই এটির জন্য কোনও ব্যয় হবে না । এবং যদি আপনার কখনও এটির প্রয়োজন হয়, এটি আপনাকে "ভার্চুয়াল মেমরির বাইরে" ত্রুটিযুক্ত ক্র্যাশ করা অ্যাপগুলি থেকে রক্ষা করবে।
কিন্তু কিন্তু কিন্তু...
আমি কয়েক ডজন ওয়েব সাইটে পড়েছি যে আপনি যদি পৃষ্ঠাফাইলে সম্প্রসারণের অনুমতি দেন তবে উইন্ডোজ ক্রমাগত পেজফাইলে প্রসারিত এবং সংকোচিত হবে এবং আপনি পেজফাইলে টুকরো টুকরো করে দেবেন যতক্ষণ না আপনি এটিকে ডিগ্র্যাগ করেন।
তারা ঠিক ভুল।
যদি আপনি কখনই "মেমরি কম চলছে" (বা পুরানো সংস্করণগুলিতে "ভার্চুয়াল মেমরির উপর কম চলছে") পপ-আপ না দেখেন তবে ওএস কখনও কখনও আপনার পৃষ্ঠাফাইলে প্রসারিত করতে পারেনি।
যদি আপনি সেই পপ-আপটি দেখতে পান তবে তা আপনাকে প্রাথমিক পৃষ্ঠাগুলির আকার খুব ছোট বলে tells (আমি এটিকে সর্বাধিক পর্যবেক্ষিত ব্যবহারের প্রায় 4x এ সেট করতে চাই; অর্থাত্ "% পেজফিল ব্যবহারের শীর্ষস্থান" পারফমন কাউন্টারটি 25% এর নিচে হওয়া উচিত Re কারণ: পেজফাইলে স্থানটি অন্যান্য গাদা মতো পরিচালিত হয় এবং এটি অনেকগুলি মুক্ত স্থানের সাথে সেরা কাজ করে খেলতে।)
তবে কেন তারা শুধু ...
কেউ তর্ক করতে পারে যে ওএসের কেবলমাত্র বরাদ্দটি হওয়া উচিত এবং পৃষ্ঠার ত্রুটিগুলি সমাধান করার জন্য কোনও র্যাম না থাকলে রেফারেন্সগুলি ব্যর্থ হওয়া উচিত । অন্য কথায়, উপরে যেখানে আমরা বর্ণনা করেছি যে প্রারম্ভিক পৃষ্ঠা ত্রুটি কীভাবে কাজ করে, "র্যামের উপলভ্য একটি দৈহিক পৃষ্ঠা বরাদ্দ করুন" (পদক্ষেপ 1) কাজটি করা যায়নি কারণ সেখানে কোনও উপলভ্য ছিল না, এবং কোনও জায়গা নেই what পেজ ছেড়ে কিছু আছে কি কোনও উপলব্ধ করার জন্য?
তারপরে পেজার পেজ ত্রুটি সমাধান করতে অক্ষম হবে। এটি ব্যতিক্রম (পৃষ্ঠা ত্রুটি) ত্রুটিযুক্ত থ্রেডে ফিরে রিপোর্ট করার অনুমতি দিতে হবে, সম্ভবত অন্য কোনও ব্যতিক্রম কোডে পরিবর্তিত হয়েছে।
নকশার দর্শনটি হ'ল ভার্চুয়ালআলোক ঠিকানার পরিবর্তে কোনও ঠিকানার পরিবর্তে শূন্য (প্রযুক্তিগতভাবে একটি এনইউএল পয়েন্টার) ফিরিয়ে দেবে, এবং প্রোগ্রামারটি এটি জানতে ভার্চুয়ালআলোক কলটি ব্যর্থ হতে পারে বলে আশা করা সম্পূর্ণ যুক্তিসঙ্গত। সুতরাং প্রোগ্রামাররা প্রত্যাশা করা হয়েছে যে কেসটি পরীক্ষা করে দেখুন এবং প্রতিক্রিয়াতে যুক্তিসঙ্গত কিছু করুন (যেমন আপনাকে আপনার কাজটি সেই পর্যায়ে বাঁচানোর জন্য একটি সুযোগ দিন এবং তারপরে প্রোগ্রামটি "কৃপণভাবে" শেষ করবেন)। (প্রোগ্রামারস: আপনি ম্যালোক, নতুন ইত্যাদি থেকে কোনও NULL পয়েন্টার রিটার্ন পরীক্ষা করে দেখুন, হ্যাঁ? তাহলে আপনি কেন এখান থেকে আসবেন না?)
তবে প্রোগ্রামারদের এমন আশা করা উচিত নয় যে সাধারণ মেমরি রেফারেন্সটি পছন্দ করে
i = 0; // initialize loop counter
ব্যর্থ হতে পারে - এটি সফলভাবে প্রতিশ্রুতিবদ্ধ ঠিকানা স্থানের অঞ্চলে নয়। (বা সেই বিষয়ে ম্যাপ করা ঠিকানার স্থান।) তবে এটিই ঘটতে পারে যদি "অতিরিক্ত বরাদ্দ বরাদ্দের অনুমতি দিন, মেমরির রেফারেন্সটি ব্যর্থ হোক" দর্শনের অনুসরণ করা হয়েছিল।
দুর্ভাগ্যক্রমে, উপরের কোড লাইনের মতো একটি মেমরি রেফারেন্সের কোনও খারাপ অবস্থা ফিরিয়ে দেওয়ার সুবিধাজনক উপায় নেই! এগুলি কেবল সংযোজন এবং বিয়োগের মতো কাজ করার কথা । ব্যর্থতা হিসাবে যেমন ব্যর্থতা রিপোর্ট করার একমাত্র উপায় হবে। সুতরাং তাদের পরিচালনা করতে প্রোগ্রামারকে পুরো ব্যয়টিকে একটি ব্যতিক্রম হ্যান্ডলারের মধ্যে আবদ্ধ করতে হবে। (চেষ্টা করুন ... ধরুন এবং সমস্ত কিছু।)
এটি করা যেতে পারে ... তবে হ্যান্ডলারের পক্ষে এই ব্যতিক্রমগুলির প্রতিক্রিয়াতে কীভাবে "সঠিক কাজটি করা যায়" তা জানা মুশকিল যেহেতু যে কোডটিতে তারা উত্থাপিত হতে পারে সেখানে অনেকগুলি, অনেক পয়েন্ট থাকবে। (বিশেষত, তারা ভার্চুয়ালআলোক'র স্মৃতি, ম্যালোক বা নতুন দ্বারা বরাদ্দ স্মৃতিতে এবং সমস্ত স্থানীয় ভেরিয়েবলগুলিতেও প্রতিটি স্মৃতি রেফারেন্সে উত্থিত হতে পারে , যেহেতু স্ট্যাকটি ভার্চুয়াল অলোক'ডও রয়েছে is)
সংক্ষেপে, এই ক্ষেত্রে প্রোগ্রামটিকে গ্রেফতার করে ব্যর্থ করা খুব কঠিন হবে।
অন্যদিকে ভার্চুয়ালআলোক (বা ম্যালোক বা নতুন, যদি তারা একেবারে একই জিনিস না হয়) এর জন্য ন্যূনাল পয়েন্টার রিটার্নের জন্য চেক করা খুব সহজ এবং তারপরে যুক্তিসঙ্গত কিছু করুন ... যেমন যাওয়ার চেষ্টা না করা চালু করুন এবং প্রোগ্রামটি যা ছিল তা করার জন্য সেই ভার্চুয়াল স্পেসের প্রয়োজন ছিল। এবং সম্ভবত ব্যবহারকারীকে জিজ্ঞাসা করুন তারা এখন পর্যন্ত যদি তাদের কাজটি সংরক্ষণ করতে চায় তবে তা যদি থাকে। (মঞ্জুর, অনেক বেশি অ্যাপ্লিকেশন এত বেশি করেও বিরক্ত করে না))
প্রতিশ্রুতিবদ্ধ অন্যান্য ব্যবহারকারীদের
ঘটনাচক্রে, ওএসের বিভিন্ন বরাদ্দ যেমন পেজড এবং ননপেজড পুল, পিএফএন তালিকা ইত্যাদি দ্বারা "কমিট সীমা" হ্রাস করা যায় না; এগুলি কেবল ঘটনার সাথে সাথে চার্জ দেওয়ার জন্য চার্জ করা হয়। তেমনি কোনও ভিডিও র্যাম বা এমনকি ভিডিও র্যাম "উইন্ডো" আকার দ্বারা প্রভাবিত বা প্রতিশ্রুতিবদ্ধ সীমাবদ্ধতাও নয়।
নিজেই পরীক্ষা করে দেখুন
সিসি ইন্টার্নালালস সাইট থেকে টেস্টিমিট সরঞ্জামের সাহায্যে আপনি এগুলি সব ডেমো করতে পারেন। বিকল্প-এম প্রতিশ্রুতিবদ্ধ ঠিকানা স্থান বরাদ্দ করবে কিন্তু এটি "স্পর্শ" করবে না, তাই র্যামের বরাদ্দ সৃষ্টি করবে না। যেখানে বিকল্প -d পৃষ্ঠাগুলি বরাদ্দ করবে এবং রেফারেন্সও দেবে, যার ফলে উভয়ই কমিট চার্জ বৃদ্ধি পাবে এবং র্যাম হ্রাস পাবে।
তথ্যসূত্র
রাশিনোভিচ, সলোমন এবং আয়নস্কু দ্বারা উইন্ডোজ ইন্টারনাল । এমনকী বিক্ষোভগুলিও রয়েছে যা আপনাকে পরীক্ষামূলক সরঞ্জাম ব্যবহার করে এই সমস্ত পয়েন্ট প্রমাণ করতে দেয়। তবে, আপনাকে অবশ্যই সতর্ক করতে হবে যে আপনি যদি মনে করেন এটি দীর্ঘ ছিল, সতর্কতা অবলম্বন করুন: এমএম অধ্যায়টি কেবল 200 পৃষ্ঠা; উপরেরটি একটি অত্যন্ত সরল সংস্করণ। (দয়া করে পরিচিতির "স্বীকৃতি" বিভাগটিও দেখুন nce)
আরও দেখুন দুটিই MSDN VirtualAlloc ডকুমেন্টেশন
