ডিফল্টভাবে লিনাক্স ওওএম কিলারটি বন্ধ করবেন?

Question

লিনাক্সের ওওম কিলার প্রায়শই প্রায়শই বিভিন্ন অ্যাপ্লিকেশনগুলির সাথে সর্বনাশ করে এবং এটিকে উন্নত করার জন্য কার্নেল বিকাশের দিক থেকে খুব বেশি কিছু করা হয় না বলে মনে হয়। নতুন সার্ভার সেটআপ করার সময়, সর্বোত্তম অনুশীলন হিসাবে মেমরির ওভার কমমিটিংয়ে ডিফল্টটি বিপরীত করার জন্য, অর্থাৎ এটি বন্ধ করুন ( vm.overcommit_memory=2) যদি না আপনি জানেন যে আপনি এটি নির্দিষ্ট ব্যবহারের জন্য না চান? আপনি যখন জানেন যে আপনি ওভার কমিটিংটি চান তখন সেইগুলি ব্যবহারের ক্ষেত্রে কী হবে?

বোনাস হিসাবে, যেহেতু আচরণটি স্থানের vm.overcommit_memory=2উপর নির্ভর করে vm.overcommit_ratioএবং অদলবদলের উপর নির্ভর করে , দ্বিতীয়টি আকার দেওয়ার জন্য থাম্বের কী একটি ভাল নিয়ম হবে যাতে এই পুরো সেটআপটি যুক্তিযুক্তভাবে কাজ করে চলে?

Answer 1

