OOM किलर / cgroups द्वारा प्रक्रिया को मारने से पहले संकेत प्राप्त करें


11

हमारे क्लस्टर में, हम अपनी प्रक्रियाओं के संसाधनों को सीमित कर रहे हैं, उदाहरण के लिए मेमोरी ( memory.limit_in_bytes)।

मुझे लगता है, अंत में, यह लिनक्स कर्नेल में ओओएम हत्यारा के माध्यम से भी संभाला जाता है ( स्रोत कोड को पढ़कर ऐसा लगता है )।

क्या मेरी प्रक्रिया के मारे जाने से पहले संकेत प्राप्त करने का कोई तरीका है? ( एसजीई के-notify लिए विकल्प की तरह , जो प्रक्रिया को मारने से पहले भेज देगा ।)qsubSIGUSR1

मैं /dev/mem_notify यहाँ के बारे में पढ़ा, लेकिन मेरे पास नहीं है - आजकल कुछ और है? मैं भी पढ़ा यह जो कुछ हद तक प्रासंगिक लगती है।

मैं कम से कम एक छोटे स्टैक ट्रेस और शायद कुछ अन्य उपयोगी डिबग जानकारी को डंप करने में सक्षम होना चाहता हूं - लेकिन शायद मैं कुछ मेमोरी को मुक्त करके भी पुनर्प्राप्त कर सकता हूं।

एक वर्कअराउंड मैं वर्तमान में उपयोग कर रहा हूं यह छोटी स्क्रिप्ट है जो अक्सर जांचती है कि क्या मैं सीमा के करीब हूं (95%) और यदि ऐसा है, तो यह प्रक्रिया को ए भेजता है SIGUSR1। बैश में, मैं इस स्क्रिप्ट को पृष्ठभूमि में शुरू कर रहा हूं ( cgroup-mem-limit-watcher.py &) ताकि यह एक ही cgroup में अन्य procs के लिए देखता है और जब पैरेंट बैश प्रक्रिया मर जाती है तो यह स्वचालित रूप से क्विट करता है।


मुझे कोई अधिकार स्रोत नहीं मिला, न ही मैं विशिष्ट प्रक्रिया के लिए OOM किलर को मैन्युअल रूप से (विचार का परीक्षण करने के लिए) आह्वान करने का एक तरीका खोज सका , लेकिन मुझे जो मिला उससे यह प्रतीत होता है कि OOM हत्यारा बस SIGTERM भेजता है, इसलिए आपको सेट करना होगा इस संकेत के लिए एक हैंडलर।
हाय-एंजेल

5
@ हाय-एंजेल: लिनक्स स्रोत कोड से , ऐसा लगता है कि यह SIGKILL भेजता है।
अल्बर्ट

@Albert स्रोत कोड को पढ़ने के बाद, मुझे भी लगता है कि OOM किलर SIGKILL सिग्नल भेजेगा।
andy

जवाबों:


5

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

देख:

https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt


5

OOM किलर SIGKILL भेजता है क्योंकि यह समस्याग्रस्त कार्यक्रम को जारी रखने का विकल्प देने के लिए अन्यथा प्रति-उत्पादक होगा।

इसका मतलब यह है कि किसी प्रक्रिया के लिए यह जानने का कोई तरीका नहीं है कि यह कब मारा जाए।

ऐसे मुद्दों का प्रबंधन आमतौर पर कार्यक्रमों या उनके कॉन्फ़िगरेशन के लिए सुधार कर रहा है। कभी-कभी, सिस्टम के कॉन्फ़िगरेशन के आधार पर, बस बढ़ती स्वैप स्पेस ओएस को ऐसे कठोर उपायों से बचने के लिए अधिक मेमोरी प्रबंधन लचीलापन दे सकती है।

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