डिफ़ॉल्ट रूप से लिनक्स OOM हत्यारा बंद करें?


37

लिनक्स पर OOM किलर हर बार विभिन्न अनुप्रयोगों के साथ कहर बरपाता है, और ऐसा प्रतीत होता है कि वास्तव में इसे सुधारने के लिए कर्नेल विकास पक्ष पर बहुत कुछ नहीं किया गया है। क्या यह बेहतर नहीं होगा, जब एक नया सर्वर स्थापित करते समय , मेमोरी ओवरकॉमिटिंग पर डिफ़ॉल्ट को उलटने के लिए एक सर्वोत्तम अभ्यास के रूप में, अर्थात, इसे बंद कर दें ( vm.overcommit_memory=2) जब तक आप यह नहीं जानते कि आप इसे अपने विशेष उपयोग के लिए चाहते हैं? और उन मामलों का उपयोग क्या होगा जहां आप जानते हैं कि आप ओवरकॉमिटिंग चाहते हैं?

एक बोनस के रूप में, चूंकि अंतरिक्ष vm.overcommit_memory=2पर निर्भर करता है vm.overcommit_ratioऔर स्वैप स्थान के मामले में व्यवहार करता है, बाद के दो को आकार देने के लिए अंगूठे का एक अच्छा नियम क्या होगा ताकि यह पूरा सेटअप यथोचित काम करता रहे?

जवाबों:


63