একটি আকর্ষণীয় উপমা ( http://lwn.net/Articles/104179/ থেকে ):

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

Comments

আমি এটি খুব উপভোগ করেছি, এটি খনন করার জন্য ধন্যবাদ।

— নিক বোল্টন

Answer 2

আপনি যদি নিজের সিস্টেমে অতিরিক্ত চাপ পড়ে থাকেন তবে ওওএম কিলারটি কেবল সর্বনাশ ডেকে আনবে। এটি পর্যাপ্ত পরিমাণে অদলবদল করুন এবং এমন অ্যাপ্লিকেশনগুলি চালান না যা হঠাৎ করে প্রচুর পরিমাণে র‌্যাম খাওয়ার সিদ্ধান্ত নেয় এবং আপনার কোনও সমস্যা হবে না।

বিশেষভাবে আপনার প্রশ্নের উত্তর দিতে:

• আমি মনে করি না যে সাধারণ ক্ষেত্রে ওভারকমিট বন্ধ করা ভাল ধারণা; brk(2) (এবং এটি যে মোড়ক ব্যবহার করে যেমন malloc(3)) একটি ত্রুটি ফিরিয়েছে তা সঠিকভাবে ডিল করার জন্য খুব কম অ্যাপ্লিকেশন লেখা হয় । আমি যখন আগের কাজটিতে এটি নিয়ে পরীক্ষা-নিরীক্ষা করেছি তখন মনে করা হয়েছিল যে এটি কোনও ওওমের পরিণতি (যা আমাদের ক্ষেত্রে, কোনও ওওএম ঘটলে মাঝেমধ্যে পরিষেবাটি পুনরায় চালু করার চেয়েও খারাপ ছিল - আমাদের একটি সম্পূর্ণ ক্লাস্টারটি পুনরায় বুট করতে হয়েছিল, কারণ জিএফএস মলসের একটি বাষ্পীয় গাদা)।
• আপনি যে কোনও প্রক্রিয়া যাতে মেমরিকে ছাড়িয়ে যায় তার জন্য ওভার কমিটিং করতে চান। এখানকার সবচেয়ে সাধারণ দুটি অপরাধী হলেন আপাচি এবং জেভিএম, তবে প্রচুর অ্যাপগুলি কিছুটা বেশি বা কম ডিগ্রীতে এটি করে। তারা মনে তারা পারে ভবিষ্যতে কিছু সময়ে মেমরি অনেক প্রয়োজন, তাই তারা একটি বড় খণ্ড এক্ষুণি দখল। একটি ওভারকমিট-সক্ষম সক্ষম সিস্টেমে, কার্নেলটি "মেহ, যাই হোক না কেন, যখন আপনি আসলে সেই পৃষ্ঠাগুলিতে লিখতে চান" তখন আমাকে বিরক্ত করুন "এবং খারাপ কিছু হয় না। একটি অতিরিক্ত কম-অফ সিস্টেমে, কার্নেলটি বলে "না, আপনার এত স্মৃতি থাকতে পারে না, আপনি যদি ভবিষ্যতে কোনও মুহুর্তে এগুলি লিখতে লিখতে পারেন তবে আমি আপনার জন্য স্মৃতি নেই!" এবং বরাদ্দ ব্যর্থ হয়। যেহেতু কিছুইবাইরে চলে যায় "ওহ, ঠিক আছে, আমি কি প্রসেস ডেটা বিভাগের এই আরও কম পরিমাণে থাকতে পারি?", তারপরে প্রক্রিয়াটি (ক) মেমরির বাইরে থাকা ত্রুটি সহ প্রস্থান করে, বা (খ) এর থেকে রিটার্ন কোডটি পরীক্ষা করে না malloc, মনে হয় এটি যেতে ঠিক আছে, এবং একটি অবৈধ মেমরি অবস্থান লিখুন, একটি segfault কারণ। কৃতজ্ঞ, জেভিএম স্টার্টআপে এটি সমস্তই প্রাকলক করে (তাই আপনার জেভিএম হয় তাত্ক্ষণিকভাবে শুরু হয় বা মারা যায়, যা আপনি সাধারণত লক্ষ্য করেন), তবে আপাচি প্রতিটি নতুন বাচ্চার সাথে এটি মজাদার জিনিস দেয়, যার উত্পাদনে উত্তেজনাপূর্ণ প্রভাব পড়তে পারে (অগ্রহণযোগ্য "সংযোগ পরিচালনা না করা) "উত্তেজনার ধরণ)।
• আমি আমার ওভারকমিট_রেটিওকে 50% এর ডিফল্টের চেয়ে উচ্চতর সেট করতে চাই না। আবার, আমার পরীক্ষাকার্যের থেকে, যদিও এটি আপ 80 বা 90 যথাসাধ্য সেটিং সাউন্ড একটি শীতল ধারণা মত, কার্নেল অসুবিধাজনক সময়ে মেমরি বড় অংশ প্রয়োজন, এবং একটি উচ্চ overcommit অনুপাত সঙ্গে একটি সম্পূর্ণরূপে লোড সিস্টেম সম্ভবত অপর্যাপ্ত অতিরিক্ত মেমরি থাকতে হয় যখন কার্নেলটির এটির প্রয়োজন হয় (ভয়, মহামারী এবং ওওপিস হতে পারে)। সুতরাং ওভারকমিটের সাথে খেলে একটি নতুন, আরও মজাদার ব্যর্থতা মোড প্রবর্তিত হয় - স্মৃতিশক্তি শেষ হয়ে যাওয়ার পরে OOMed হওয়া যে কোনও প্রক্রিয়া পুনরায় চালু না করে এখন আপনার মেশিনটি ক্র্যাশ হয়ে যায়, যার ফলে মেশিনে সমস্ত কিছু বিচ্ছিন্ন হয়ে যায়। অসাধারণ!
• একটি ওভার কমিট-মুক্ত সিস্টেমে অদলবদল আপনার অ্যাপ্লিকেশনগুলির জন্য কতগুলি অনুরোধযুক্ত-তবে-অব্যবহৃত মেমরির প্রয়োজন, তার চেয়ে বেশি স্বাস্থ্যকর সুরক্ষার মার্জিনের উপর নির্ভরশীল। নির্দিষ্ট ক্ষেত্রে যা প্রয়োজন তা নিয়ে কাজ করা পাঠকের অনুশীলন হিসাবে ছেড়ে দেওয়া হয়েছে।

মূলত, আমার অভিজ্ঞতা হ'ল ওভারকমিটটি বন্ধ করা একটি দুর্দান্ত পরীক্ষা যা তাত্ত্বিকভাবে শোনাতে খুব কমই অনুশীলনের পাশাপাশি কাজ করে। এটি কর্নেলের অন্যান্য টিউনবেলের সাথে আমার অভিজ্ঞতার সাথে সামঞ্জস্যপূর্ণ - লিনাক্স কার্নেল বিকাশকারীরা প্রায় সবসময় আপনার চেয়ে বেশি স্মার্ট এবং ডিফল্টগুলি বিস্তৃত, বিস্তৃত অংশের ক্ষেত্রে সবচেয়ে ভাল কাজ করে । তাদের একা ছেড়ে যান এবং পরিবর্তে কোন প্রক্রিয়া ফাঁস হয়েছে তা সন্ধান করুন এবং এটি ঠিক করুন।

Comments

আমি চাই না যে আমার ব্যাকআপ প্রক্রিয়াটি মারা যায় কারণ কেউ আমার ওয়েব সার্ভারকে ডস-ইনগ করছে ing ব্যতিক্রমগুলি ঠিক আছে তবে ডিফল্টটি সুরক্ষা এবং ধারাবাহিকতা হওয়া উচিত। ওওমের মতো অপ্টিমাইজেশানগুলি ম্যানুয়ালি আইএমএইচও চালু করা উচিত। এটি কোডিংয়ের মতো, আপনি পরিষ্কারভাবে কোড কোড করুন এবং তারপরে অনুকূলিত হন। ওভার-কমিট একটি দুর্দান্ত বৈশিষ্ট্য, তবে এটি ডিফল্ট হওয়া উচিত নয়।

— আকি

যদি আপনি না চান যে আপনার ব্যাকআপ প্রক্রিয়াটি মারা যেতে পারে কারণ কেউ আপনার ওয়েব সার্ভারকে ডস-ইন করছে, আপনার ওয়েবসারভারটি এমনভাবে কনফিগার করবেন না যে কোনও ডস সিস্টেমের সংস্থানগুলিকে ডুবে যেতে পারে।

— দোলা

আমার 8 গিগাবাইট র‌্যাম রয়েছে এবং ফায়ারফক্স এবং ভার্চুয়াল মেশিনটি চালানো কখনও কখনও ওওএম হত্যাকারীর ভিএমকে হত্যা করে। অবাস্তব ইঞ্জিন 4 সংকলন করে প্রতিটি ঝাঁকুনির আমন্ত্রণটি 1 ~ 1.5 গিগাবাইট মেমরি নেয় এবং আবারও, ওওএম হত্যাকারী এখন এবং পরে একে একে হত্যা করে। এখন আমি এটির সাথে সাধারণত ভাল আছি, ওওএম ঘাতক ছাড়া তারা সম্ভবত সেগফল্ট করবে। এটি ঠিক যে প্রতিবার ওওএম ঘাতক কোনও প্রক্রিয়া হত্যা করতে চায়, খারাপ প্রক্রিয়াটি আসলে মারা যাওয়ার আগে আমার সিস্টেম 10 মিনিটের জন্য হিমশীতল হয়ে যায়। বাগ সম্ভবত? খুব সম্ভবত। আমি কি এটা চাই? অবশ্যই না. এবং এ কারণেই আপনারা OOM হত্যাকারীকে অক্ষম করতে চান।

— শাহবাজ

আপনি যদি বাক্সে যা কিছু করে থাকেন আপনার আরও বেশি র‌্যাম লাগবে এবং অতিরিক্ত কমিট অক্ষম করা কেবল এটিকে আরও খারাপ করবে।

— বেন লুটজেন

Answer 3

হুম, আমি ওভার কমিট এবং ওওএম হত্যাকারীর পক্ষে যুক্তি দ্বারা সম্পূর্ণরূপে বিশ্বাসী নই ... যখন দোলাচল লেখেন,

"যদি আপনি আপনার সিস্টেমটি ওভারলোড করে থাকেন তবে ওওএম হত্যাকারী কেবলই ধ্বংসস্তূপ ডেকে আনে it এটি পর্যাপ্ত পরিমাণে সোয়াপ দিন এবং এমন অ্যাপ্লিকেশনগুলি চালান না যা হঠাৎ করে প্রচুর পরিমাণে র‌্যাম খাওয়ার সিদ্ধান্ত নেয় এবং আপনার কোনও সমস্যা হবে না।"

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

জেভিএম উদ্বেগের জন্য, ভাল, এটি একটি ভার্চুয়াল মেশিন, কিছুটা হলেও এটির শুরুতে প্রয়োজনীয় সমস্ত সংস্থান বরাদ্দ করা দরকার , যাতে এটি তার অ্যাপ্লিকেশনগুলির জন্য তার 'নকল' পরিবেশ তৈরি করতে পারে এবং তার উপলব্ধ উত্সটিকে হোস্ট থেকে পৃথক রাখতে পারে পরিবেশ, যতদূর সম্ভব। সুতরাং, এটি 'বাহ্যিক' ওওএম শর্তের ফলে (ওভারকমিট / ওওএম হত্যাকারী / যে কোনও কারণে ঘটে) বা তারপরে যে কোনও অবস্থাতেই হস্তক্ষেপের কারণে ক্ষতিগ্রস্থ হওয়ায় এর ফলে কিছুটা সময় বাদে এটি প্রারম্ভকালে ব্যর্থ হওয়া বাঞ্ছনীয় might অভ্যন্তরীণ ওওএম হ্যান্ডলিং কৌশলগুলি (সাধারণভাবে, কোনও ভিএম শুরু থেকে প্রয়োজনীয় প্রয়োজনীয় সংস্থান অর্জন করতে পারে এবং হোস্ট সিস্টেমকে শেষ অবধি এগুলি 'উপেক্ষা' করা উচিত, গ্রাফিক্স কার্ডের সাথে ভাগ করা কোনও পরিমাণ শারীরিক রাম কখনই হয় না - এবং হতে পারে না) - ওএস দ্বারা স্পর্শ)।

