किसी भी मुद्दे पर अगर ज़ोंबी राज्य को मंजूरी नहीं दी जाती है?


18

मेरे पास उत्पादन इकाई है जिसमें जावा प्रक्रिया ज़ोंबी बन गई है और पिछले कुछ समय से वहां बनी हुई है। यदि इकाई को फिर से शुरू किया जाता है, तो यह साफ हो जाएगा। हालाँकि, इकाई को पुनरारंभ नहीं किया गया है और एक अन्य जावा प्रक्रिया ऊपर और चल रही है। क्या कोई मुद्दा है अगर यह ज़ोंबी स्थिति बनी हुई है क्योंकि यह इसे साफ करने के बिना है? क्या यह किसी भी तरह से प्रभावित करेगा (प्रदर्शन या सुस्ती)?

जवाबों:


22

ज़ोंबी प्रक्रिया का प्रदर्शन या सुस्ती पर कोई प्रभाव नहीं पड़ेगा क्योंकि ज़ोंबी प्रक्रियाएं किसी भी सिस्टम संसाधनों का उपयोग नहीं करती हैं।

नोट: - व्यावहारिक रूप से, यह अभी भी पीआईडी ​​(जो एक सीमित संसाधन है) का उपयोग कर रहा है, और प्रक्रिया के लिए कर्नेल डेटा संरचनाएं अभी भी आवंटित की गई हैं। आमतौर पर, यह ज्यादा मायने नहीं रखता है, लेकिन कर्नेल मेमोरी का उपयोग बहुत सीमित मेमोरी वाले सिस्टम पर महत्वपूर्ण हो सकता है।

ज़ोंबी प्रक्रिया के कारण समस्या

प्रत्येक ज़ोंबी प्रक्रिया अपनी प्रक्रिया आईडी को बरकरार रखती है। - Linux सिस्टम प्रक्रिया आईडी की एक निश्चित संख्या है 32767 , उपलब्ध PIDs की पूरी पूल अंततः, ज़ोंबी प्रक्रियाओं करने के लिए आवंटित हो जाएगा शुरू करने से अन्य प्रक्रियाओं को रोकने के लिए एक बहुत जल्दी दर से जमा कर रहे हैं 32-बिट systems.If लाश पर डिफ़ॉल्ट रूप से।

नोट : 64-बिट सिस्टम पर, आप अधिकतम PID बढ़ा सकते हैं, /unix//a/16884/170373 देखें

हालांकि, कुछ ज़ोंबी प्रक्रियाओं के चारों ओर लटकी हुई कोई समस्या नहीं है - हालांकि वे आपके सिस्टम पर अपनी मूल प्रक्रिया के साथ एक बग का संकेत देते हैं।

स्पष्टीकरण:

जब लिनक्स पर एक प्रक्रिया मर जाती है, तो यह तुरंत मेमोरी से नहीं हटाया जाता है - इसकी प्रक्रिया विवरणक मेमोरी में रहती है।

प्रक्रिया की स्थिति बन जाती है EXIT_ZOMBIEऔर प्रक्रिया के जनक को सूचित किया जाता है कि SIGCHLDसंकेत के साथ इसकी बाल प्रक्रिया मर गई है ।

माता-पिता की प्रक्रिया तब मृत प्रक्रिया के निकास की स्थिति और अन्य जानकारी को पढ़ने के लिए प्रतीक्षा () सिस्टम कॉल निष्पादित करने के लिए माना जाता है। यह मूल प्रक्रिया को मृत प्रक्रिया से जानकारी प्राप्त करने की अनुमति देता है। प्रतीक्षा के बाद () कहा जाता है, ज़ोंबी प्रक्रिया पूरी तरह से स्मृति से हटा दी जाती है।

यह सामान्य रूप से बहुत जल्दी होता है, इसलिए आप ज़ोंबी प्रक्रियाओं को आपके सिस्टम पर जमा नहीं देखेंगे। हालाँकि, यदि कोई मूल प्रक्रिया ठीक से प्रोग्राम नहीं की गई है और कभी भी वेट () कॉल नहीं किया जाता है, तो इसके ज़ोंबी बच्चे स्मृति में तब तक चिपके रहेंगे, जब तक वे साफ़ नहीं हो जाते।

संकल्प:

आप ज़ोंबी प्रक्रियाओं को नहीं मार सकते क्योंकि आप सामान्य प्रक्रियाओं को सामान्य संकेत से मार सकते हैं - ज़ोंबी प्रक्रिया पहले से ही मृत हैं।

