क्या वेब सर्वर को समय-समय पर फिर से चालू करना एक सर्वश्रेष्ठ उद्योग अभ्यास है? [बन्द है]

28

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

ग्राहक के दृष्टिकोण से जो दिन के दौरान दुर्घटनाग्रस्त होने वाली साइट के उनके मुद्दे को कम करता है, लेकिन SysAdmin परिप्रेक्ष्य से यह एक अजीब समाधान है।

हम अलग-अलग क्लाइंट्स के लिए अलग-अलग सर्वरों में इनमें से 20 एप्लिकेशन होस्ट करते हैं, और यह सुनिश्चित करने का समन्वय कि सभी को हर रात फिर से शुरू किया जा रहा है, केवल गलत लगता है।

tomcat java

— भू
स्रोत

41

उन्हें बताएं कि एप्लिकेशन डेवलपर्स के लिए उनकी मेमोरी लीक को खोजने और उन्हें ठीक करने के लिए यह उद्योग सर्वश्रेष्ठ अभ्यास है।

— बार्ट सिल्वरस्ट्रिम

4

@ बर्ट ओह स्नैप !!

— एमफिनी

1

+1 बस अपना दिन बनाने के लिए (PS: मैं खुद एक डेवलपर हूं)

— आरएन।

1

क्या उसने सर्वर या सेवाएं कहा था? हम एक tomcat एप्लिकेशन को hve करते हैं, जिसे सेवा को हर रात पुनरारंभ करने की आवश्यकता होती है। अगर मैं ऐसा नहीं करता हूं, तो भविष्य में किसी समय यह दुर्घटनाग्रस्त हो जाएगा। मैं ऐसा नहीं करूंगा, लेकिन दिन के दौरान सेवा अधिक महत्वपूर्ण है।

— टब

1

कुछ लॉग फ़ाइल मॉनिटरिंग पर जाएं और कुछ JVM मॉनिटरिंग टूल डाउनलोड करें। यदि सामान दिन के दौरान दुर्घटनाग्रस्त हो रहा है तो आपको अपवाद या कुछ और लॉग इन करना चाहिए - भले ही वे डिफ़ॉल्ट अपवाद हों। यह आपको त्रुटि की सामान्य प्रकृति में कुछ जानकारी देगा। इसके अलावा, JVM मेमोरी माइलेज देखें। ऑड्स वास्तव में अच्छे हैं उनके पास एक मेमोरी लीक है और यदि आप सर्वर JVM हीप देखते हैं तो आप इसे पकड़ लेंगे। अच्छे sysadmin डेटा के साथ खराब विकास से लड़ें। यह "आप अभी नहीं जानते कि आप क्या कर रहे हैं" रक्षा को नष्ट कर देता है और उन्हें वास्तव में इस बात के लिए जवाब देना पड़ता है कि चीजों ने गड़बड़ क्यों की।

— फ्लॉपीडिस्क

29

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

— EEAA
स्रोत

1

यह बहुत अच्छी बात है। यदि आप कभी भी अपने सर्वर को पुनः आरंभ नहीं करते हैं जैसा कि नीचे सुझाया गया है तो आप यह नहीं जान सकते हैं कि आपके पास कुछ ऐसी सेवाएं हैं जो ठीक से शुरू नहीं होती हैं। फिर, एक बिजली की विफलता / हार्ड पुनरारंभ होने की स्थिति में आपका सर्वर सही वापस नहीं आ सकता है।

— आइंस्टीन

1

+1। मासिक अधिक समझ में आ सकता है - न केवल एक पुनरारंभ के लिए, बल्कि पैच लगाने के लिए एक सामान्य ऑपरेशन प्रक्रिया के लिए आदि मैं एक बार लगभग 1500 सर्वर, 24/7 के लिए एक व्यवस्थापक टीम का हिस्सा था, और हर महीने एक 3 रात "रोलिंग" था। पुनः आरंभ "अनुसूचित, जिस बिंदु पर सभी पैच आदि सर्वर में डाल दिए जाएंगे, भी। यह कुछ नियोजन स्थिरता और एक मानक संचालन प्रक्रिया को बढ़ावा देता है।

— टॉमटॉम

12

"बेस्ट प्रैक्टिस", उन चीजों के बीच अंतर है जो कई लोग अच्छे कारणों से करते हैं, और "कॉमन प्रैक्टिस", वे चीजें जो बहुत से लोग करते हैं क्योंकि वे आलसी और / या अज्ञानी हैं।

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

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

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

यह देखते हुए कि आप डेवलपर को बदलने की स्थिति में नहीं हो सकते, कुछ सुझाव:

देखें कि क्या आप एक बेहतर डेवलपर कोड की समीक्षा कर सकते हैं और अपने मूल्यांकन की रिपोर्ट किसी ऐसे व्यक्ति से कर सकते हैं जो इसके बारे में कुछ कर सकता है,
प्रोफाइलिंग टूल पर एक नज़र डालें। यदि आपको कौशल और / या झुकाव मिला है, तो रिसाव को खोजने और रिपोर्ट करने के लिए कोड को स्वयं प्रोफाइल करने का प्रयास करें।

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

लेकिन बेहतर अभी तक, ये आपको सबूत इकट्ठा करने में मदद करनी चाहिए कि एक रिसाव है, और यह भी इंगित कर सकता है कि समस्या आवेदन में कहां है। यह तय करने के लिए आपको लॉबी के लिए बेहतर गोला-बारूद देगा।

— कैफ
स्रोत

2

