👨🏻‍⚕️ 👩‍🌾 👩🏻‍🔬 अचानक, अकेले कचरा संग्रहण प्रणाली पर्याप्त नहीं है 👨‍👧‍👦 📷 ⬅️

यहां रहस्यमय सर्वर विफलताओं के बारे में एक छोटी कहानी है जिसे मुझे एक साल पहले डिबग करना पड़ा था (लेख दिनांक 05 दिसंबर, 2018, लगभग .per)। सर्वर ने कुछ समय के लिए ठीक काम किया, और फिर कुछ बिंदु पर दुर्घटना शुरू हो गई। इसके बाद, सर्वर पर होने वाले लगभग किसी भी प्रोग्राम को चलाने का प्रयास "डिवाइस पर कोई जगह नहीं है" त्रुटियों के साथ विफल रहा, हालांकि फ़ाइल सिस्टम ने ~ 20 जीबी डिस्क पर केवल कुछ कब्जे वाली गीगाबाइट की सूचना दी।

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

* निक्स फाइल सिस्टम फाइलों में फाइल के नाम और डेटा को अलग करता है। डिस्क पर डेटा में कई फ़ाइल नाम होते हैं जो उन्हें इंगित करते हैं (यानी हार्ड लिंक), और डेटा केवल तभी हटाया जाता है जब अंतिम लिंक हटा दिया जाता है। एक ओपन फ़ाइल डिस्क्रिप्टर को एक लिंक माना जाता है, इसलिए यदि प्रोग्राम को पढ़ते समय फ़ाइल को हटा दिया जाता है, तो फ़ाइल का नाम निर्देशिका से गायब हो जाता है, लेकिन प्रोग्राम बंद होने तक फ़ाइल डेटा जीवित रहता है। लकड़हारे के साथ ऐसा ही हुआ। डु ("डिस्क उपयोग") एक डायरेक्टरी लिस्टिंग का उपयोग करके फाइलों की खोज करता है, इसलिए इसने हजारों लॉग फ़ाइलों के लिए फ़ाइल डेटा के गीगाबाइट्स को नहीं देखा जो अभी भी खुले थे। इन फ़ाइलों को केवल lsof ("सूची खुली फ़ाइलें") चलाने के बाद खोजा गया था।

बेशक, एक समान त्रुटि अन्य समान मामलों में होती है। कुछ महीने पहले, मुझे एक जावा एप्लिकेशन में भागना पड़ा था जो नेटवर्क कनेक्शन में रिसाव के कारण कुछ दिनों के बाद टूट गया।

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

आप कचरा संग्रहण पर भरोसा नहीं कर सकते हैं, क्योंकि यह केवल स्मृति प्रबंधन की समस्या को हल करता है, और जटिल कार्यक्रमों को सिर्फ मेमोरी से बहुत अधिक निपटाना पड़ता है। एक लोकप्रिय मेम है जो इस तथ्य के साथ जवाब देती है कि स्मृति संसाधन समस्याओं का 95% है । आप यहां तक कह सकते हैं कि सभी संसाधन आपकी समस्याओं का 0% हैं - जब तक आप उनमें से एक से बाहर नहीं निकलते। तब यह संसाधन आपकी समस्याओं का 100% बन जाता है।

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

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

ध्यान दें कि स्वचालित कचरा संग्रह वास्तव में पहले पैटर्न को लागू करने के लिए अच्छा है, लेकिन दूसरा नहीं, जबकि मैनुअल संसाधन प्रबंधन तकनीक (जैसे RAII) दूसरे पैटर्न को लागू करने के लिए महान हैं, लेकिन पहले के लिए भयानक हैं। ये दो दृष्टिकोण जटिल कार्यक्रमों में पूरक बन जाते हैं।

अचानक, अकेले कचरा संग्रहण प्रणाली पर्याप्त नहीं है

More articles: