ওএম-কিলার কেবল যে প্রক্রিয়াটি খুব বেশি চেয়েছিল কেবল তাকে হত্যা করতে পারে না কেন?

Question

এখানে ব্যাখ্যা করা হয়েছে যে ওওএম-কিলারটি overcommit_memoryএবং এর মাধ্যমে কনফিগার করা যায়:

• 2 = অতিরিক্ত কমিট নেই। খুব বেশি জিজ্ঞাসা করলে বরাদ্দগুলি ব্যর্থ হয়।
• 0, 1 = অতিরিক্ত কমিট (তাত্পর্যপূর্ণ বা সর্বদা)। যখন খুব বেশি মেমোরি আসলে অ্যাক্সেস হয় তখন কিছু হিউরিস্টিকের ভিত্তিতে কিছু প্রক্রিয়া (এস) হত্যা করুন।

এখন, আমি এটি পুরোপুরি ভুল বুঝে উঠতে পারি, তবে কেন খুব কার্যকর প্রক্রিয়াটি যে এটি বরাদ্দ করা হয়েছে তা অ্যাক্সেস করার চেষ্টা করে কেন একটি বিকল্প নেই (বা এটি ডিফল্ট নয় কেন)?

Comments

একটি সমালোচনামূলক সিস্টেম প্রক্রিয়া যদি খুব বেশি মেমরির জন্য জিজ্ঞাসা করে?

— লরেন্স

প্রথম স্থানে - এটি এই জিনিসটি করতে পারে। তবে, এই প্রশ্নের সবচেয়ে বড় সমস্যাটি হ'ল সমস্ত সম্ভাবনার মধ্যে যদি কোনও প্রক্রিয়া মেমরির জন্য জিজ্ঞাসা করে তবে তা নতুনভাবে কার্যকর করা হয় - বা, অন্য কথায়, এটি একটি বর্তমান প্রক্রিয়াতে জড়িত একটি নতুন প্রক্রিয়া। আপনি কি OOM এর পরিবর্তে 3 দিনের জন্য অন-খোলা ইমেল ক্লায়েন্টকে সিস্টেমের মেমোরি নষ্ট করার অনুমতি দেবেন বা আপনি বরং ইউটিউবকে এই বছর কিছুটা সময় লোড করবেন? linuxatemyram.com

— মাইকেসার্ভ

এই কি no overcommitবিকল্প মূলত আছে। যদি কোনও প্রক্রিয়া খুব বেশি স্মৃতি চেয়ে বলে তবে এটি ব্যর্থ হয়। যদি এটি ত্রুটিটি পরীক্ষা করে তবে এটি সাধারণত নিজেকে মেরে ফেলবে; যদি এটি না ঘটে তবে এটি সম্ভবত যে নাল পয়েন্টারটি malloc()ফেরত দেবে, এবং এটি ক্র্যাশ হবে তা অবজ্ঞার চেষ্টা করার পরে এটি সম্ভবত একটি সেগমেন্টেশন ত্রুটিটি পাবে।

— বর্মার

উল্লেখ্য যে 2 প্রকৃতপক্ষে no overcommitমোড, উদ্ধৃত উত্স অনুসারে (যেমন কার্নেল.আর / ডক / ডকুমেন্টেশন / ভিএম / ওভারকমিট- অ্যাকাউন্টিং )। আমি মনে করি আমি সেই অনুযায়ী আপনার প্রশ্নটি সম্পাদনা করব।

— হ্যান্স_মাইন 2'18

Answer 1

এই পরিস্থিতিতে বিবেচনা করুন:

• আপনার 4 গিগাবাইট মেমরি বিনামূল্যে free
• একটি ত্রুটিযুক্ত প্রক্রিয়া 3.999 জিবি বরাদ্দ করে।
• পলাতক প্রক্রিয়াটি হ্রাস করার জন্য আপনি একটি টাস্ক ম্যানেজার খুলুন। টাস্ক ম্যানেজার 0.002 জিবি বরাদ্দ করে।