दरअसल, कई बार यह बुनियादी ढाँचा होता है जिसमें बग होता है, न कि डेवलपर का कोड। हमें जे 2 ईई ऐप से परेशानी का कोई अंत नहीं है जो समय-समय पर JBoss पर कचरा-संग्रह नरक में जाते हैं लेकिन अन्य commercail एप्लिकेशन सर्वर पर ठीक काम करते हैं। तो यह डेवलपर की गलती नहीं हो सकती है, बल्कि तैनाती का माहौल हो सकता है।

— ralayter

6

एप्लिकेशन डेवलपर अधिक संभावना यह दावा कर रहा है कि आपके द्वारा किए गए अनप्रोफेशनल जॉब के आसपास काम करके अपने गधे को कवर करना उसके लिए अपने हित में है। हो सकता है कि उसने वास्तव में स्वीकार करना बंद कर दिया हो कि उसने कुछ मेमोरी रिसाव के साथ लिखा था, लेकिन बहुत कम नहीं।

— मैक्सिमस मिनिमस
स्रोत

3

यहाँ कई उत्तर व्यावहारिक समाधानों की छाप छोड़ते हुए प्रतीत होते हैं। वे हठधर्मिता से बचने लगते हैं - सर्वर को कभी भी पुनरारंभ नहीं किया जाना चाहिए - हमारे पास 5 नाइन क्यों हैं? दोष सहिष्णुता? ठीक है, इसलिए जब वे उठने वाले होते हैं तो वे ऊपर रहते हैं।

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

सप्ताह में एक बार या महीने में एक बार रिबूट करने वाले सर्वर कहते हैं कि मेरे विचार में स्मार्ट और कुशल है। यदि आपको क्लस्टर किया गया है और आप सर्वरों को घुमाते हैं तो आपको क्लाइंट को एक सा प्रभावित नहीं करना चाहिए। आपके सर्वर के प्रदर्शन से ग्राहक अधिक खुश होंगे।

— क्लाउड
स्रोत

2

IMO सर्वर को यथासंभव कम बंद किया जाना चाहिए। यह अधिक संभावना है कि ऐप डेवलपर ने मेमोरी लीक के साथ एक घटिया एप्लिकेशन बनाया।

— matpie
स्रोत

बिल्कुल - मुझे लगता है कि ओपी को किसी को बताने की जरूरत है कि उन्हें एक बेहतर डेवलपर खोजने की जरूरत है।

— हेल्विक

2

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

— बार्ट सिल्वरस्ट्रिम

1

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

— einstiien
स्रोत

1

एक सर्वर को अधिमानतः कभी भी पुनरारंभ नहीं किया जाना चाहिए । यही कारण है कि हमारे पास दोष सहिष्णुता है । यदि आपको अपने एप्लिकेशन के कारण अपने सर्वर को पुनरारंभ करना है, तो आपके एप्लिकेशन मेमोरी को लीक कर रहे हैं और बुरी तरह से निर्मित हैं।

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

संपादित करें: यदि आपको इसे अब हर रात को पुनरारंभ करना है, तो संभवतः आपको लोड अधिक होने पर / इसे अधिक बार पुनरारंभ करना होगा। ठोस अनुप्रयोग सुनिश्चित करें, यह सबसे अच्छा समाधान है।

— जोनास
स्रोत

4

मुझे नहीं लगता कि मैं सहमत हूं जब आप कहते हैं कि एक सर्वर को कभी भी पुनरारंभ नहीं किया जाना चाहिए। सुरक्षा फ़िक्सेस को लागू करने के लिए सर्वर को पुनरारंभ किया जाना चाहिए। उन्हें कभी भी उन चीजों के लिए फिर से शुरू करने की आवश्यकता नहीं होनी चाहिए जो योजनाबद्ध रखरखाव हैं।

— Zoredache

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

— जोनास

1

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

— EEAA

1

"अगली बार ... मैं टॉमकैट के अलावा एक और [जावा कंटेनर की तलाश करूंगा"। मैं टॉमकैट को दोषी नहीं ठहराऊंगा। मैं वर्षों से इस पर उत्पादन सेवाएँ चला रहा हूँ, और हर बार जब भी मुझे यह समस्या हुई है, तो यह एक एप्लीकेशन इश्यू है। "ठोस अनुप्रयोगों के लिए सुनिश्चित करें, यह सबसे अच्छा समाधान है" बिल्कुल सही। मजेदार रूप से पर्याप्त है, मैंने अब तक उपयोग किए गए हर दूसरे जावा एप्लिकेशन सर्वर को जब मैं इस पर लीक कोड चलाता हूं तो इसी तरह की समस्याओं का सामना करना पड़ता है। उस ने कहा, टॉमकैट 7 में किसी प्रकार के प्रो-एक्टिव मेमोरी लीक का पता लगाने की संभावना है।

— कीफ

0

सबसे अधिक बार जो मैंने देखा है वह साप्ताहिक है। जहाँ मैं अभी हूँ हम एक विंडोज़ शॉप हैं, और हम इसे पैच मंगलवार के बाद के सप्ताहांत में मासिक रूप से करते हैं।

— जोएल कोएल
स्रोत

जब मैंने एक स्थान पर काम करना शुरू किया, तो मैंने पाया कि उनके पास जगह-जगह रात के समय रिबूट्स थे ... यह भयानक था, खासकर जब से सर्वर को सही तरीके से वापस नहीं आने का 1-2% मौका था (हार्ड ड्राइव ड्राइवर में टाइमिंग बग) )। रिबूट के लिए "कारणों" को ठीक करने के लिए कुछ समय लिया। समय अच्छा कटा।

— ब्रायन नोब्लुच

0

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

— निक मेलर
स्रोत