অ্যাপাচি সম্পর্কে আমি সন্দেহ করি যে পুরো সার্ভারটি মাঝেমধ্যে নিহত এবং পুনরায় চালু করা একক সংযোগের সাথে একটি শিশুকে তার (= সন্তানের / সংযোগের) শুরু থেকে ব্যর্থ হওয়ার চেয়ে ভাল (যেন এটি সম্পূর্ণ নতুন উদাহরণ হিসাবে দেখা যায়) জেভিএম তৈরি করা অন্য উদাহরণটি কিছুক্ষণ চালানোর পরে)। আমার ধারণা, সেরা 'সমাধান' কোনও নির্দিষ্ট প্রসঙ্গে নির্ভর করবে। উদাহরণস্বরূপ, একটি ই-বাণিজ্য পরিষেবা বিবেচনা করে, কখনও কখনও শপিং চার্টের কয়েকটি সংযোগ পুরো পরিষেবাটি ছাড়ার পরিবর্তে এলোমেলোভাবে ব্যর্থ হয়ে ঝুঁকির সাথে, উদাহরণস্বরূপ, একটি চলমান অর্ডার চূড়ান্তকরণে বাধা সৃষ্টি করতে বা (আরও খারাপ) অর্থ প্রদানের প্রক্রিয়া, কেস এর সমস্ত পরিণতি সহ (সম্ভবত নিরীহ, তবে সম্ভবত ক্ষতিকারক - এবং সমস্যাটি দেখা দিলে,

একইভাবে, ওয়ার্কস্টেশনে এমন প্রক্রিয়া যা সর্বাধিক সংস্থান গ্রহণ করে এবং তাই ওওএম হত্যাকারীর পক্ষে প্রথম পছন্দ হতে পারে, এটি কোনও ভিডিও ট্রান্সকোডার, বা একটি রেন্ডারিং সফ্টওয়্যার, সম্ভবত একমাত্র অ্যাপ্লিকেশন হতে পারে ব্যবহারকারী অচ্ছুত হতে চায়। এই বিবেচনাগুলি আমাকে ইঙ্গিত দেয় যে ওওএম কিলার ডিফল্ট নীতিটি খুব আক্রমণাত্মক। এটি একটি "সবচেয়ে খারাপ ফিট" পদ্ধতির ব্যবহার করে যা কোনও কোনওরকম কিছু ফাইল সিস্টেমের মতোই (ওমকে চেষ্টা করে এবং যতটা সম্ভব মেমরি মুক্ত করতে পারে, নিহত সময়ে সাব-প্রসেসিসের সংখ্যা হ্রাস করার জন্য, অল্প সময়ের মধ্যে আরও কোনও হস্তক্ষেপ রোধ করার জন্য, পাশাপাশি একটি fs আরও বেশি ডিস্ক স্পেস বরাদ্দ করতে পারে তবে একটি নির্দিষ্ট ফাইলের জন্য প্রকৃতপক্ষে প্রয়োজন হয়, যদি ফাইলটি বৃদ্ধি পায় এবং এইভাবে কিছুটা হলেও খণ্ডন রোধ করতে পারে তবে আরও কিছু বরাদ্দ রোধ করতে পারে)।

তবে আমি মনে করি যে একটি 'সর্বোত্তম ফিট' পদ্ধতির মতো একটি বিপরীত নীতিই অগ্রাধিকারযোগ্য হতে পারে, তাই নির্দিষ্ট পর্যায়ে সঠিক মেমরির প্রয়োজন মুক্ত করতে এবং 'বড়' প্রক্রিয়াগুলির সাথে বিরক্ত না করা, যা ভাল নষ্ট হতে পারে মেমরি, তবে এটিও নাও হতে পারে এবং কার্নেলটি এটি জানতে পারে না (এইচএমএম, আমি কল্পনা করতে পারি যে পৃষ্ঠার অ্যাক্সেসগুলি গণনা এবং সময় চিহ্নিত করতে পারে যদি কোনও প্রক্রিয়া মেমরি বরাদ্দ করে থাকে তবে এটির কোনও প্রক্রিয়া প্রয়োজন কিনা তা অনুমান করার জন্য মেমোরি নষ্ট করছে বা কেবল প্রচুর ব্যবহার করছে, তবে মেমরি এবং সিপিইউ নিবিড় অ্যাপ্লিকেশন থেকে নষ্ট হওয়া স্মৃতিকে আলাদা করার জন্য অ্যাক্সেস বিলম্বগুলি সিপিইউ চক্রের উপরে ওজন করা উচিত , তবে, সম্ভাব্যভাবে সঠিক না হলেও, এই ধরনের একটি হিউরিস্টিকের অত্যধিক ওভারহেড থাকতে পারে)।

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

যাইহোক, আমি মনে করি যে ব্যবহারকারীকে কী করবেন তার নিজের সিদ্ধান্ত নিতে সক্ষম করা উচিত। একটি ডেস্কটপ (= ইন্টারেক্টিভ) সিস্টেমে এটি করা তুলনামূলকভাবে সহজ হওয়া উচিত, তবে ব্যবহারকারীরা যে কোনও অ্যাপ্লিকেশন বন্ধ করতে বলার জন্য যথেষ্ট সংস্থান সংরক্ষিত থাকে (তবে কয়েকটি ট্যাব বন্ধ করাও যথেষ্ট হতে পারে) এবং তার পছন্দটিকে পরিচালনা করতে পারে (একটি বিকল্প হতে পারে অতিরিক্ত স্থান অদলবদল করে, যদি পর্যাপ্ত জায়গা থাকে) তৈরি করে। পরিষেবাদির জন্য (এবং সাধারণভাবে), আমি আরও দুটি সম্ভাব্য বর্ধনগুলি বিবেচনা করব: একটি OOM হত্যাকারী হস্তক্ষেপ লগ করা হয়, পাশাপাশি ব্যর্থতাগুলি সহজেই ডিবাগ করা যায় এমন পদ্ধতিতে ব্যর্থতা শুরু / কাঁটাচামচ করা প্রক্রিয়াগুলি (উদাহরণস্বরূপ, একটি API এ পারে নতুন প্রক্রিয়া তৈরি বা জালিয়াতি প্রদান প্রক্রিয়াটি অবহিত করুন - সুতরাং, অ্যাপাচি-এর মতো একটি সার্ভার, সঠিক প্যাচ সহ, কিছু ত্রুটির জন্য আরও ভাল লগিং সরবরাহ করতে পারে); ওভারকমিট / ওমকে প্রচেষ্টায় থাকাকালীন থেকে এটি নির্বিঘ্নে করা যেতে পারে; দ্বিতীয় স্থানে, তবে গুরুত্বের জন্য নয়, ওমকে অ্যালগরিদমকে সূক্ষ্ম করে তোলার জন্য একটি প্রক্রিয়া প্রতিষ্ঠা করা যেতে পারে - আমি জানি যে প্রক্রিয়া ভিত্তিতে কোনও প্রক্রিয়া সম্পর্কে একটি নির্দিষ্ট নীতি নির্ধারণ করা সম্ভব, তবে আমি লক্ষ্য রাখতে চাই প্রাসঙ্গিক প্রক্রিয়াগুলি চিহ্নিত করতে এবং তাদেরকে নির্দিষ্ট পরিমাণের গুরুত্ব (তালিকাভুক্ত বৈশিষ্ট্য অনুসারে) দেওয়ার জন্য অ্যাপ্লিকেশন নামের (বা আইডি) এক বা একাধিক তালিকার উপর ভিত্তি করে 'কেন্দ্রীভূত' কনফিগারেশন প্রক্রিয়া; এই জাতীয় প্রক্রিয়াটিও (বা কমপক্ষে পারে) স্তরযুক্ত হওয়া উচিত, যাতে শীর্ষ স্তরের ব্যবহারকারী-সংজ্ঞায়িত তালিকা, সিস্টেম- (বিতরণ) সংজ্ঞায়িত তালিকা এবং (নীচের স্তরের) অ্যাপ্লিকেশন-সংজ্ঞায়িত এন্ট্রি থাকতে পারে উদাহরণস্বরূপ, কোনও ডি ফাইল ম্যানেজার OOMK কে নিরাপদে কোনও ঘটনা হত্যার নির্দেশ দিতে পারে,

মরওভার, রান-সময়ে অ্যাপ্লিকেশনগুলিকে তাদের 'গুরুত্ব' স্তর বাড়াতে বা কমিয়ে আনার অনুমতি দেওয়ার জন্য একটি এপিআই সরবরাহ করা যেতে পারে (মেমরি পরিচালনার উদ্দেশ্যে এবং নির্ধারিত নির্বাহের অগ্রাধিকারের সাথে), যাতে উদাহরণস্বরূপ, একটি ওয়ার্ড প্রসেসর শুরু হতে পারে একটি নিম্ন 'গুরুত্ব' তবে এটি উত্থাপন করুন কারণ কোনও ফাইলটিতে ফ্লাশ করার আগে কিছু তথ্য ধরে রাখা হয়, বা একটি রাইটিং অপারেশন করা হচ্ছে, এবং কম গুরুত্ব আবারও যখন এই ধরণের অপারেশন শেষ হয় (সমানভাবে, কোনও ফাইল ম্যানেজার স্তরটি পরিবর্তন করতে পারে যখন এটি ঠিক থেকে চলে যায়) ডেটা এবং বিপরীতে মোকাবেলা করার জন্য ফাইল লিখন, পৃথক প্রক্রিয়াগুলি ব্যবহার না করে এবং অ্যাপাচি বিভিন্ন বাচ্চাদের বিভিন্ন স্তরের গুরুত্ব দিতে পারে, বা সিসাদমিন দ্বারা সিদ্ধান্ত নেওয়া এবং অ্যাপাচি-এর মাধ্যমে বা অন্য কোনও সার্ভারের মাধ্যমে উন্মুক্ত কিছু নীতি অনুসারে একটি শিশু রাষ্ট্র পরিবর্তন করতে পারে - সেটিংস). অবশ্যই, যেমন একটি এপিআই হতে পারে এবং অপব্যবহার / অপব্যবহার করা যেতে পারে, তবে আমি মনে করি যে সিস্টেমে কী চলছে (এবং মেমোরি খরচ / সৃষ্টির সময় বা একই রকমের ক্ষেত্র) সম্পর্কিত কোনও প্রাসঙ্গিক তথ্য ছাড়াই কার্নেল নির্বিচারে মেমরি মুক্ত করার প্রক্রিয়াটির তুলনায় এটি একটি সামান্য উদ্বেগ 'আমার পক্ষে যথেষ্ট প্রাসঙ্গিক বা' বৈধকরণ 'নয় - কেবলমাত্র ব্যবহারকারী, প্রশাসক এবং প্রোগ্রাম লেখকরা কোনও কারণে কোনও প্রক্রিয়াটি' এখনও প্রয়োজন 'কিনা, কারণ কী, এবং / অথবা যদি অ্যাপ্লিকেশনটি রাষ্ট্রের নেতৃত্বাধীন হয় তবে তা সত্যই নির্ধারণ করতে পারে ডেটা ক্ষতি বা অন্যান্য ক্ষতি / ঝামেলা যদি নিহত হয়; যাইহোক, কিছু অনুমান করা যায়নি, উদাহরণস্বরূপ কোনও প্রক্রিয়া দ্বারা অর্জিত নির্দিষ্ট ধরণের (ফাইল বর্ণনাকারী, নেটওয়ার্ক সকেট, ইত্যাদি) সংস্থানগুলি অনুসন্ধান করা এবং অপেক্ষমান ক্রিয়াকলাপগুলি বলতে পারে যে কোনও প্রক্রিয়া উচ্চতর 'অবস্থায়' থাকা উচিত কিনা? এক সেট,

অথবা, মাত্রাতিরিক্ত কমিটিকে এড়িয়ে চলুন এবং কার্নেলকে কর্নেল যা করতে হবে ঠিক তা করতে দিন, সংস্থানগুলি বরাদ্দ করুন (তবে ওওএম হত্যাকারীর মতো নির্বিচারে তাদের উদ্ধার করবেন না), সময় নির্ধারণের প্রক্রিয়া, অনাহার এবং অচলাবস্থা রোধ করে (বা তাদের থেকে উদ্ধার), সম্পূর্ণ প্রিমিপশন নিশ্চিত করে এবং মেমরি স্পেস পৃথককরণ, এবং আরও ...

আমি ওভারকমিট পদ্ধতির বিষয়ে আরও কিছু শব্দ ব্যয় করব। অন্যান্য আলোচনা থেকে আমি ধারণাটি তৈরি করেছি যে ওভার কমিট সম্পর্কে অন্যতম প্রধান উদ্বেগ (এটি চাওয়ার কারণ হিসাবে এবং সম্ভাব্য সমস্যার উত্স হিসাবে উভয়) কাঁটাচামচ নিয়ে গঠিত: সত্যি বলতে কী, আমি ঠিক জানি না যে অনুলিপি- অন-রাইটিং কৌশলটি কার্যকর করা হয়েছে, তবে আমি মনে করি যে কোনও আক্রমণাত্মক (বা আশাবাদী) নীতিটি অদলবদলযুক্ত স্থানীয়তা কৌশল দ্বারা প্রশমিত হতে পারে। এটি হ'ল, একটি কাঁটাচামচ প্রক্রিয়া কোড পৃষ্ঠা এবং সময়সূচী কাঠামোগুলি ক্লোনিং (এবং সামঞ্জস্য করার) পরিবর্তে প্রকৃত লেখার আগে আরও কয়েকটি তথ্য পৃষ্ঠাগুলি অনুলিপি করা যেতে পারে, সেই পৃষ্ঠাগুলির মধ্যে প্যারেন্ট প্রসেসটি আরও ঘন ঘন লেখার জন্য অ্যাক্সেস করেছে (এটি, লেখার ক্রিয়াকলাপের জন্য একটি কাউন্টার ব্যবহার করে)।

অবশ্যই, আইএমএইচও।

Comments

"রানওয়ে অ্যাপ্লিকেশনগুলিকে তাদের 'গুরুত্ব' স্তর বাড়াতে বা কমিয়ে আনতে যাতে মরিওভার, একটি এপিআই সরবরাহ করা যেতে পারে" গুরুত্ব হ'ল /proc/$PID/oom_adj।

— vi।

জেভিএম সম্পর্কিত, এমন একটি গ্যাচা রয়েছে যা আপনাকে কিছু ক্ষেত্রে মেমরির ওভারকমিট চায়: যদি আপনি আপনার আসল জেভিএম থেকে অন্য কোনও জেভিএম তৈরি করতে চান তবে এটি কাঁটাচামচ () কল করবে। একটি কাঁটাচামচ কলটি প্রকৃত প্রক্রিয়াটি শুরু না হওয়া অবধি মূল প্রক্রিয়া (প্রথম) হিসাবে যতটা মেমরি বরাদ্দ করবে। সুতরাং বলুন যে আপনার কাছে একটি 4 জিবি জেভিএম রয়েছে এবং এটি থেকে একটি নতুন 512 কেবি জেভিএম তৈরি করতে চান, আপনার যদি ওভার কমিট না করে থাকে, তবে এটি করার জন্য আপনার 8 গিগাবাইট মেমরির প্রয়োজন হবে ...

