कितनी बार Windows सर्वर को पुनरारंभ करने की आवश्यकता है?


77

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

तो सवाल यह है: कितनी बार हर कोई अपने विंडोज सर्वर को पुनरारंभ करता है? क्या कोई उद्योग मानक या सिफारिश है? क्या आईटी विभाग यह कहने में सही है कि क्योंकि हम फिर से शुरू कर रहे हैं, इसलिए हम हार्डवेयर समस्याएँ हैं? (अगर मुझे उसका मन बदलने वाला है तो मुझे एक कारण चाहिए!)


111
ओह, महीने के हर दूसरे मंगलवार के बारे में । :)
26'11

4
डांग! हम महीने के हर चौथे गुरुवार को कर रहे थे! :)
इवान

2
मैं विपरीत नाव में हूं। हम पूरे विभाग के बीच एक सप्ताह के लिए आगे-पीछे बहस के बिना सर्वर को रिबूट करने की अनुमति नहीं देते हैं जो प्रति सर्वर लगभग 12 मैनहॉर्स लेता है। हां, इसमें पैचिंग के लिए रिबूट शामिल हैं, जिसका प्रभावी अर्थ है कि यह कभी नहीं किया जाता है।
हयपी

19
साप्ताहिक को फिर से शुरू करने से हार्डवेयर विफलताओं में भारी वृद्धि नहीं होनी चाहिए।
जेम्सरेन

3
ऐसा लगता है कि आपके सर्वर मेरे लैपटॉप की तुलना में अधिक बार रिबूट हो जाते हैं। जब मैं इसका उपयोग नहीं कर रहा होता हूं तो मैं इसे आमतौर पर स्लीप मोड में रखता हूं। रिबूट करने का सामान्य कारण विंडोज़ अपडेट या सॉफ़्टवेयर स्थापित करना है।
फिल

जवाबों:


116

मेरे बॉस का कहना है कि सर्वर को कम से कम साप्ताहिक रूप से फिर से शुरू करने की आवश्यकता है

मैं दृढ़ता से असहमत हूं । स्थिरता और अपटाइम के संबंध में गुड-ओले [एनटी, किसी?] दिनों से माइक्रोसॉफ्ट ने काफी प्रगति की है। यह शर्म की बात है कि आईटी समर्थन में आम सहमति इसके साथ नहीं बदली है।

कितनी बार हर कोई अपने विंडोज सर्वर को पुनरारंभ करता है?

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

क्या कोई उद्योग मानक या सिफारिश है?

मैंने कभी भी एक मानक सिफारिश नहीं देखी है, प्रति से , लेकिन मैं किसी भी सिफारिश से सहमत नहीं हो सकता था [एमएस को छोड़कर] जो एक विशिष्ट समय अंतराल पर "बस-क्योंकि" में आवश्यक रिबूट का संकेत देगा।

क्या आईटी विभाग यह कहने में सही है कि क्योंकि हम फिर से शुरू कर रहे हैं, इसलिए हम हार्डवेयर समस्याएँ हैं?

पुनः आरंभ करना [और, और अधिक, पावर साइकिलिंग] एक कंप्यूटर के लिए हार्डवेयर गतिविधि का सबसे तनावपूर्ण अवधि है। आपके पास सबसे अधिक सब कुछ 100% तक है - डिस्क और प्रशंसक ... ... साथ ही घटक तापमान में महत्वपूर्ण उतार-चढ़ाव। आधुनिक हार्डवेयर अविश्वसनीय रूप से लचीला है, लेकिन यह सिर्फ उछलते हुए सर्वरों के लिए एक कारण नहीं होना चाहिए, सप्ताह में कुछ बार।

1 के अलावा, मैं जब तकनीक "बस" एक असफल सेवा, या इस तरह के मामले में एक विंडोज सर्वर रिबूट "जब मैं घृणा। मुझे सेवा को फिर से चालू करने की आवश्यकता समझ में आती है, लेकिन सर्वर को शूट करने में परेशानी होने पर रिबूट अंतिम चरण होना चाहिए । पहचानना, और ठीक करना [!], असफलता का मूल कारण "मेह में लगभग परिणाम नहीं होना चाहिए , बस इसे रिबूट करें ...."


2
पूरी तरह से जवाब देने के लिए धन्यवाद। हम महीने में एक बार अपडेट करते हैं, जो जाहिर तौर पर जब हम करते हैं, तो हमें रिस्टार्ट करना होता है। मैं जवाब की सराहना करता हूं।
इवान

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

34
@ मैथ्यू: यदि वास्तव में रिबूटिंग के कारण खो जाने के कारण के बारे में क्षणिक जानकारी नहीं है, तो मूल कारण विश्लेषण का प्रदर्शन करना सब ठीक है और अच्छा है। मुझे लगता है कि मैं कई लोगों के लिए बोलता हूं जब मैं कहता हूं कि मेरे पास फेरेट-आउट के लिए एक और विस्तारित डाउनटाइम है और जब मैं "सिर्फ रिबूट" करने का फैसला करता हूं तो कई छोटी डाउनटाइम घटनाओं की तुलना में एक आउटेज के मूल कारण को ठीक करता हूं संभावित रूप से मूल कारण विश्लेषण में सहायता करने के लिए अस्थिर जानकारी का उपयोग करने की क्षमता खो देते हैं।
इवान एंडरसन

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

6
@ इवान मैं आपसे सहमत हूँ लेकिन मुझे लगता है कि घटनाओं की एक सीमा होनी चाहिए जो एक समस्या बन जाती है। जैसे अगर यह महीने में एक बार होता है और रिबूट के साथ 10 मिनट में हल हो जाता है, तो व्यवसाय कभी भी मूल कारण की परवाह नहीं कर सकता है। मुझे लगता है कि आप और मैं जानना चाहते हैं लेकिन अपटाइम मूल कारण से अधिक आयात है। हालांकि अगर यह सप्ताह में 3 बार होता है, तो यह पूरी तरह से अलग कहानी है।
जिम बी

52

यदि आप पैच लागू कर रहे हैं, तो विंडोज सर्वर को मासिक रूप से रिबूट करना होगा। आप पैच लागू कर रहे हैं, है ना? सही?


8
मुझे

3
आप केवल मासिक रूप से पैच लागू करते हैं?
जॉन गार्डनियर्स

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

2
जब अपडेट की आवश्यकता होती है तो मैं केवल विंडोज़ सर्वर को रीबूट करता हूं । कभी-कभी यह एक पैच के बिना कुछ महीनों तक चला जाएगा जिसे रिबूट की आवश्यकता होती है। हालाँकि, मेरे पास लिनक्स सर्वर हैं जो वर्षों में रिबूट नहीं हुए हैं और बिना किसी अड़चन के चलते हैं। मुझे लगता है कि मैंने अपने नेटवर्क में सबसे लंबे समय तक देखा है एक लिनक्स बॉक्स है जिसे एक कोठरी में डाल दिया गया और भूल गया (इसे स्वचालित अपडेट मिला)। मैं ssh'd और uptime 3 साल में था। एक साल बाद बिजली की आपूर्ति विफल होने के कारण इसे रिबूट किया गया था।
जेम्स

यदि यह लिनक्स, या बीएसडी था, तो आप अपने सर्वर को रिबूट की आवश्यकता के बिना पैच कर सकते हैं । आपको केवल कर्नेल अपडेट के लिए रीबूट करना होगा (और सर्वर ओरिएंटेड डिस्ट्रो के साथ, जो अनारक्षित हैं)।
स्नेकडॉक

18

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

ज़रूर, यह सर्वरों का नियमित रिबूट है, लेकिन वे डेस्कटॉप की तरह उपयोग किए जा रहे हैं।


4
एमएम ... टीएस / सिट्रिक्स मामले पर अच्छी कॉल।
ह्यपी

CCH के ऑडिट प्रबंधन सॉफ्टवेयर के साथ Citrix का उपयोग करते हुए यहां समान अनुभव।

1
मेटाफ्रेम के दिनों में भी यही बात लागू हुई, जब सिट्रिक्स ने खुद को व्यावहारिक रूप से रात में रिबूट करने की सिफारिश की।
जॉन गार्डनियर्स

हाँ, मेटाफ़्रेम ... हूफ़। मैं प्रिंटर ड्राइवर मैपिंग फ़ाइल के साथ खेलना नहीं भूलता। यह निश्चित रूप से एक आईटी प्रबंधन के नजरिए से बहुत बेहतर है।
mfinni

