OOM किलर काम नहीं कर रहा है?

Question

मैं जो समझता हूं, जब सिस्टम के पास कोई मुफ्त मेमोरी नहीं है, तो कर्नेल को कुछ मेमोरी फिर से प्राप्त करने के लिए प्रक्रियाओं को मारना शुरू करना चाहिए। लेकिन मेरे सिस्टम में ऐसा बिल्कुल नहीं होता है।

मान लीजिए कि एक साधारण स्क्रिप्ट जो सिस्टम में उपलब्ध की तुलना में बहुत अधिक मेमोरी आवंटित करती है (उदाहरण के लिए लाखों स्ट्रिंग्स के साथ एक सरणी)। यदि मैं इस तरह से एक स्क्रिप्ट चलाता हूं (एक सामान्य उपयोगकर्ता के रूप में), यह पूरी तरह से सभी मेमोरी प्राप्त करता है जब तक कि सिस्टम पूरी तरह से जमा नहीं हो जाता है (केवल SysRQ REISUB काम करता है)।

यहां अजीब बात यह है कि जब कंप्यूटर फ्रीज होता है, तो हार्ड ड्राइव का नेतृत्व चालू हो जाता है और उस तरह से रहता है जब तक कि कंप्यूटर को रिबूट नहीं किया जाता है, या तो मेरे पास एक स्वैप विभाजन घुड़सवार है या नहीं!

तो मेरे सवाल हैं:

1. क्या यह व्यवहार सामान्य है? यह अजीब है कि एक सामान्य उपयोगकर्ता के रूप में निष्पादित एक एप्लिकेशन इस तरह से सिस्टम को क्रैश कर सकता है ...
2. क्या कोई तरीका है जब मैं उबंटू बना सकता हूं बस स्वचालित रूप से उन अनुप्रयोगों को मार सकता हूं जब वे बहुत अधिक (या सबसे) मेमोरी प्राप्त करते हैं?

अतिरिक्त जानकारी

• उबुन्टु 12.04.3
• कर्नेल 3.5.0-44

• रैम: 4GB से ~ 3.7GB (ग्राफिक्स कार्ड के साथ साझा)। *

  $ tail -n+1 /proc/sys/vm/overcommit_*
  ==> /proc/sys/vm/overcommit_memory <==
  0
  
  ==> /proc/sys/vm/overcommit_ratio <==
  50
  
  $ cat /proc/swaps
  Filename                Type        Size    Used    Priority
  /dev/dm-1                               partition   4194300 344696  -1
  

Comments

मुझे यकीन नहीं है कि यह काम क्यों नहीं कर रहा है। कोशिश करें tail -n+1 /proc/sys/vm/overcommit_*और आउटपुट जोड़ें। यहाँ भी देखें: मैं ओओम-किलर को कैसे कॉन्फ़िगर करूं

— kiri

तो आपके स्वैप स्थान के साथ क्या हो रहा है? क्या आप # vmstat 1 100 की तरह कुछ vmstat आउटपुट या कुछ ऐसा पोस्ट कर सकते हैं? और हमें बिल्ली / आदि / fstab भी दिखाएं कि क्या होना चाहिए स्मृति उपयोग की एक निश्चित मात्रा में है, आपको स्वैप करना लिखना शुरू करना चाहिए। स्मृति और स्वैप स्थान "पूर्ण" होने तक हत्या प्रक्रियाएं नहीं होनी चाहिए।

— jhh

यह भी प्रयास करें #swapon -a

— j0h

@ j0h स्वैप के साथ यह अच्छी तरह से काम करने लगता है (कुछ समय बाद यह प्रक्रिया कुछ इस तरह से दुर्घटनाग्रस्त हो गई Allocation failed)। लेकिन स्वैप के बिना यह सिर्फ कंप्यूटर को जमा देता है। यह इस तरह से काम करना चाहिए (केवल स्वैप का उपयोग करते समय मारना)?

— सेलम

SysRq के साथ आप OOM (SysRq + F iirc)

— Lekensteyn

Answer 1

