টি এল; ডিআর
সংক্ষিপ্ত অস্থায়ী / উত্তর
- সবচেয়ে সহজ : একটি ছোট অদলবদল করুন এবং ধীরে ধীরে স্টোরেজ থেকে প্রক্রিয়া চালিয়ে কোনও মেমরির সীমা নেই বলে মিথ্যা কথা বলার চেষ্টা করে কার্নেলটি এড়িয়ে চলুন।
- একটি বড় অদলবদল করার পরে, OOM (মেমরি পরিচালকের বাইরে) খুব শীঘ্রই পদক্ষেপ নেয় না। সাধারণত, এটি ভার্চুয়াল মেমোরি অনুসারে অ্যাকাউন্ট করে এবং আমার অতীতের অভিজ্ঞতায়, পুরো অদল-বদল না হওয়া পর্যন্ত জিনিসগুলিকে মেরে ফেলেনি, সুতরাং থ্র্যাসিং এবং ক্রলিং সিস্টেমটি ...
- হাইবারনেটের জন্য একটি বড় অদলবদল দরকার?
- চেষ্টা করা / সমস্যাযুক্ত : কিছু ইউলিমিট সেট করুন (যেমন চেক করুন
ulimit -vএবং সম্ভবত asবিকল্পটি ব্যবহার করে একটি শক্ত বা নরম সীমা নির্ধারণ করুন limits.conf)। এটি যথেষ্ট ভাল কাজ করত, তবে ওয়েবকিট প্রবর্তনের জন্য ধন্যবাদ gigacage, অনেক জিনোম অ্যাপ্লিকেশন এখন সীমাহীন অ্যাড্রেস স্পেস আশা করে এবং চালাতে ব্যর্থ হয়!
- প্রয়াস / সমস্যাযুক্ত : overcommit নীতি এবং অনুপাত অন্য উপায় পরিচালনা চেষ্টা করুন এবং এই প্রশমিত (যেমন হয়
sysctl vm.overcommit_memory, sysctl vm.overcommit_ratioকিন্তু এই পদ্ধতির বাইরে আমার জন্য কাজ করে নি।
- অসুবিধা / জটিল : সর্বাধিক গুরুত্বপূর্ণ প্রক্রিয়াগুলিতে (উদাহরণস্বরূপ ssh) সিগ্রুপের অগ্রাধিকার প্রয়োগের চেষ্টা করুন, তবে বর্তমানে এটি সিগ্রুপ ভি 1 এর জন্য জটিল মনে হচ্ছে (আশা করি ভি 2 এটি সহজ করে দেবে) ...
আমি এটিও পেয়েছি:
দীর্ঘ মেয়াদী সমাধান solution
অপেক্ষা করুন এবং কিছু প্রবাহ প্যাচগুলি স্থিতিশীল ডিস্ট্রো কার্নেলগুলিতে প্রবেশের জন্য আশা করুন। এছাড়াও আশা করি যে ডিসট্রো বিক্রেতারা আরও ভাল টিউন কার্নেল ডিফল্ট এবং ডেস্কটপ সংস্করণগুলিতে GUI প্রতিক্রিয়াটিকে অগ্রাধিকার দিতে আরও ভাল লিভারেজ সিস্টেমেড সিগ্রুপগুলি উপস্থাপন করতে পারেন।
আগ্রহের কিছু প্যাচ:
সুতরাং এটি কেবল খারাপ ব্যবহারকারীর স্পেস কোড এবং ডিস্ট্রো কনফিগারেশন / ডিফল্ট নয় যা ত্রুটিযুক্ত - কার্নেল এটি আরও ভালভাবে পরিচালনা করতে পারে।
ইতিমধ্যে বিবেচিত বিকল্পগুলির উপর মন্তব্যসমূহ
1) অদলবদল অক্ষম করুন
কমপক্ষে একটি ছোট অদলবদল সরবরাহ করার প্রস্তাব দেওয়া হয় ( আধুনিক সিস্টেমে আমাদের কী সত্যই দরকার? ) অদলবদল অক্ষম করা কেবল অব্যবহৃত পৃষ্ঠাগুলি অদলবদলকেই প্রতিরোধ করে না, এটি মেমরি বরাদ্দকরণের জন্য কার্নেলের ডিফল্ট হিউরিস্টিক ওভারকমিট কৌশলকেও প্রভাবিত করতে পারে ( ওভারকমিট_মেমোরি = 0 এর অর্থাত্ হিউরিস্টিকস কী বোঝায়? ) যেহেতু হিউরিস্টিক অদলবদল পৃষ্ঠাগুলিতে গণনা করে। অদলবদল ছাড়াই ওভারকমিট সম্ভবত সম্ভবত হিউরিস্টিক (0) বা সর্বদা (1) মোডে কাজ করতে পারে তবে কোনও অদলবদল এবং কখনই (2) ওভার কমিট কৌশলটির সংমিশ্রণ সম্ভবত একটি ভয়ঙ্কর ধারণা। সুতরাং বেশিরভাগ ক্ষেত্রে, কোনও অদলবদলের সম্ভবত কর্মক্ষমতা ক্ষতিগ্রস্থ হবে না।
উদাহরণস্বরূপ, দীর্ঘ-চলমান প্রক্রিয়াটি সম্পর্কে ভাবুন যা প্রথমদিকে একবার বন্ধ কাজের জন্য মেমরিটিকে স্পর্শ করে, কিন্তু তারপরে সেই স্মৃতিটি প্রকাশ করতে ব্যর্থ হয় এবং পটভূমি চালিয়ে যায়। প্রক্রিয়া শেষ না হওয়া অবধি কার্নেলটিকে তার জন্য র্যাম ব্যবহার করতে হবে। কোনও অদলবদল ছাড়া, কার্নেল এটিকে অন্য কোনও কিছুর জন্য খুঁজে বের করতে পারে না যা আসলে সক্রিয়ভাবে র্যাম ব্যবহার করতে চায়। এছাড়াও কতগুলি ডিভাস অলস এবং সেগুলি স্পষ্টভাবে ব্যবহারের পরে মেমরি মুক্ত করবে না সে সম্পর্কেও ভাবুন।
3) একটি সর্বাধিক মেমরি ulimit সেট
এটি কেবলমাত্র প্রক্রিয়া অনুযায়ী প্রযোজ্য, এবং এটি সম্ভবত একটি যুক্তিসঙ্গত অনুমান যে কোনও প্রক্রিয়া শারীরিকভাবে কোনও সিস্টেমের আরও মেমরির জন্য অনুরোধ করা উচিত নয়! সুতরাং সম্ভবত উদারতার সাথে সেট হয়ে থাকা অবস্থায় একাকী পাগল প্রক্রিয়াটিকে থ্রেশিং ট্রিগার থেকে থামানো সম্ভবত দরকারী useful
৪) গুরুত্বপূর্ণ প্রোগ্রামগুলি (এক্স 11, বাশ, কিল, টপ, ...) স্মৃতিতে রাখুন এবং সেগুলি কখনই অদলবদল করবেন না
দুর্দান্ত ধারণা, তবে সেই প্রোগ্রামগুলি সক্রিয়ভাবে ব্যবহার করছে না এমন মেমরিটি হোগ করবে। এটি গ্রহণযোগ্য হতে পারে যদি প্রোগ্রামটি কেবলমাত্র একটি পরিমিত পরিমাণ মেমরির জন্য অনুরোধ করে।
সিস্টেমড 232 রিলিজ সবেমাত্র কিছু বিকল্প যুক্ত করেছে যা এটি সম্ভব করে তোলে: আমি মনে করি যে কোনও ইউনিট (পরিষেবাদি) এর যেমন কোনও স্মৃতি অদলবদল হয়ে যায় তা রোধ করার জন্য কেউ 'মেমোরিসপ্যাম্যাক্স = 0' ব্যবহার করতে পারে।
তবুও, মেমরি অ্যাক্সেসটিকে অগ্রাধিকার দিতে সক্ষম হওয়াই ভাল।
দীর্ঘ ব্যাখ্যা
লিনাক্স কার্নেলটি সার্ভার কাজের চাপের জন্য আরও সুরযুক্ত, তাই জিইউআই প্রতিক্রিয়াশীলতা দু: খজনকভাবে একটি দ্বিতীয় উদ্বেগ হয়ে দাঁড়িয়েছে ... উবুন্টু 16.04 এলটিএস-এর ডেস্কটপ সংস্করণে কার্নেল মেমরি পরিচালনার সেটিংস অন্যান্য সার্ভার সংস্করণগুলির থেকে আলাদা বলে মনে হচ্ছে না। এটি সাধারণত সার্ভার হিসাবে ব্যবহৃত RHEL / CentOS 7.2 এর ডিফল্টগুলির সাথে মেলে।
ওম, প্রতিক্রিয়াশীলতার জন্য অলিমিটিকে ট্রেডিং বন্ধ করে দেয়
অদলবদল থ্র্যাশিং (যখন মেমরির কার্যকারী সেট, যেমন পৃষ্ঠাগুলি একটি স্বল্প সময়ের ফ্রেমে পড়া এবং লেখার জন্য দৈহিক র্যামকে ছাড়িয়ে যায়) সর্বদা লকআপ স্টোরেজ I / O - কোনও কার্নেল উইজার্ড্রি কোনও প্রক্রিয়া না মেরে কোনও সিস্টেমকে এ থেকে বাঁচাতে পারে না অথবা দুই...
আমি আশা করছি আরও সাম্প্রতিক কার্নেলগুলিতে লিনাক্স ওওএম এর টুইটগুলি উপস্থিত রয়েছে এই স্বীকৃত শারীরিক মেমরির পরিস্থিতি ছাড়িয়ে গেছে এবং একটি প্রক্রিয়া মেরে ফেলেছে recognize যখন এটি হয় না, ছিটকে যাওয়ার সমস্যা ঘটে। সমস্যাটি হ'ল একটি বড় অদলবদল বিভাজন সহ, সিস্টেমটি এখনও দেখতে পেয়েছে যে শিরোনামে যখন কার্নেল আনুষঙ্গিকভাবে কাজ করে এবং এখনও মেমরির অনুরোধগুলি সরবরাহ করে তখন সিস্টেমে হেডরুম রয়েছে তবে কার্যকারী সেটটি স্টোরেজটিকে চিকিত্সার জন্য কার্যকরভাবে চেষ্টা করার চেষ্টা করছে এটা র্যাম
সার্ভারগুলিতে, এটি একটি নির্ধারিত, ধীর, ডেটা হারাবেন না, বাণিজ্য বন্ধের জন্য থ্র্যাশিংয়ের পারফরম্যান্স পেনাল্টি গ্রহণ করে। ডেস্কটপগুলিতে, বাণিজ্যটি আলাদা হয় এবং ব্যবহারকারীরা জিনিসগুলিকে প্রতিক্রিয়াশীল রাখতে কিছুটা ডেটা হ্রাস (প্রক্রিয়া ত্যাগ) পছন্দ করেন prefer
এটি ওওএম সম্পর্কে একটি দুর্দান্ত হাস্যকর উপমা ছিল: ওম_পার্ডন, ওরফে আমার এক্সলকটি মারবে না
ঘটনাক্রমে, OOMScoreAdjustওজনকে সহায়তা করা এবং ওওএম হত্যার প্রক্রিয়াটিকে আরও গুরুত্বপূর্ণ হিসাবে বিবেচনা করা এড়াতে আরেকটি সিস্টেমড বিকল্প।
বাফার রাইটব্যাক
আমি মনে করি " ব্যাকগ্রাউন্ড রাইটব্যাক না চুষে ফেলুন " এমন কিছু সমস্যা এড়াতে সহায়তা করবে যেখানে কোনও র্যাব হগিং র্যামের ফলে অন্য কিছু বদলাতে পারে (ডিস্কে লিখুন) এবং ডিস্কে বাল্ক লেখার কারণে আইও চাইলে অন্য কিছু স্টল হয়। এটি নিজেই থ্র্যাশিংয়ের সমস্যা নয়, তবে এটি প্রতিক্রিয়াশীলতার সামগ্রিক অবক্ষয়কে বাড়িয়ে তোলে।
সীমাবদ্ধতা দূর করে
ইউলিমিটগুলির সাথে একটি সমস্যা হ'ল অ্যাকাউন্টিং সীমাটি ভার্চুয়াল মেমরি অ্যাড্রেস স্পেসে প্রযোজ্য (যা শারীরিক এবং অদলবদল উভয় স্থানের সমন্বয় বোঝায়)। অনুসারে man limits.conf:
rss
maximum resident set size (KB) (Ignored in Linux 2.4.30 and
higher)
সুতরাং কেবল শারীরিক র্যাম ব্যবহারের ক্ষেত্রে প্রয়োগ করার জন্য একটি ইউলিমিট সেট করা আর ব্যবহারের মতো দেখায় না। অত: পর
as
address space limit (KB)
একমাত্র সম্মানিত টিউনযোগ্য মনে হয়।
দুর্ভাগ্যজনকভাবে, ওয়েবকিট / জোনোমের উদাহরণ হিসাবে আরও বিস্তারিতভাবে বলা হয়েছে, ভার্চুয়াল ঠিকানার জায়গার বরাদ্দ সীমাবদ্ধ থাকলে কিছু অ্যাপ্লিকেশন চলতে পারে না।
ভবিষ্যতে সাহায্য করা উচিত?
বর্তমানে এটি জটিল মনে হচ্ছে, তবে কিছু কার্নেল সিগ্রুপ পতাকা সক্ষম করা সম্ভব cgroup_enable=memory swapaccount=1(উদাহরণস্বরূপ গ্রাব কনফিগারেশনে) এবং তারপরে মেমরির ব্যবহার সীমাবদ্ধ করতে সিগ্রুপ মেমরি নিয়ামক ব্যবহার করার চেষ্টা করুন।
সিগ্রুপগুলিতে আরও উন্নত মেমরি সীমা বৈশিষ্ট্য রয়েছে তারপরে 'উলিমিট' বিকল্পগুলি। সিগ্রুপ ভি 2 নোটগুলি কীভাবে ইউলিট কাজ করে তা উন্নত করার চেষ্টা করার ইঙ্গিত দেয়।
সম্মিলিত মেমরি + অদলবদ অ্যাকাউন্টিং এবং সীমাবদ্ধকরণ অদলবদলের স্থানের উপর প্রকৃত নিয়ন্ত্রণ দ্বারা প্রতিস্থাপিত হয়।
সিগ্রুপ বিকল্পগুলি সিস্টেমড রিসোর্স নিয়ন্ত্রণ বিকল্পগুলির মাধ্যমে সেট করা যেতে পারে । উদাহরণ:
অন্যান্য দরকারী বিকল্প হতে পারে
এগুলির কিছু ত্রুটি রয়েছে:
- ওভারহেড। বর্তমান ডকার ডকুমেন্টেশন সংক্ষেপে 1% অতিরিক্ত মেমরি ব্যবহার এবং 10% কর্মক্ষমতা হ্রাস উল্লেখ করেছে (সম্ভবত মেমরি বরাদ্দকরণ ক্রিয়াকলাপগুলির ক্ষেত্রে - এটি সত্যিই নির্দিষ্ট করে না)।
- সিগ্রুপ / সিস্টেমযুক্ত স্টাফগুলি সম্প্রতি ভারী পুনরায় কাজ করা হয়েছে, সুতরাং ফ্লাক্স আপস্ট্রিমটি বোঝায় যে লিনাক্স ডিস্ট্রো বিক্রেতারা সম্ভবত এটি স্থাপনের জন্য অপেক্ষা করছে।
ইন cgroup v2 , তারা প্রমাণ করে যে memory.highশ্বাসনালী একটি ভাল বিকল্প হওয়া উচিত এবং একটি প্রক্রিয়া একদল মেমরি ব্যবহার ও পরিচালনা করুন। তবে এই উক্তিটি পরামর্শ দেয় যে মেমরির চাপের পরিস্থিতিগুলি পর্যবেক্ষণ করতে আরও কাজ করা প্রয়োজন (2015 হিসাবে)।
মেমরির চাপের একটি পরিমাপ - মেমরির অভাবের কারণে কাজের চাপ কতটা প্রভাবিত হচ্ছে - একটি কাজের চাপকে আরও মেমরির প্রয়োজন কিনা তা নির্ধারণ করার জন্য প্রয়োজনীয়; দুর্ভাগ্যক্রমে, মেমরি প্রেস মনিটরিং ব্যবস্থাটি এখনও কার্যকর হয়নি।
প্রদত্ত সিস্টেমেড এবং সিগ্রুপ ব্যবহারকারীর স্পেস সরঞ্জামগুলি জটিল, উপযুক্ত কিছু সেট করার এবং এটির আরও পরে উত্থাপনের সহজ উপায় আমি খুঁজে পাইনি। উবুন্টুর জন্য সিগ্রুপ এবং সিস্টেমেড ডকুমেন্টেশন দুর্দান্ত নয়। ভবিষ্যতের কাজ ডেস্কটপ সংস্করণগুলি সহ সিগ্রুপ এবং সিস্টেমডের জন্য ডেস্কটপ সংস্করণ থাকা উচিত যাতে উচ্চ মেমরির চাপের অধীনে, এসএসএস এবং এক্স-সার্ভার / উইন্ডো ম্যানেজারের উপাদানগুলি সিপিইউ, শারীরিক র্যাম এবং স্টোরেজ আইওতে উচ্চ অগ্রাধিকার পেতে পারে, যাতে প্রক্রিয়াগুলির সাথে প্রতিযোগিতা এড়াতে পারে ব্যস্ত অদলবদল। কার্নেলের সিপিইউ এবং I / O অগ্রাধিকার বৈশিষ্ট্যগুলি কিছু সময়ের জন্য রয়েছে। মনে হচ্ছে এটির অভাবযুক্ত শারীরিক র্যামের অগ্রাধিকার অ্যাক্সেস।
তবে, এমনকি সিপিইউ এবং আইও অগ্রাধিকারগুলি যথাযথভাবে সেট করা নেই !? আমি যখন সিস্টেমেড সিগ্রুপের সীমা পরীক্ষা করেছি, সিপিইউ শেয়ার ইত্যাদি প্রয়োগ হয়েছিল, যতদূর আমি বলতে পারি উবুন্টু কোনও পূর্বনির্ধারিত অগ্রাধিকারগুলিতে বেক করেনি। যেমন আমি দৌড়েছি:
systemctl show dev-mapper-Ubuntu\x2dswap.swap
আমি এসএস, সাম্বা, জিডিএম এবং এনজিনেক্সের জন্য একই আউটপুটটির সাথে তুলনা করেছি। জিইউআই এবং রিমোট অ্যাডমিন কনসোলের মতো গুরুত্বপূর্ণ বিষয়গুলি থ্র্যাশিংয়ের সময় অন্যান্য সমস্ত প্রক্রিয়ার সাথে সমানভাবে লড়াই করতে হয়।
১ 16 জিবি র্যাম সিস্টেমে আমার মেমরি সীমাবদ্ধতার উদাহরণ
আমি হাইবারনেট সক্ষম করতে চেয়েছিলাম, সুতরাং আমার একটি বড় অদলবদল প্রয়োজন needed সুতরাং ইউলিমিট ইত্যাদির সাহায্যে প্রশমিত করার চেষ্টা করা etc.
ulimit
আমি করা * hard as 16777216মধ্যে /etc/security/limits.d/mem.confযেমন যে কোন একক প্রক্রিয়া আরো মেমরি তুলনায় শারীরিকভাবে সম্ভব অনুরোধ করতে অনুমতি দেওয়া হবে। আমি সবাইকে একসাথে মারতে বাধা দেব না, তবে লোভী মেমরির ব্যবহারের সাথে কেবল একটি একক প্রক্রিয়া বা একটি মেমরি ফাঁস হ্রাস পেতে পারে। যেমন আমি gnome-contactsকোনও এক্সচেঞ্জ সার্ভার থেকে গ্লোবাল ঠিকানা তালিকা আপডেট করার মতো জাগতিক জিনিসগুলি করার সময় 8 গিগাবাইট + মেমরি চুষতে দেখেছি ...
যেমন দেখা গেছে ulimit -S -v, অনেকগুলি ডিস্ট্রো'র এই শক্ত এবং নরম সীমাটি 'সীমাহীন' হিসাবে নির্ধারিত হিসাবে দেওয়া হয়েছে, তাত্ত্বিকভাবে, একটি প্রক্রিয়া প্রচুর মেমরির জন্য অনুরোধ করতে পারে তবে কেবল সক্রিয়ভাবে একটি উপসেট ব্যবহার করে, এবং আনন্দের সাথে চালাতে ভেবে ভেবে চালিত হয় যে এটি 24 গিগাবাইট র্যাম বলে সিস্টেমে কেবল ১GB জিবি রয়েছে। উপরের হার্ড সীমাটি এমন প্রক্রিয়া তৈরি করবে যেগুলি যখন কার্নেল তাদের লোভী অনুমানমূলক মেমরির অনুরোধগুলি অস্বীকার করে তখন জালিয়াতি করতে জরিমানা চালাতে সক্ষম হতে পারে।
যাইহোক, এটি জিনোম পরিচিতিগুলির মতো উন্মাদ জিনিসগুলিও ধরে এবং আমার ডেস্কটপের প্রতিক্রিয়াটি হারিয়ে ফেলার পরিবর্তে, আমি "পর্যাপ্ত ফ্রি মেমরি নয়" ত্রুটি পেয়েছি:
জটিলতার জন্য ঠিকানা স্থানের জন্য ওলিমিট সেট করা (ভার্চুয়াল মেমরি)
দুর্ভাগ্যক্রমে, কিছু বিকাশকারী ভার্চুয়াল মেমরির ভান করতে পছন্দ করে অসীম সংস্থান এবং ভার্চুয়াল মেমরির উপর একটি ইউলিমিট সেট করা কিছু অ্যাপ্লিকেশনগুলিকে ভেঙে দিতে পারে। উদাহরণস্বরূপ ওয়েবকিট (যা কিছু জিনোম অ্যাপস নির্ভর করে) একটি gigacageসুরক্ষা বৈশিষ্ট্য যুক্ত করেছে যা পাগল পরিমাণ ভার্চুয়াল মেমরির বরাদ্দ করার চেষ্টা করে এবং FATAL: Could not allocate gigacage memoryএকটি দালাল ইঙ্গিত সহ ত্রুটিগুলি Make sure you have not set a virtual memory limitঘটে। কাজ প্রায়,GIGACAGE_ENABLED=noসুরক্ষা সুবিধাগুলি ত্যাগ করে তবে তেমনি ভার্চুয়াল মেমরি বরাদ্দকে সীমাবদ্ধ করার অনুমতি না দেওয়া একটি সুরক্ষা বৈশিষ্ট্যও (যেমন রিসোর্স কন্ট্রোল যা পরিষেবার অস্বীকারকে আটকাতে পারে) ত্যাগ করে। হাস্যকরভাবে, গিগােজ এবং জিনোম ডেভসের মধ্যে, তারা মনে করতে পারে যে মেমরি বরাদ্দকে সীমাবদ্ধ করা নিজেই একটি সুরক্ষা নিয়ন্ত্রণ। এবং দুঃখের বিষয়, আমি লক্ষ্য করেছি যে জিনোম অ্যাপ্লিকেশনগুলি যা গিগাসেজের উপর নির্ভর করে স্পষ্টভাবে উচ্চতর সীমাটির জন্য অনুরোধ করতে বিরক্ত করে না, তাই এমনকি নরম সীমাও এই ক্ষেত্রে জিনিসগুলিকে ভেঙে দেয়।
সত্য কথা বলতে গেলে, কার্নেল যদি ভার্চুয়াল মেমরির পরিবর্তে আবাসিক মেমরির ব্যবহারের ভিত্তিতে মেমরি বরাদ্দকে অস্বীকার করতে সক্ষম হওয়ার জন্য আরও ভাল কাজ করে, তবে ভার্চুয়াল মেমরির ভান করা সীমাহীন কম বিপজ্জনক হবে।
overcommit
আপনি যদি অ্যাপ্লিকেশনগুলিকে মেমরি অ্যাক্সেস প্রত্যাখ্যান করতে পছন্দ করেন এবং অতিরিক্ত কমিটি বন্ধ করতে চান, উচ্চ মেমরির চাপের মধ্যে থাকা অবস্থায় আপনার সিস্টেমটি কী আচরণ করে তা পরীক্ষা করতে নীচের কমান্ডগুলি ব্যবহার করুন।
আমার ক্ষেত্রে, ডিফল্ট প্রতিশ্রুতি অনুপাত ছিল:
$ sysctl vm.overcommit_ratio
vm.overcommit_ratio = 50
অতিরিক্ত মাত্রায় নিষ্ক্রিয় করতে এবং অনুপাত প্রয়োগ করতে নীতি পরিবর্তন করার সময় এটি সম্পূর্ণ কার্যকর হয়
sudo sysctl -w vm.overcommit_memory=2
অনুপাতটিকে বোঝানো হয়েছে কেবল 24 গিগাবাইট মেমরির সামগ্রিক বরাদ্দ করা যায় (16 গিগাবাইট র্যাম * 0.5 + 16 গিগাবাইট সোয়াপ্প)। সুতরাং আমি সম্ভবত কখনই ওওএম-কে দেখায়নি এবং কার্যকরভাবে প্রক্রিয়াগুলি অদলবদলে অবিচ্ছিন্নভাবে মেমরি অ্যাক্সেস করার সম্ভাবনা কম থাকে। তবে আমি সম্ভবত সামগ্রিক সিস্টেমের দক্ষতা ত্যাগ করব।
এটি মেমরি বরাদ্দকরণের অনুরোধটিকে অস্বীকার করে ওএসকে কৃপণভাবে পরিচালনা করতে না পারার পক্ষে সাধারণভাবে অনেকগুলি অ্যাপ্লিকেশন ক্র্যাশ হয়ে যাবে। এটি বিভিন্ন অ্যাপ্লিকেশন ক্রাশ হওয়ার ঘন ঘন ঝুঁকির জন্য ছোঁড়ার কারণে (হার্ড রিসেটের পরে আপনার সমস্ত কাজ আলগা করে) ছাড়িয়ে যাওয়া লকআপের মাঝেমধ্যে ঝুঁকি নিয়ে কাজ করে। আমার পরীক্ষায়, এটি খুব একটা সুবিধা দেয়নি কারণ ডেস্কটপ নিজেই ক্র্যাশ হয়েছিল যখন সিস্টেমটি মেমরির চাপের মধ্যে ছিল এবং এটি মেমরির বরাদ্দ করতে পারে না। তবে কমপক্ষে কনসোল এবং এসএসএইচ এখনও কাজ করে।
ভিএম ওভারকমিট মেমরির কাজের কীভাবে আরও তথ্য রয়েছে।
sudo sysctl -w vm.overcommit_memory=0পুরো ডেস্কটপ গ্রাফিকাল স্ট্যাক এবং এর মধ্যে থাকা অ্যাপ্লিকেশনগুলি ক্রাশ করেও আমি এর জন্য ডিফল্টে ফিরে যেতে বেছে নিয়েছি ।