10

यह तकनीकी की तुलना में अधिक राजनीतिक और मनोवैज्ञानिक मुद्दा है।

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

दूसरी तरफ, लगातार रिबूट हार्डवेयर विफलता को उत्प्रेरित कर सकते हैं, लेकिन इसके कारण होने की बहुत अधिक संभावना नहीं है।


7
मेरे मालिक सेवानिवृत्त नेटवर्क प्रशासक के साथ अच्छे दोस्त हैं जिन्होंने उसे बताया कि उन्हें कम से कम साप्ताहिक रूप से रिबूट करने की आवश्यकता है ... जो बताता है कि वह उसके बारे में इतना अडिग क्यों है। जवाब के लिए धन्यवाद।
इवान

5
कोई आश्चर्य नहीं कि वह "सेवानिवृत्त" है ... कि एक व्यंजना है निकाल दिया?
KCotreau

3

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


जवाब के लिए धन्यवाद। इससे उसे मनाने में मदद करनी चाहिए।
इवान

1
मैंने विंडोज़ नेट, 2000 और 2003 के बक्से को कार्य नेटवर्क पर पाया है जो कई वर्षों से चल रहे हैं और चल रहे हैं। और हाल ही में जब तक हमारे डेटा सेंटर में एक वार्षिक पैचिंग नीति थी और 600 से अधिक सर्वरों के साथ 250+ से अधिक रेंज में बार-बार देखना असामान्य नहीं है। मेरे सर्वर (मेरे पास लगभग 120 हैं) हर Microsoft पैच होने पर अपडेट और बूट हो जाते हैं। कभी-कभी, पिछले महीने की तरह हमारे पास एक चक्र नहीं था। अपटाइम इस बात पर निर्भर करता है कि सर्वर पर क्या चल रहा है और चीजें एक साथ कितनी अच्छी तरह काम करती हैं। उस सामग्री के साथ 2003 R2 को मुझे हर 35 दिनों में रिबूट करना होगा। उसके बाद अजीब चीजें होती हैं।
क्रिस्टोफर थॉर्नटन

2

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

टाइमगेट टाइम में 32 बिट का परिणाम होता है, जो कंप्यूटर शुरू होने के बाद से मिलीसेकंड की संख्या के बराबर होता है। यह अधिकतम 49.7 दिनों में समाप्त हो जाता है।


2
एरर, नहीं। मेरे पास एक सर्वर है (पूरी तरह से अलग-थलग, भरोसेमंद नेटवर्क पर - मेरे लिए उपदेश नहीं) जो कि 14 महीनों के सर्वश्रेष्ठ भाग के लिए नहीं है।
बेन पलब्रो

3
मेरा मतलब यह नहीं था कि हर सर्वर और इंस्टेंस में यह समस्या होगी, लेकिन अगर सर्वर ऐसे सॉफ़्टवेयर का उपयोग करता है जो इन कार्यों का उपयोग करता है और इस तरह की कम्प्यूटेशनल समस्याओं का सामना नहीं करेगा।
मैथ्यू

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

1
क्या आप इस Microsoft KB की बात कर रहे हैं ?
jscott

9
Err यह एक NT 4 बग जीत 2k + है इससे पीड़ित न हों। मुझे लगता है कि हम सुरक्षित रूप से कह सकते हैं कि NT 4 2011 में मर चुका है। और अगर कोई व्यक्ति इसे चला रहा है ... वे इस लायक हैं कि उन्हें इस बिंदु पर क्या मिलता है।
ज़ीरफ़

2

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


2

Microsoft ने वर्षों से अपने सर्वर OS को बेहतर बनाने का काम किया है। और कुछ सर्वर आप 6 - 12 महीने तक चला सकते हैं इससे पहले कि वे समस्याओं का सामना करना शुरू कर दें, कुछ केवल इसे 2 - 3 महीने बनाते हैं। यह सब इस बात पर निर्भर करता है कि सर्वर किस सेवा और ऐप को चला रहे हैं। लेकिन वे सभी कुछ बिंदु पर एक समस्या होगी । विंडोज अपडेट, मेमोरी लीक, अपूर्ण सॉफ्टवेयर, कुछ कारण हैं।

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

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