से आधिकारिक /proc/sys/vm/*प्रलेखन :

oom_kill_allocating_task

यह ओओएम-ट्रिगरिंग कार्य को आउट-ऑफ-मेमोरी स्थितियों में मारने में सक्षम या अक्षम करता है।

यदि इसे शून्य पर सेट किया जाता है, तो OOM हत्यारा पूरे टास्कलिस्ट के माध्यम से स्कैन करेगा और मारने के लिए उत्तराधिकार के आधार पर एक कार्य का चयन करेगा। यह आम तौर पर एक दुष्ट मेमोरी-हॉगिंग कार्य का चयन करता है जो मारे जाने पर बड़ी मात्रा में मेमोरी को मुक्त करता है।

यदि यह गैर-शून्य पर सेट होता है, तो OOM किलर उस कार्य को मार देता है, जो आउट-ऑफ-मेमोरी स्थिति को ट्रिगर करता है। यह महंगी टास्कलिस्ट स्कैन से बचा जाता है।

यदि आतंक_ऑन_ओम का चयन किया जाता है, तो oom_kill_allocating_task में जो भी मूल्य का उपयोग किया जाता है, उस पर यह पूर्वता लेता है।

डिफॉल्यू मूल्य शून्य है।

सारांशित करने के लिए, जब सेटिंग oom_kill_allocating_taskकरने 1के बजाय, अपने सिस्टम को मारने के लिए प्रक्रियाओं की तलाश में स्कैन करने के बजाय, जो एक महंगा और धीमा काम है, तो कर्नेल सिर्फ उस प्रक्रिया को मार देगा जिसके कारण सिस्टम मेमोरी से बाहर हो गया।

अपने स्वयं के अनुभवों से, जब एक ओओएम ट्रिगर होता है, तो कर्नेल के पास "स्कैन" करने के लिए पर्याप्त "ताकत" नहीं होती है, जिससे सिस्टम पूरी तरह से बेकार हो जाता है।

इसके अलावा, यह अधिक स्पष्ट होगा कि समस्या का कारण बने कार्य को मारना, इसलिए मैं यह समझने में विफल हूं कि यह 0डिफ़ॉल्ट रूप से क्यों सेट किया गया है।

परीक्षण के लिए, आप बस उचित छद्म फाइल में लिख सकते हैं /proc/sys/vm/, जो अगले रिबूट पर पूर्ववत होगी:

echo 1 | sudo tee /proc/sys/vm/oom_kill_allocating_task

स्थाई फ़िक्स के लिए, विस्तार के साथ ( उदाहरण के लिए) , के /etc/sysctl.confतहत निम्नलिखित को एक नई फ़ाइल में लिखें :/etc/sysctl.d/.conf/etc/sysctl.d/local.conf

vm.oom_kill_allocating_task = 1

Comments

क्या यह हमेशा Ubuntu में 0 पर सेट था? क्योंकि मुझे याद है कि यह स्वचालित रूप से मार करता था, लेकिन कुछ संस्करणों के बाद से ऐसा करना बंद हो गया।

— स्कीर

@skerit यह मुझे वास्तव में नहीं पता है, लेकिन इसे 2010 में वापस उपयोग की जाने वाली गुठली (डेबियन, लिकोरिक्स और जीआरएमएल) में 0 पर सेट किया गया था।

— टेरेसा ई जूनियर

"इसके अलावा, यह और अधिक स्पष्ट होगा कि समस्या का कारण बनने वाले कार्य को मारना है, इसलिए मैं यह समझने में विफल हूं कि यह 0डिफ़ॉल्ट रूप से क्यों सेट किया गया है।" - क्योंकि स्मृति से अनुरोध करने वाली प्रक्रिया जरूरी नहीं है कि "समस्या का कारण" हो। यदि प्रक्रिया A सिस्टम की मेमोरी का 99% हॉग करता है, लेकिन प्रक्रिया B, जो 0.9% का उपयोग कर रहा है, तो ऐसा होता है जो OOM किलर को दुर्भाग्य से चलाता है, B ने "समस्या का कारण" नहीं बनाया और इसका कोई मतलब नहीं है मार बी। कि एक अलग प्रक्रिया के भगोड़ा स्मृति उपयोग की वजह से मौके से मारे जा रहे पूरी तरह से अप्रमाणिक कम-स्मृति प्रक्रियाओं के जोखिम के रूप में जोखिम ।

— मार्क अमेरी

@MarkAmery असली समस्या यह है कि लिनक्स, केवल आवश्यक प्रक्रिया को मारने के बजाय, मंदता की तरह जोर देना शुरू कर देता है, भले ही vm.admin_reserve_kbytesबढ़ाकर कहा जाए, 128 एमबी । सेटिंग vm.oom_kill_allocating_task = 1समस्या को कम करने के लिए लगता है, वास्तव में इसे हल नहीं करता है (और Ubuntu पहले से ही डिफ़ॉल्ट रूप से कांटा बम से संबंधित है)।

— टेरेसा ई जूनियर

शायद अधिक सुंदरsudo sysctl -w vm.oom_kill_allocating_task=1

— पाब्लो ए

Answer 2

अद्यतन: बग ठीक हो गया है।

टेरेसा का जवाब समस्या को हल करने के लिए पर्याप्त है और अच्छा है।

इसके अतिरिक्त, मैंने एक बग रिपोर्ट दर्ज की है क्योंकि यह निश्चित रूप से एक टूटा हुआ व्यवहार है।

Comments

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

— शेपचैकर

हो सकता है कि 2014 में तय किया गया हो, 2018 (और 18.04) में ओओएम हत्यारा अभी तक फिर से कुछ नहीं कर रहा है।

— स्केटर

Answer 3

आप शुरुआती ओओएम हत्यारे की कोशिश कर सकते हैं , जो यूजर स्पेस में काम करता है और ओओएम स्थिति में सबसे बड़ी प्रक्रिया को मारने की कोशिश करता है।

Answer 4

सबसे पहले मैं 13.10 को अपडेट की सिफारिश करता हूं (साफ इंस्टॉल, अपना डेटा सहेजें)।

यदि आप vm.swappiness को 10 में बदलना नहीं चाहते हैं और यदि आपको अपने RAM zRAM के साथ समस्याएँ आती हैं।

Comments

मैं वह नहीं था, जिसने आपको नीचा दिखाया, लेकिन आम तौर पर, vm.swappinessकम मेमोरी से अधिक नुकसान करता है, कम मेमोरी के मुद्दों से पीड़ित सिस्टम पर भी।

— टेरेसा ई जूनियर

तब नहीं जब आप पहले रैम को सेक करते हैं और आप तब डिस्क के उपयोग से बचते हैं जो बहुत धीमी है और आपके कंप्यूटर को फ्रीज कर सकती है।

— ब्रास्क

सिद्धांत रूप में, zRAM एक अच्छी बात है, लेकिन यह सीपीयू भूखा है, और आमतौर पर लागत के लायक नहीं है। आम तौर पर मेमोरी बिजली से सस्ती होती है। और, एक लैपटॉप पर, जहां रैम को अपग्रेड करना अधिक महंगा है, सीपीयू का उपयोग ज्यादातर अवांछनीय है।

— टेरेसा ई जूनियर

वह जिस चीज के लिए कह रहा है वह एक अधिक स्थिर प्रणाली zRAM है और बदलते स्वपनदोष से उसका सिस्टम अधिक CPU संसाधन का उपयोग करेगा, लेकिन वह जो सीमित एटीएम है और जिसके साथ त्रुटियां हैं वह स्मृति है, वह समस्या को ठीक करना चाहता है सिद्धांत सिद्धांत नहीं जब आप zRAM स्थापित करते हैं तो क्या होता है।

— ब्रास्क 9'14

यह उसके प्रश्न से स्पष्ट है कि वह एक अनुचित स्क्रिप्ट लिख सकता है जो इसे जितना चाहिए, उससे अधिक खाती है (और मैंने पहले ही खुद ऐसा किया है)। इस तरह की स्थिति में, आप स्क्रिप्ट को कुछ सेकंड में RAM के गीगाबाइट को हथियाने के लिए देख सकते हैं, और zRAM बचाव में नहीं आएगा, क्योंकि स्क्रिप्ट कभी भी संतुष्ट नहीं होगी।

— टेरेसा ई जूनियर