सॉफ्टवेयर जरण

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

इस घटना की पहली बार डेविड पारनास ने निबंध में पहचान की थी, जिसने यह पता लगाया था कि इसके बारे में क्या करना है: प्रोग्राम, लोगों की तरह, पुराने हो जाते हैं। हम जरण बढ़ने को नहीं रोक सकते, लेकिन हम इसके कारणों को समझ सकते हैं, इसके प्रभावों को सीमित करने के लिए कदम उठा सकते हैं, इससे होने वाली कुछ क्षति को अस्थायी रूप से उलट सकते हैं, और उस दिन के लिए तैयार हो सकते हैं जब सॉफ्टवेयर अब व्यवहार्य नहीं रहेगा।

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

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

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

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

एक अन्य तकनीक क्लाउड कम्प्यूटिंग वातावरण में चल रही आभासी मशीन को पुनः आरंभ करना है।

बहुराष्ट्रीय दूरसंचार निगम एटी एंड टी ने अधिकांश टेलीफोन एक्सचेंजों के लिए संयुक्त राज्य अमेरिका में बिलिंग डेटा एकत्र करने वाली वास्तविक समय प्रणाली में सॉफ्टवेयर कायाकल्प प्रयुक्त किया है।

सॉफ्टवेयर कायाकल्प विधियों को नियोजित करने वाली कुछ प्रणालियों में सम्मिलित हैं:
 * 1) लेनदेन प्रसंस्करण प्रणाली
 * 2) वेब सर्वर
 * 3) अंतरिक्ष यान प्रणाली

सॉफ़्टवेयर विश्वसनीयता इंजीनियरिंग (आईएसएसआरई) पर आईईईई अंतर्राष्ट्रीय संगोष्ठी ने 2013 में सॉफ़्टवेयर एजिंग और कायाकल्प पर 5वीं वार्षिक अंतर्राष्ट्रीय कार्यशाला (woSAR) की होस्टिंग की। विषयों में सम्मिलित हैं:
 * कायाकल्प तंत्र का डिजाइन, कार्यान्वयन और मूल्यांकन
 * कायाकल्प शेड्यूलिंग का मॉडलिंग, विश्लेषण और कार्यान्वयन
 * सॉफ्टवेयर कायाकल्प बेंचमार्क (कंप्यूटिंग)

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

प्रोग्रामिंग लैंग्वेज में लिखे प्रोग्राम जो कचरा संग्राहक (जैसे जावा (प्रोग्रामिंग भाषा)) का उपयोग करते हैं, मेमोरी लीक होने का खतरा नहीं है।

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

कार्यान्वयन
कायाकल्प को प्रयुक्त करने के दो विधियाँ हैं:
 * 1) समय आधारित कायाकल्प
 * 2) भविष्यवाणी आधारित कायाकल्प

मेमोरी ब्लोटिंग
कचरा संग्रह स्वचालित मेमोरी प्रबंधन का रूप है जिससे प्रणाली स्वचालित रूप से अप्रयुक्त मेमोरी को पुनः प्राप्त करता है। उदाहरण के लिए, .नेट फ्रेमवर्क इसके अंतर्गत चलने वाले सॉफ़्टवेयर के लिए मेमोरी के आवंटन और रिलीज़ का प्रबंधन करता है। लेकिन स्वचालित रूप से इन वस्तुओं को ट्रैक करने में समय लगता है और यह सही नहीं है।

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

यह भी देखें

 * सॉफ्टवेयर प्रतिगमन
 * सॉफ्टवेयर सड़ांध

अग्रिम पठन

 * R. Matias Jr. and P. J. Freitas Filho, "An experimental study on software aging and rejuvenation in web servers," Proceedings of the 30th Annual International Computer Software and Applications Conference (COMPSAC'06), Vol. 01, pp. 189 – 196, 2006.
 * M. Grottke, R. Matias Jr., and K. S. Trivedi, "The Fundamentals of Software Aging," Workshop of Software Aging and Rejuvenation (WoSAR/ISSRE), 2008.
 * R. Matias Jr, P. Barbetta, K. Trivedi, P. Freitas Filho "Accelerated Degradation Tests Applied to Software Aging Experiments," IEEE Transactions on Reliability 59(1): 102–114,2010.
 * M. Grottke, L. Li, K. Vaidyanathan, and K.S. Trivedi, "Analysis of software aging in a web server," IEEE Transactions on Reliability, vol. 55, no. 3, pp. 411–420, 2006.
 * M. Grottke, K. Trivedi, "Fighting Bugs: Remove, Retry, Replicate, and Rejuvenate," IEEE Computer 40(2): 107–109, 2007.
 * More papers on Proceedings of Workshop of Software Aging and Rejuvenation (WoSAR'08,'10, '11, '12, '13, '14) at IEEE Xplore.