एक दिलचस्प सादृश्य ( http://lwn.net/Articles/104179/ ) से:

एक विमान कंपनी ने पता लगाया कि बोर्ड पर कम ईंधन के साथ अपने विमानों को उड़ाना सस्ता था। विमान हल्का होगा और ईंधन का कम इस्तेमाल करेगा और पैसे बचेंगे। हालांकि दुर्लभ अवसरों पर ईंधन की मात्रा अपर्याप्त थी, और विमान दुर्घटनाग्रस्त हो जाता। इस समस्या को कंपनी के इंजीनियरों द्वारा एक विशेष OOF (आउट-ऑफ-फ्यूल) तंत्र के विकास द्वारा हल किया गया था। आपातकालीन मामलों में एक यात्री को चुना गया और उसे विमान से बाहर फेंक दिया गया। (जब आवश्यक हो, प्रक्रिया दोहराई गई थी।) सिद्धांत का एक बड़ा शरीर विकसित किया गया था और कई प्रकाशनों को पीड़ित को ठीक से चुनने की समस्या के लिए समर्पित किया गया था। क्या पीड़ित को यादृच्छिक पर चुना जाना चाहिए? या सबसे भारी व्यक्ति को चुनना चाहिए? या सबसे पुराना? क्या यात्रियों को बेदखल न होने के लिए भुगतान करना चाहिए, ताकि पीड़ित बोर्ड पर सबसे गरीब हो? और अगर उदाहरण के लिए सबसे भारी व्यक्ति को चुना गया था, तो क्या पायलट के मामले में कोई विशेष अपवाद होना चाहिए? क्या प्रथम श्रेणी के यात्रियों को छूट दी जानी चाहिए? अब जब ओओएफ तंत्र मौजूद था, तो यह हर अब और फिर सक्रिय हो जाएगा, और ईंधन की कमी नहीं होने पर भी यात्रियों को बेदखल कर देगा। इंजीनियर अभी भी ठीक से अध्ययन कर रहे हैं कि यह खराबी कैसे होती है।


11
मुझे बहुत अच्छा लगा, इसे खोदने के लिए धन्यवाद।
निक बोल्टन

32

यदि आपके सिस्टम पर ओवरलोडेड है तो OOM किलर केवल कहर बरपाता है। इसे पर्याप्त स्वैप दें, और ऐसे एप्लिकेशन न चलाएं जो अचानक भारी मात्रा में रैम खाने का निर्णय लेते हैं, और आपको कोई समस्या नहीं होगी।

विशेष रूप से अपने सवालों के जवाब देने के लिए:

  • मुझे नहीं लगता कि सामान्य मामले में ओवरकमिट को बंद करना एक अच्छा विचार है; बहुत कम एप्लिकेशन brk(2) (और इसका उपयोग करने वाले रैपर, जैसे malloc(3)) किसी त्रुटि को ठीक से निपटने के लिए लिखे जाते हैं । जब मैंने अपनी पिछली नौकरी में यह प्रयोग किया था, तो यह एक परेशानी के रूप में समझा गया था कि आउट-ऑफ-मेमोरी त्रुटियों से निपटने में सक्षम सब कुछ प्राप्त करने की तुलना में यह एक ओओएम के परिणामों से निपटने के लिए था (जो, हमारे मामले में, कभी-कभार सेवा को फिर से शुरू करने की तुलना में कहीं अधिक खराब होता था अगर एक OOM ने किया - हमें एक पूरे क्लस्टर को रिबूट करना पड़ा, क्योंकि जीएफएस मल की एक स्टीमिंग ढेर है)।
  • आप किसी भी प्रक्रिया के लिए overcommitting चाहते हैं जो स्मृति को overcommits करता है। यहां दो सबसे आम अपराधी अपाचे और जेवीएम हैं, लेकिन बहुत सारे ऐप इसे कुछ अधिक या कम डिग्री तक करते हैं। उन्हें लगता है कि उन्हें भविष्य में किसी समय बहुत अधिक स्मृति की आवश्यकता हो सकती है, इसलिए वे एक बड़ा हिस्सा हड़प लेते हैं। ओवर-कॉम्पीट-इनेबल्ड सिस्टम पर, कर्नेल "meh, जो भी हो, मुझे परेशान करता है जब आप वास्तव में उन पृष्ठों पर लिखना चाहते हैं" और कुछ भी बुरा नहीं होता है। एक ओवरकमिट-ऑफ सिस्टम पर, कर्नेल कहते हैं, "नहीं, आपके पास इतनी मेमोरी नहीं हो सकती है, यदि आप ऐसा करने के लिए भविष्य में किसी बिंदु पर मुझे लिखने के लिए करते हैं तो मैं आपके लिए कोई स्मृति नहीं हूं!" और आवंटन विफल रहता है। चूंकि कुछ भी नहींबाहर "ओह, ठीक है, क्या मेरे पास प्रक्रिया डेटा खंड की यह छोटी मात्रा हो सकती है?", फिर या तो (ए) आउट-ऑफ-मेमोरी त्रुटि के साथ क्विट करता है, या (बी) से रिटर्न कोड की जांच नहीं करता है मॉलॉक, सोचता है कि जाना ठीक है, और एक अवैध मेमोरी लोकेशन पर लिखता है, जिससे सेगफॉल्ट होता है। शुक्र है, JVM यह सब स्टार्टअप पर प्रचार करता है (इसलिए आपका JVM या तो शुरू होता है या तुरंत मर जाता है, जिसे आप आमतौर पर देखते हैं), लेकिन Apache क्या यह प्रत्येक नए बच्चे के साथ कायरता भरा सामान है, जो उत्पादन में रोमांचक प्रभाव डाल सकता है (unpproducible "कनेक्शन नहीं संभाल रहा है" "उत्साह के प्रकार)।
  • मैं अपने overcommit_ratio को 50% के डिफ़ॉल्ट से अधिक नहीं सेट करना चाहूंगा। फिर से, मेरे परीक्षण से, हालांकि इसे 80 या 90 के आसपास सेट करना एक शांत विचार की तरह लग सकता है, कर्नेल को असुविधाजनक समय पर स्मृति की बड़ी मात्रा की आवश्यकता होती है, और एक उच्च ओवरकमिटी अनुपात के साथ एक पूरी तरह से भरी हुई प्रणाली की अपर्याप्त स्पेयर मेमोरी होने की संभावना है जब कर्नेल को इसकी आवश्यकता होती है (डर, महामारी और ऊप्स के कारण)। इसलिए ओवरकॉमिट के साथ खेलना एक नई, और भी मजेदार विफलता मोड का परिचय देता है - जब आप मेमोरी से बाहर निकलते हैं, तो जो भी प्रक्रिया OOMed हो गई थी, उसे फिर से शुरू करने के बजाय, अब आपकी मशीन क्रैश हो जाती है, जिससे मशीन पर सब कुछ खत्म हो जाता है। बहुत बढ़िया!
  • एक ओवर-कॉम्पीट-फ्री सिस्टम में स्वैप स्पेस इस बात पर निर्भर है कि आपके एप्लिकेशन की कितनी जरूरी है लेकिन अप्रयुक्त मेमोरी, एक स्वस्थ सुरक्षा मार्जिन। एक विशिष्ट मामले में जो आवश्यक है उसे काम करते हुए पाठक के लिए एक अभ्यास के रूप में छोड़ दिया जाता है।

मूल रूप से, मेरा अनुभव यह है कि ओवरकमिट को बंद करना एक अच्छा प्रयोग है जो शायद ही कभी अभ्यास में काम करता है जैसा कि सिद्धांत में लगता है। यह अच्छी तरह से कर्नेल में अन्य ट्यूनबल्स के साथ मेरे अनुभवों से मेल खाती है - लिनक्स कर्नेल डेवलपर्स लगभग हमेशा आपसे ज्यादा स्मार्ट होते हैं, और डिफॉल्ट बड़े, विशाल मामलों के लिए सबसे अच्छा काम करते हैं। उन्हें अकेला छोड़ दें, और इसके बजाय यह जानें कि किस प्रक्रिया में रिसाव है और इसे ठीक करें।


2
मैं नहीं चाहता कि मेरी बैकअप प्रक्रिया को मार दिया जाए क्योंकि कोई DoS-ing मेरा वेब सर्वर है। अपवाद ठीक हैं लेकिन डिफ़ॉल्ट सुरक्षा और स्थिरता होना चाहिए। OOM जैसे अनुकूलन को मैन्युअल रूप से IMHO चालू किया जाना चाहिए। यह कोडिंग की तरह है, आप सफाई से कोड करते हैं, और फिर अनुकूलन करते हैं। ओवर-कमिट एक अच्छी सुविधा है, लेकिन डिफ़ॉल्ट नहीं होना चाहिए।
अकी

1
यदि आप नहीं चाहते हैं कि आपकी बैकअप प्रक्रिया समाप्त हो जाए, क्योंकि कोई व्यक्ति आपके वेब सर्वर का आईओएस है, तो अपने वेबसर्वर को इस तरह से कॉन्फ़िगर न करें, जिससे DoS सिस्टम पर मौजूद संसाधनों से अभिभूत हो सके।
Womble

मेरे पास 8GB रैम है और सिर्फ फ़ायरफ़ॉक्स और एक वर्चुअल मशीन चलाने से कभी-कभी OOM हत्यारा VM को मार देता है। अवास्तविक इंजन 4 को संकलित करते हुए, प्रत्येक क्लैंग आह्वान में 1 ~ 1.5GB मेमोरी लगती है और फिर से, OOM किलर हर एक को मारता है। अब मैं आम तौर पर उस के साथ ठीक हूँ, OOM हत्यारे के बिना वे शायद वैसे भी सीगफॉल्ट कर सकते थे। यह सिर्फ इतना है कि हर बार ओओएम हत्यारा एक प्रक्रिया को मारना चाहता है, मेरी प्रणाली 10 मिनट के लिए जमा हो जाती है इससे पहले कि वास्तव में खराब प्रक्रिया को मार दिया जाए। बग शायद? सबसे अधिक संभावना। क्या मुझे यह चाहिए? निश्चित रूप से नहीं। और यही कारण है कि कोई OOM हत्यारे को निष्क्रिय करना चाहता है।
शहबाज

1
यदि आप वह सब कर रहे हैं जिस बॉक्स पर आपको अधिक RAM की आवश्यकता होती है, और ओवरकमिट को अक्षम करना केवल इसे बदतर बना देगा।
1930 में बेन लुत्जेंस

6

हम्म, मैं पूरी तरह से overcommit और OOM हत्यारे के पक्ष में तर्क से आश्वस्त नहीं हूँ ... जब womble लिखते हैं,

"OOM किलर तभी कहर बरपाता है, जब आपने अपने सिस्टम को ओवरलोड कर दिया हो। इसे पर्याप्त स्वैप दें, और ऐसे एप्लिकेशन न चलाएं जो अचानक भारी मात्रा में रैम खाने का निर्णय लेते हैं, और आपको कोई समस्या नहीं होगी।"

वह एक ऐसे पर्यावरण परिदृश्य का वर्णन करने के बारे में है, जहां ओवरकमिट और ओओएम किलर को लागू नहीं किया जाता है, या 'वास्तव में' अधिनियम नहीं है (यदि सभी अनुप्रयोगों को आवश्यकतानुसार मेमोरी आवंटित की जाती है, और पर्याप्त वर्चुअल मेमोरी आवंटित की जानी थी, मेमोरी राइट्स बिना मेमोरी आवंटन का बारीकी से अनुसरण करेगा। त्रुटियों, तो हम वास्तव में एक overcommited प्रणाली के बारे में बात नहीं कर सकता, भले ही एक overcommit रणनीति सक्षम थे)। यह एक अंतर्निहित प्रवेश के बारे में है कि जब उनके हस्तक्षेप की आवश्यकता नहीं होती है, तो ओवरकमेट और ओओएम हत्यारा सबसे अच्छा काम करता है, जिसे किसी तरह इस रणनीति के अधिकांश समर्थकों द्वारा साझा किया जाता है, जहां तक ​​मैं बता सकता हूं (और मैं मानता हूं कि मैं बहुत कुछ नहीं बता सकता ...)। Morover, विशिष्ट व्यवहार के साथ अनुप्रयोगों का जिक्र करते हुए जब मेमोरी का प्रचार करते हुए मुझे लगता है कि डिफॉल्ट होने के बजाय वितरण स्तर पर एक विशिष्ट हैंडलिंग को ट्यून किया जा सकता है,

JVM किस चिंता के लिए है, ठीक है, यह एक आभासी मशीन है, कुछ हद तक इसे स्टार्टअप पर जितने भी संसाधन चाहिए, उसे आवंटित करने की आवश्यकता है, इसलिए यह अपने अनुप्रयोगों के लिए अपना 'नकली' वातावरण बना सकता है, और अपने उपलब्ध संसाधन को मेजबान से अलग रख सकता है। पर्यावरण, जहाँ तक संभव हो। इस प्रकार, 'बाहरी' OOM स्थिति (ओवरकॉमिट / OOM किलर / जो भी हो) के परिणामस्वरूप थोड़ी देर के बाद, या इसके बाद भी ऐसी स्थिति के लिए पीड़ित होने के बजाय स्टार्टअप पर विफल होना बेहतर हो सकता है। आंतरिक OOM हैंडलिंग रणनीतियों (सामान्य तौर पर, एक वीएम को शुरुआत से ही कोई आवश्यक संसाधन प्राप्त करने चाहिए और मेजबान सिस्टम को अंत तक उन्हें 'अनदेखा' करना चाहिए, उसी तरह किसी भी भौतिक ग्राफिक्स के साथ साझा की गई राम की राशि कभी नहीं होती है - और नहीं हो सकती है - ओएस द्वारा छुआ)।

अपाचे के बारे में, मुझे संदेह है कि पूरे सर्वर को कभी-कभी मार दिया जाता है और फिर से चालू किया जाता है, एक एकल कनेक्शन के साथ-साथ एकल बच्चे को देने से बेहतर है, इसके (= बच्चे के / कनेक्शन की) शुरुआत से असफल (जैसे कि यह एक नया उदाहरण था) एक और उदाहरण के चलने के बाद निर्मित JVM)। मुझे लगता है कि सबसे अच्छा 'समाधान' एक विशिष्ट संदर्भ पर निर्भर हो सकता है। उदाहरण के लिए, एक ई-कॉमर्स सेवा पर विचार करना, कभी-कभी बेहतर हो सकता है, कभी-कभी, शॉपिंग चार्ट के कुछ कनेक्शन पूरी सेवा को खोने के बजाय बेतरतीब ढंग से विफल हो जाते हैं, उदाहरण के लिए, चल रहे ऑर्डर को अंतिम रूप देने के लिए, या (शायद बदतर) एक भुगतान प्रक्रिया, मामले के सभी परिणामों के साथ (शायद हानिरहित, लेकिन शायद हार्मफुल हो - और निश्चित रूप से, जब एक संभव हो,

उसी तरह, एक कार्य केंद्र पर प्रक्रिया जो सबसे अधिक संसाधनों का उपभोग करती है, और इसलिए ओओएम किलर के लिए पहली पसंद होने के लिए एक मेमोरी इंटेंसिव एप्लिकेशन हो सकता है, जैसे कि वीडियो ट्रांसकोडर, या एक रेंडरिंग सॉफ्टवेयर, केवल आवेदन की संभावना है। उपयोगकर्ता अछूता रहना चाहता है। यह विचार मुझे संकेत देता है कि OOM किलर डिफ़ॉल्ट नीति बहुत आक्रामक है। यह एक "सबसे खराब फिट" दृष्टिकोण का उपयोग करता है जो किसी न किसी फाइलसिस्टम के समान होता है (OOMK कोशिश करता है और जितनी अधिक हो सके उतनी मेमोरी मुक्त करता है, जबकि कम समय में किसी भी आगे के हस्तक्षेप को रोकने के लिए, मारे गए उपप्रकारों की संख्या को कम कर सकता है, जैसे कि साथ ही एक fs अधिक डिस्क स्थान आवंटित कर सकता है, तो वास्तव में एक निश्चित फ़ाइल के लिए आवश्यक है, किसी भी अन्य आवंटन को रोकने के लिए यदि फ़ाइल बढ़ी और इस प्रकार कुछ हद तक विखंडन को रोकती है)।

हालांकि, मुझे लगता है कि एक विपरीत नीति, जैसे कि 'सबसे अच्छा फिट' दृष्टिकोण, बेहतर हो सकता है, इसलिए एक निश्चित बिंदु पर आवश्यक सटीक मेमोरी को मुक्त करने के लिए, और 'बड़ी' प्रक्रियाओं से परेशान नहीं होना चाहिए, जो अच्छी तरह से बर्बाद हो सकता है। स्मृति, लेकिन यह भी नहीं पता हो सकता है, और कर्नेल यह नहीं जान सकता है कि (हम्म, मैं कल्पना कर सकता हूं कि पेज एक्सेस का पता लगाना गिनती और समय को इंगित कर सकता है यदि कोई प्रक्रिया मेमोरी आवंटित कर रही है तो उसे किसी और की आवश्यकता नहीं है, इसलिए यह अनुमान लगाने के लिए कि क्या एक प्रक्रिया है स्मृति को बर्बाद कर रहा है या सिर्फ एक बहुत का उपयोग कर रहा है, लेकिन एक्सेस देरी को एक मेमोरी और सीपीयू गहन अनुप्रयोग से बर्बाद होने वाली मेमोरी को अलग करने के लिए सीपीयू चक्रों पर भारित किया जाना चाहिए , लेकिन, जबकि संभावित रूप से गलत है, इस तरह के उत्तराधिकार में अत्यधिक ओवरहेड हो सकता है)।

इसके अलावा, यह सच नहीं हो सकता है कि कम संभव प्रक्रियाओं को मारना हमेशा एक अच्छा विकल्प है। उदाहरण के लिए, डेस्कटॉप वातावरण पर (एक नेटटॉप या सीमित संसाधनों के साथ एक नेटबुक के बारे में सोचें, नमूने के लिए) एक उपयोगकर्ता कई टैब के साथ एक ब्राउज़र चला रहा हो सकता है (इस प्रकार, मेमोरी की खपत - मान लें कि यह ओओएमके के लिए पहला विकल्प है) , प्लस कुछ अन्य एप्लिकेशन (गैर सहेजे गए डेटा के साथ एक शब्द प्रोसेसर, एक मेल क्लाइंट, एक पीडीएफ रीडर, एक मीडिया प्लेयर, ...), प्लस कुछ (सिस्टम) डेमॉन, और कुछ फ़ाइल प्रबंधक उदाहरण। अब, एक OOM त्रुटि होती है, और OOMK ब्राउज़र को मारने का विकल्प चुनता है, जबकि उपयोगकर्ता नेट पर कुछ 'महत्वपूर्ण' समझा जाता है ... उपयोगकर्ता निराश होगा। दूसरी ओर, कुछ फ़ाइल प्रबंधक को बंद करना '

वैसे भी, मुझे लगता है कि उपयोगकर्ता को स्वयं निर्णय लेने में सक्षम होना चाहिए कि क्या करना है। एक डेस्कटॉप (= इंटरएक्टिव) सिस्टम में, जो कि अपेक्षाकृत काफी आसान होना चाहिए, बशर्ते पर्याप्त संसाधन उपयोगकर्ता को किसी भी एप्लिकेशन को बंद करने के लिए कहने के लिए आरक्षित हों (लेकिन कुछ टैब को बंद करना भी पर्याप्त हो सकता है) और उसकी पसंद को संभालना (एक विकल्प हो सकता है) एक अतिरिक्त स्वैप फ़ाइल बनाने से युक्त है, अगर पर्याप्त जगह है)। सेवाओं के लिए (और सामान्य तौर पर), मैं दो और संभावित संवर्द्धन पर भी विचार करूँगा: एक OOM किलर इंटरवेन्ट्स को लॉग कर रहा है, साथ ही साथ प्रक्रियाएँ शुरू / असफलताओं को इस तरह से विफल किया जा सकता है कि विफलता को आसानी से डीबग किया जा सके (उदाहरण के लिए, एक एपीआई नई प्रक्रिया निर्माण या जारी करने की प्रक्रिया को सूचित करें - इस प्रकार, अपाचे जैसा सर्वर, उचित पैच के साथ, कुछ त्रुटियों के लिए एक बेहतर लॉगिंग प्रदान कर सकता है); यह ओवरकम / OOMK के प्रयास में होने से अनिर्णय से किया जा सकता है; दूसरे स्थान पर, लेकिन महत्व के लिए नहीं, OOMK एल्गोरिथ्म को ठीक करने के लिए एक तंत्र स्थापित किया जा सकता है - मुझे पता है कि यह संभव है, कुछ हद तक, प्रक्रिया के आधार पर एक प्रक्रिया पर एक विशिष्ट नीति को परिभाषित करने के लिए, लेकिन मैं एक लक्ष्य बनाऊंगा 'केंद्रीकृत' विन्यास तंत्र, प्रासंगिक प्रक्रियाओं की पहचान करने और उन्हें एक निश्चित डिग्री (महत्व के अनुसार सूचीबद्ध विशेषताओं) देने के लिए एक या एक से अधिक सूचियों के नाम (या आईडी) के आधार पर; इस तरह के एक तंत्र को (या कम से कम) भी स्तरित किया जाना चाहिए, ताकि एक शीर्ष-स्तरीय उपयोगकर्ता-परिभाषित सूची हो, एक प्रणाली- (वितरण-) परिभाषित सूची, और (निचले-स्तर) अनुप्रयोग-परिभाषित प्रविष्टियां (इसलिए उदाहरण के लिए, एक डीई फ़ाइल प्रबंधक किसी भी उदाहरण को सुरक्षित रूप से मारने के लिए ओओएमके को निर्देश दे सकता है,

Morover, एप्लिकेशन को रन-टाइम (स्मृति प्रबंधन उद्देश्यों के संबंध में और निष्पादन प्राथमिकता की परवाह किए बिना) को बढ़ाने या कम करने के लिए एक एपीआई प्रदान किया जा सकता है, ताकि, उदाहरण के लिए, एक वर्ड प्रोसेसर के साथ शुरू हो सके कम 'महत्व' लेकिन इसे बढ़ाएं क्योंकि किसी फ़ाइल में फ्लश करने से पहले कुछ डेटा को होल्ड किया जाता है, या एक लिखित ऑपरेशन किया जा रहा है, और कम महत्व फिर से एक बार ऐसे ऑपरेशन समाप्त हो जाता है (अनुरूपता से, एक फ़ाइल प्रबंधक तब बदल सकता है जब यह बस से पारित हो गया हो डेटा और वाइसवेरा से निपटने के लिए फ़ाइलों को अलग-अलग प्रक्रियाओं का उपयोग करने के बजाय, और अपाचे अलग-अलग बच्चों को अलग-अलग स्तर का महत्व दे सकते हैं, या sysadmins द्वारा तय की गई कुछ नीति के अनुसार बाल अवस्था को बदल सकते हैं और अपाचे के माध्यम से उजागर कर सकते हैं - या किसी भी तरह का सर्वर - सेटिंग्स)। बेशक, इस तरह के एपीआई का दुरुपयोग और दुरुपयोग किया जा सकता है, लेकिन मुझे लगता है कि कर्नेल की तुलना में एक मामूली चिंता है कि सिस्टम पर क्या हो रहा है और (या मेमोरी खपत / निर्माण का समय या समान रूप से) किसी भी प्रासंगिक जानकारी के बिना मेमोरी को फ्रीज करने के लिए प्रक्रियाओं को मार सकता है। मेरे लिए 'पर्याप्त रूप से प्रासंगिक या' मान्य करना) - केवल उपयोगकर्ता, व्यवस्थापक और कार्यक्रम लेखक ही यह निर्धारित कर सकते हैं कि क्या किसी कारण के लिए एक प्रक्रिया की 'फिर भी जरूरत' है, क्या कारण है, और / या यदि आवेदन राज्य में अग्रणी है मारे जाने पर नुकसान या अन्य नुकसान / परेशानियों के लिए; हालाँकि, कुछ धारणा अभी तक की जा सकती है, उदाहरण के लिए एक प्रक्रिया द्वारा अधिग्रहीत एक निश्चित प्रकार के संसाधनों की तलाश (फाइल डिस्क्रिप्टर, नेटवर्क सॉकेट्स इत्यादि) और लंबित संचालन के साथ यह बता सकता है कि क्या प्रक्रिया एक उच्चतर 'राज्य' की तुलना में होनी चाहिए एक सेट,

या, बस overcommitting से बचें और कर्नेल को बस वही करें जो एक कर्नेल को करना चाहिए, संसाधनों को आवंटित करना (लेकिन OOM किलर के रूप में उन्हें मनमाने ढंग से बचाव नहीं करना), प्रक्रियाओं को शेड्यूल करना, भुखमरी और गतिरोध (या उनसे बचाव करना) को रोकना, पूर्ण क्षतिपूर्ति सुनिश्चित करना और मेमोरी रिक्त स्थान अलग करना, और इसी तरह ...

मैं भी कुछ और शब्द खर्च करना चाहता हूँ। अन्य चर्चाओं से मैंने यह विचार किया है कि ओवरकमिट के बारे में मुख्य चिंताओं में से एक (दोनों एक कारण के रूप में यह चाहते हैं और संभावित परेशानियों के स्रोत के रूप में) कांटे से निपटने के होते हैं: ईमानदारी से, मुझे नहीं पता है कि वास्तव में प्रतिलिपि कैसे है- ऑन-राइट रणनीति को लागू किया गया है, लेकिन मुझे लगता है कि किसी भी आक्रामक (या आशावादी) नीति को स्वैप-समान रूप से स्थानीयता रणनीति द्वारा कम किया जा सकता है। अर्थात्, केवल एक कोड प्रक्रिया पृष्ठों और शेड्यूलिंग स्ट्रक्चर्स को क्लोन करने (और एडजस्ट करने) के बजाय, कुछ अन्य डेटा पेजों को वास्तविक लिखने से पहले कॉपी किया जा सकता है, उन पेजों के बीच चयन करना जिन्हें पेरेंट प्रक्रिया ने अधिक बार लिखने के लिए एक्सेस किया है (यानी, लेखन कार्यों के लिए एक काउंटर का उपयोग करना)।

सब कुछ, ज़ाहिर है, IMHO।


5
"मोवरोवर, एक एपीआई को क्रम में रन-टाइम पर उनके 'महत्व' स्तर को बढ़ाने या कम करने के लिए प्रदान किया जा सकता है" महत्व है /proc/$PID/oom_adj
वि।

1
JVM के बारे में, एक गोछा है जो आपको कुछ मामलों में मेमोरी ओवरकॉमिट करना चाहती है: यदि आप अपने मूल JVM से एक और JVM बनाना चाहते हैं, तो यह fork () कहलाएगा। एक कांटा कॉल मूल प्रक्रिया (पहले) जितनी स्मृति आवंटित करेगा, जब तक कि यह वास्तव में प्रक्रिया शुरू नहीं करता है। तो मान लीजिए कि आपके पास 4GB JVM है और आप इसमें से एक नया 512KB JVM बनाना चाहते हैं, जब तक कि आपके पास ओवरकम नहीं है, आपको ऐसा करने के लिए 8GB मेमोरी की आवश्यकता होगी ...
alci

4
@Vi। अब लगता है/proc/$PID/oom_score_adj
erm3nda

1

यदि आपकी मेमोरी का उपयोग प्रक्रियाओं द्वारा उस सीमा तक किया जाता है जो संभवतः सिस्टम की स्थिरता को खतरे में डाल सकता है, तो OOM हत्यारा तस्वीर में आता है। ओओएम किलर का काम है कि वह प्रक्रियाओं को मार डाले जब तक कि बाकी प्रक्रिया के सुचारू संचालन के लिए पर्याप्त मेमोरी को मुक्त नहीं किया जाता है। OOM किलर को मारने के लिए "सर्वश्रेष्ठ" प्रक्रिया का चयन करना होगा। "बेस्ट" यहां उस प्रक्रिया को संदर्भित करता है जो हत्या पर अधिकतम मेमोरी को मुक्त कर देगा और सिस्टम के लिए भी कम से कम महत्वपूर्ण है। प्राथमिक लक्ष्य कम से कम प्रक्रियाओं को मारना है जो नुकसान को कम करता है और साथ ही साथ मुक्त की गई मेमोरी की मात्रा को अधिकतम करता है। इसे सुविधाजनक बनाने के लिए, कर्नेल प्रत्येक प्रक्रिया के लिए oom_score को बनाए रखता है। आप प्रत्येक प्रक्रिया के oom_score को pid ​​निर्देशिका के अंतर्गत / proc फाइलसिस्टम में देख सकते हैं

# cat /proc/10292/oom_score

किसी भी प्रक्रिया के oom_score का मूल्य जितना अधिक होता है, OOM किलर द्वारा आउट-ऑफ-मेमोरी स्थिति में मारे जाने की संभावना अधिक होती है।

क्रेडिट: - लिनक्स कर्नेल OOM किलर शुरू कर रहा है

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.