ज़ोंबी को मारने का एक तरीका मूल प्रक्रिया को SIGCHLD संकेत भेजना है। यह संकेत प्रतीक्षा () सिस्टम कॉल को निष्पादित करने और अपने ज़ोंबी बच्चों को साफ करने के लिए मूल प्रक्रिया को बताता है। पैरेंट प्रॉसेस के PID के साथ नीचे कमांड में pid की जगह, किल कमांड के साथ सिग्नल भेजें:

kill -s SIGCHLD pid

जब प्रक्रिया है कि लाश का निर्माण होता है, init ज़ोंबी प्रक्रियाओं विरासत में मिला और उनके नए माता पिता बन जाता है। (init बूट पर लिनक्स पर शुरू की गई पहली प्रक्रिया है और इसे PID 1 सौंपा गया है)

नोट: - Linux 3.4 से आगे की प्रक्रिया PR_SET_CHILD_SUBREAPER विकल्प के साथ prctl () सिस्टम कॉल जारी कर सकता है, और परिणामस्वरूप, वे # 1 प्रक्रिया नहीं, उनकी अनाथ वंशज प्रक्रियाओं के माता-पिता बन जाएंगे। संदर्भ: /unix//a/177361/5132  

INIT तब अपने ज़ोंबी बच्चों को साफ करने के लिए प्रतीक्षा () सिस्टम कॉल को अंजाम देता है, इसलिए init लाश का छोटा काम कर देगा। आप इसे बंद करने के बाद मूल प्रक्रिया को पुनरारंभ कर सकते हैं।


क्या कोई ऐसा मौका है जहाँ प्रतीक्षा () ही विफल हो जाती है?
रवि

3
64-बिट सिस्टम पर, आप अधिकतम PID बढ़ा सकते हैं, unix.stackexchange.com/a/16884/170373
ilkkachu

1
पुनर्परिवर्तन के बारे में भी गलत है। unix.stackexchange.com/a/177361/5132 विडंबना यह है कि, प्रोग्राम बनाने वाले सबरीपर्स जो लंबे समय तक ज़ोंबी प्रक्रियाओं का कारण बनने का एक आसान तरीका है।
JdeBP

2
माता-पिता को पहले से ही एक SIGCHLD प्राप्त होगा जब प्रक्रिया अब एक ज़ोंबी मर गई है।
.ngel

2
कड़े शब्दों में यह कहना सही नहीं है कि यह संसाधनों का उपयोग नहीं करता है। यह अभी भी पीआईडी ​​(जो एक सीमित संसाधन है) का उपयोग कर रहा है, और प्रक्रिया के लिए कर्नेल डेटा संरचनाएं अभी भी आवंटित की गई हैं। आमतौर पर, यह ज्यादा मायने नहीं रखता है, लेकिन कर्नेल मेमोरी का उपयोग बहुत सीमित मेमोरी वाले सिस्टम पर महत्वपूर्ण हो सकता है।
ऑस्टिन हेमेलर्गरन

6

ज्यादातर, लाश एक बड़ा मुद्दा नहीं है। वे एक 'डेड-ईश' प्रक्रिया है, जिसमें कोई सीपीयू समय नहीं लगता है, और किसी भी आवंटित मेमोरी को मरने से पहले प्रक्रिया से मुक्त किया जाना चाहिए । एकमात्र संसाधन जो वे वास्तव में लेते हैं, वह आपकी प्रक्रिया सूची में एक प्रविष्टि है। आपके सिस्टम के आधार पर, आपके पास थ्रेड्स की अधिकतम अनुमत संख्या हो सकती है, और लाश होने से आप बिना किसी कारण के इस सीमा तक पहुँच सकते हैं।

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

संपादित करें : यदि प्रक्रिया एक जावा प्रोग्राम है, तो मुक्त मेमोरी एक मुद्दा नहीं होनी चाहिए, क्योंकि जावा कचरा कलेक्टर सब कुछ का ख्याल रखता है।


3
वास्तव में, फ़ीड नहीं स्मृति यह सभी भाषाओं में सबसे OSes जारी नहीं करता है। मूल प्रक्रिया के लिए छोटी राशि को छोड़कर सिस्टम सभी मेमोरी को मुक्त कर देगा।
वैल का कहना है कि
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.