मुझे लगता है कि नियमित मासिक पुनरारंभ के लिए कोई नकारात्मक पहलू नहीं है, जबकि समय के साथ अपसाइड स्पष्ट और सिद्ध होते हैं।


1

मैं अपने 'रिबूट शेड्यूल' को कॉन्फ़िगर करने के लिए विंडोज़ अपडेट पर भरोसा करता हूं। विंडोज़ को स्वयं प्रबंधित करें .. एक बार के लिए! केवल बहुत मुश्किल से ही मेमोरी लीक के कारण हमारे सेटअप के साथ रीबूट की आवश्यकता होती है ...


1

मैं एक कंपनी के साथ एक नेटवर्क व्यवस्थापक हूं जो कई विंडोज 2003 2008 सर्वरों पर काम करता है। मैं मासिक आधार पर सर्वरों को पुनः आरंभ करता हूं, आमतौर पर 3 महीने से अधिक समय तक इंतजार नहीं किया जाता है, क्योंकि उस छोटी अवधि के लिए नीचे होना बहुत महत्वपूर्ण है।

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


1

आप सभी विंडोज़ हैटर्स को औसत अपटाइम ( http://uptime.netcraft.com/up/today/top.avg.html ) द्वारा सबसे लंबे समय तक चलने वाले सिस्टम के साथ Netcraft.com साइटें देखनी चाहिए । यह उन साइटों को दिखाता है जो उनके अंतिम रिबूट के बाद से सबसे लंबे समय से चल रही हैं और शीर्ष 50 में से 95% विंडोज 2003 और 2000 मशीनें हैं। हमेशा की तरह, आपके माईलेज़ भिन्न हो सकते हैं।


लोड बैलेंसिंग के बारे में शायद आप बहुत ज्यादा नहीं जानते ...
mfinni

0

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

किसी विशिष्ट सर्वर पर चलाए गए तृतीय पक्ष एप्लिकेशन और वेब सेवाओं की गुणवत्ता और व्यवहार उनके बिना अन्य मशीनों की तुलना में होस्टिंग विंडोज मशीन के अधिक / कम लगातार पुनरारंभ की मांग का सुझाव दे सकते हैं।

वास्तव में कुछ तृतीय पक्ष एप्लिकेशन ( गैर-पूरी तरह से डिजाइन किए गए; अच्छी तरह से कोई भी हालांकि सही नहीं है! ) प्राप्त सिस्टम संसाधनों जैसे कि मेमोरी, ताले और सॉकेट्स को एक सुंदर और समय पर फैशन में जारी करने में विफल हो सकता है। उदाहरण के लिए यह कुछ दुर्घटनाग्रस्त अनुप्रयोगों, सेवाओं या ड्राइवरों [, जब पुन: भागा हुआ], को लंबित या आरंभिक स्थिति में रख सकता है जो बिना रीबूट के आसानी से तय नहीं हो सकता है।

व्यवहार में, डिस्क I / O, नेटवर्क और मेमोरी उच्च और तनाव वाले कार्यभार के तहत भूखे अनुप्रयोगों और उपलब्ध कम सिस्टम संसाधनों के साथ आपकी विंडोज मशीन लैगिंग, अस्थिर या ट्रैशिंग को प्रस्तुत कर सकती है जो आपको जल्द ही पुनः आरंभ करने का सुझाव दे सकती है।

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


-6

जब तक आप सॉफ़्टवेयर अपग्रेड नहीं करते हैं तब तक सही उत्तर कभी नहीं होता। पिछली बार मैंने अपने सर्वर को लगभग 2 साल पहले रिबूट किया था और इसका कारण बिजली की विफलता थी।


3
मुझे आशा है कि आप या तो एक लिनक्स सर्वर के बारे में बात कर रहे हैं या मुझे आशा है कि आपका सर्वर पेशेवर उपयोग में नहीं है ...
HTDutchy

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

मेरे पास कुछ NT 4 डोमेन नियंत्रक हैं जो साल में एक बार बूट होते हैं। कोई और अधिक अद्यतन और बुरे लोगों द्वारा लक्षित नहीं है किसी भी अधिक ... (वे इंटरनेट का सामना नहीं कर रहे हैं)
11'11
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.