যদি নিহত হওয়া প্রক্রিয়াটি মেমরির অনুরোধের শেষ প্রক্রিয়া হয় তবে আপনার টাস্ক ম্যানেজারকে হত্যা করা হবে।

বা:

• আপনার 4 গিগাবাইট মেমরি বিনামূল্যে free
• একটি ত্রুটিযুক্ত প্রক্রিয়া 3.999 জিবি বরাদ্দ করে।
• পলাতক প্রক্রিয়াটি হ্রাস করার জন্য আপনি একটি টাস্ক ম্যানেজার খুলুন। এক্স সার্ভারটি টাস্ক ম্যানেজারের উইন্ডোটি পরিচালনা করতে 0.002GB বরাদ্দ করে।

এখন আপনার এক্স সার্ভারটি মারা যায়। এটি সমস্যার কারণ হয়নি; এটি ছিল "ভুল সময়ে ভুল জায়গায়"। এটি কিছুই ছিল না যখন আরও মেমরি বরাদ্দ করার প্রথম প্রক্রিয়া হয়েছিল, তবে এটি প্রক্রিয়াটি নয় যা সমস্ত স্মৃতি দিয়ে শুরু করেছিল।

Comments

আপনার উদাহরণটি প্রসারিত করার অর্থ হ'ল কোনও প্রক্রিয়া যদি আপনার স্মৃতিতে 99.999% গ্রাস করে তবে আপনি কখনই এটি হত্যা করতে সক্ষম হবেন না কারণ এর ফলে যে কোনও কিছু হ'তে পারে তার স্মৃতি দরকার এবং এভাবে ভুল প্রক্রিয়াটি হত্যার আগেই নিজেকে হত্যা করা যায়!

— টানা স্লেজগাড়ির

মনে মনে, এটি লিনাক্স দর্শন, একটি প্রয়োজনীয় সত্য নয়। উইন্ডোজ 3.0 প্রয়োজনীয় ডায়ালগগুলি সহ ওওএম হ্যান্ডলিংয়ের জন্য পর্যাপ্ত মেমরির সংরক্ষণ করে এটি সমাধান করেছে।

— এমসাল্টারস

@ এসএমএলটারস: যদিও এটি উদাহরণের ক্ষেত্রে সত্যই প্রযোজ্য নয়; উদাহরণটি এমন একটি প্রক্রিয়া সম্পর্কে ছিল যা প্রায় সমস্ত মেমরির সংরক্ষণ করে ie নিজেকে ওওএমকে হত্যা করার পক্ষে যথেষ্ট নয়। স্পষ্টতই যে কোনও ওএসে ওওএম হ্যান্ডলিংয়ের জন্য পর্যাপ্ত পরিমাণ মেমোরি থাকতে হবে। OOM হ্যান্ডলিংয়ের জন্য অনুরোধ করা প্রক্রিয়াটি হ'ল পরবর্তী প্রক্রিয়া যা মেমরি সংরক্ষণের জন্য ঘটে তা হ'ল দুর্ব্যবহার নয়। অবশ্যই, যদি না আপনি বোঝাতে চেয়েছিলেন যে উইন্ডোজ 3.0 এর ক্ষেত্রে টাস্ক ম্যানেজারটি চালনার জন্য সর্বদা পর্যাপ্ত মেমরি সংরক্ষিত থাকে বা OOM হ্যান্ডলার সর্বদা ব্যবহারকারীকে প্রক্রিয়াটিকে হত্যা করার জন্য অনুরোধ জানায়। (যা! = আপত্তিজনক প্রক্রিয়া হত্যার)

— আলেক্সি তোড়হামো

@ আলেকসী তোরহামো: আমি প্রকৃতপক্ষে বোঝাতে চাইছি। উইন্ডোজ 3.0 এর কোনও ফুলব্লাউন টাস্ক ম্যানেজার ছিল না, এর বিখ্যাত নীল পর্দা রয়েছে যার স্মৃতি পূর্বনির্ধারিত ছিল।

— MSalters