— alci

@Vi। এখন মনে হচ্ছে/proc/$PID/oom_score_adj

— erm3nda

Answer 4

যদি আপনার স্মৃতি প্রসেসগুলি দ্বারা পরিসীমা ব্যবহার করে এমন পরিমাণে ব্যবহার করা হয় যা সম্ভবত সিস্টেমের স্থায়িত্বকে হুমকির সম্মুখীন করতে পারে, তবে ওওএম হত্যাকারী ছবিতে আসে। বাকী প্রক্রিয়াটির সুষ্ঠুভাবে পরিচালনার জন্য পর্যাপ্ত মেমরি মুক্ত না হওয়া পর্যন্ত প্রক্রিয়াগুলি মেরে ফেলা ওওম কিলারের কাজ। ওওম কিলারকে হত্যা করার জন্য "সেরা" প্রক্রিয়াটি নির্বাচন করতে হবে। "সেরা" এখানে সেই প্রক্রিয়াটিকে বোঝায় যা হত্যার পরে সর্বাধিক স্মৃতি মুক্ত করবে এবং এটি সিস্টেমের পক্ষেও গুরুত্বপূর্ণ। প্রাথমিক লক্ষ্যটি হ'ল ন্যূনতম সংখ্যক প্রক্রিয়াগুলিকে হত্যা করা যা ক্ষতিগুলি হ্রাস করে এবং একই সাথে মেমরির মুক্তির পরিমাণ সর্বাধিক করে তোলে। এটির সুবিধার্থে কার্নেল প্রতিটি প্রসেসের জন্য oom_score বজায় রাখে। আপনি পিড ডিরেক্টরিতে / proc ফাইল সিস্টেমের প্রতিটি প্রক্রিয়ার oom_score দেখতে পাবেন

# cat /proc/10292/oom_score

যে কোনও প্রক্রিয়ার ওম_স্কোরের মান তত বেশি হ'ল স্মৃতি বহির্ভূত পরিস্থিতিতে ওওম কিলারের হাতে মারা যাওয়ার সম্ভাবনা তত বেশি।

ক্রেডিট: - লিনাক্স কার্নেল OOM হত্যাকারী শুরু করছে