क्या सर्वर-क्लास हार्डवेयर के लिए बर्न-इन रैम आवश्यक है?


31

इस तथ्य को ध्यान में रखते हुए कि कई सर्वर-क्लास सिस्टम ईसीसी रैम से लैस हैं , क्या उनकी तैनाती से पहले मेमोरी डीआईएमएम को जलाना आवश्यक या उपयोगी है ?

मैंने एक ऐसे वातावरण का सामना किया है जहाँ सभी सर्वर रैम को एक लंबी बर्न-इन / स्ट्रेस-टेसिंग प्रक्रिया के माध्यम से रखा गया है। इस अवसर पर सिस्टम की तैनाती में देरी हुई है और हार्डवेयर लीड-टाइम को प्रभावित करता है।

सर्वर हार्डवेयर मुख्य रूप से सुपरमाइक्रो है , इसलिए रैम विभिन्न प्रकार के विक्रेताओं से प्राप्त होता है; सीधे डेल पॉवरेज या एचपी प्रोलिएंट जैसे निर्माता से नहीं ।

क्या यह एक उपयोगी व्यायाम है? अपने पिछले अनुभव में, मैंने बस विक्रेता रैम का उपयोग बॉक्स से बाहर किया था। क्या POST मेमोरी परीक्षणों को DOA मेमोरी नहीं पकड़नी चाहिए ? मैंने ECC त्रुटियों के लिए एक DIMM के वास्तव में विफल होने से पहले जवाब दिया है, क्योंकि ECC थ्रेसहोल्ड आमतौर पर वारंटी प्लेसमेंट के लिए ट्रिगर थे।

  • क्या आप अपने रैम में जलते हैं ?
  • यदि हां, तो आप परीक्षण करने के लिए किस विधि (ओं) का उपयोग करते हैं?
  • क्या इसने तैनाती से पहले किसी समस्या की पहचान की है?
  • क्या बर्न-इन प्रक्रिया किसी भी अतिरिक्त प्लेटफ़ॉर्म स्थिरता के परिणामस्वरूप होती है जो कि कदम नहीं उठाती है?
  • किसी मौजूदा चल रहे सर्वर में RAM जोड़ते समय आप क्या करते हैं ?

जवाबों:


25

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

यहाँ छवि विवरण दर्ज करें

समय क्षैतिज अक्ष पर दर्शाया गया है, कारखाने की शिपमेंट के साथ शुरुआत और तीन अलग-अलग समय अवधि के माध्यम से जारी है:

  • प्रारंभिक जीवन विफलताएँ: अधिकांश विफलताएँ प्रारंभिक उपयोग अवधि के दौरान होती हैं। हालांकि, जैसे-जैसे समय बीतता है, विफलताओं की संख्या जल्दी से कम हो जाती है। पीले रंग में दिखाए गए प्रारंभिक जीवन की विफलता अवधि, लगभग 3 महीने है।

  • उपयोगी जीवन: इस अवधि के दौरान, विफलताएं अत्यंत दुर्लभ हैं। उपयोगी जीवन काल को नीले रंग में दिखाया गया है और इसका अनुमान 20+ वर्ष है।

  • जीवन के अंत में विफलताएं: आखिरकार, अर्धचालक उत्पाद खराब हो जाते हैं और विफल हो जाते हैं। एंड-ऑफ-लाइफ अवधि हरे रंग में दिखाया गया है

अब क्योंकि किंग्स्टन ने कहा कि उच्च असफलता-दर पहले तीन महीनों में घटित होगी (इन तीन महीनों के बाद इकाई को अच्छा माना जाता है जब तक कि यह ईओएल लगभग 15 - 20 साल बाद न हो)। उन्होंने KT2400 नामक एक इकाई का उपयोग करके एक परीक्षण तैयार किया जो उच्च वोल्टेज पर 100 डिग्री सेल्सियस पर 24 घंटे के लिए सर्वर मेमोरी मॉड्यूल का क्रूरता से परीक्षण करता है , जिसके द्वारा प्रत्येक DRAM चिप की सभी कोशिकाओं का लगातार उपयोग किया जाता है; तनाव परीक्षण के इस उच्च स्तर पर कम से कम तीन महीनों तक मॉड्यूल को बूढ़ा करने का प्रभाव होता है (जैसा कि महत्वपूर्ण अवधि से पहले नोट किया जाता है जहां अधिकांश मॉड्यूल विफलताओं को दर्शाते हैं)।

परिणाम थे:

मार्च 2004 में, किंग्स्टन ने छह महीने का परीक्षण शुरू किया, जिसमें 100 प्रतिशत सर्वर मेमोरी का परीक्षण KT2400 में किया गया था। विफलताओं में परिवर्तन को मापने के लिए परिणामों की बारीकी से निगरानी की गई। सितंबर 2004 में, सभी परीक्षण डेटा संकलित और विश्लेषण किए जाने के बाद, परिणामों से पता चला कि विफलताओं को 90 प्रतिशत तक कम कर दिया गया था। ये परिणाम उम्मीदों से अधिक थे और उत्पाद लाइन के लिए एक महत्वपूर्ण सुधार का प्रतिनिधित्व करते हैं जो पहले से ही अपनी कक्षा के शीर्ष पर था।

तो मेमोरी में जलन सर्वर मेमोरी के लिए उपयोगी क्यों नहीं है? बस, क्योंकि यह पहले से ही आपके निर्माता द्वारा किया गया है!


10
चिप निर्माता, और शायद सर्वर विक्रेता भी कुछ चिप्स का परीक्षण कर सकते हैं । लेकिन लागत कम करने के लिए इन दिनों mst घटकों का केवल नमूना-परीक्षण किया जाता है। यहां तक ​​कि अगर आपके चिप्स या पूरे डीआईएमएम का एक बार परीक्षण किया गया था, तो यह आपको नहीं बताता है कि क्या संपर्क या पीसीबी को किसी तरह से असेंबली या शिपिंग के दौरान गड़बड़ या गड़बड़ किया गया था। हमारे पास मेमोरस्टोरी बर्न-इन दो अलग-अलग सर्वरों से मेमोरी में समस्याएँ हैं, दो अलग-अलग "टियर 1" सर्वर विक्रेताओं से आउट-ऑफ-द-बॉक्स। यदि उन्होंने इसे उत्पादन के लिए बनाया होता, तो ईसीसी हमें बचा सकता था, लेकिन मूक डेटाबेस भ्रष्टाचार का परिणाम हो सकता है।
ralayter

7
यह बाथटब वक्र सिर्फ अर्धचालकों के लिए नहीं है। गुणवत्ता नियंत्रण के किसी भी डिग्री के साथ निर्मित अधिकांश घटक इसका अनुसरण करते हैं: हार्ड ड्राइव, एसएसडी, बिजली की आपूर्ति (मुख्य रूप से कैपेसिटर के कारण), प्रशंसक, आदि
voretaq7

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

@rmalayter तो आप किसी भी तरह से RAM को जलाने की वकालत करेंगे?
ewhite

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

30

नहीं।

हार्डवेयर में जलने का लक्ष्य एक घटक में विफलता को उत्प्रेरित करने के बिंदु पर जोर देना है।

मैकेनिकल हार्ड ड्राइव के साथ ऐसा करने से कुछ परिणाम मिलेंगे, लेकिन यह रैम के लिए बहुत कुछ करने वाला नहीं है। घटक की प्रकृति इस तरह की है कि पर्यावरणीय कारक और आयु रैम के पढ़ने और लिखने की तुलना में विफलताओं का कारण होने की संभावना है (यहां तक ​​कि कुछ घंटों या दिनों के लिए इसकी अधिकतम बैंडविड्थ पर) कभी भी होगा।

मान लें कि आपकी RAM उच्च गुणवत्ता वाली है, तो मिलाप पहली बार नहीं पिघलेगा जब आप वास्तव में इसका उपयोग करना शुरू करते हैं, एक जलती हुई प्रक्रिया आपको दोष खोजने में मदद नहीं करेगी।


15

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


3
एक "अवसर की कसौटी" समझ में आता है - मौका मुझे यह करना होगा। अगर यह तैनाती में देरी करने वाला है तो मैं एक खराब DIMM और ECC लाइट का जोखिम उठा सकता हूं :-)
voretaq7

2
यदि आप परिनियोजन योजना में परीक्षण का निर्माण करते हैं तो आपने स्वयं को समय दिया है, यदि आप सब कुछ उतनी ही तेजी से करते हैं जितना आप बाद की तारीख में आलोचना के लिए खुद को स्थापित कर सकते हैं। जब भी आप कर सकते हैं मजबूत हाथ प्रबंधन :)
चोपर 3

@ चॉपर 3 यदि आप एक नीति स्थापित कर रहे थे, तो क्या यह हमेशा होता है? , यह कभी नहीं है? या जब आप यह कर सकते हैं?
ewwhite

@ewwhite - मैं कहता हूँ कि बाद में, हालांकि हम इंजीनियर को मानक तैनाती योजना में शामिल करते हैं, इसलिए यह हर बार होने की संभावना है।
चॉपर 3

11

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

स्मृति को वास्तव में "तनाव-परीक्षण" करने के लिए; जब तक आप ओवरक्लॉकिंग उद्देश्यों के लिए परीक्षण नहीं कर रहे हैं, तब भी मुझे यह देखना होगा कि यह क्यों उपयोगी होगा।


MemTest86 आपको क्या बताता है? क्या आपने इस विधि का उपयोग करके इसे सर्वर में स्थापित करने से पहले RAM के मुद्दों को पाया है?
ewwhite

4
मुझे मेमेस्टी86 + के साथ बहुत सारी त्रुटियां मिली हैं जो कि BIOS और विंडोज मेमोरी डायग्नोस्टिक्स में नहीं मिलेंगी। मैं इसकी पुरजोर सलाह देता हूँ। हां, ईसीसी में वही त्रुटियां होंगी, लेकिन एक यादगार समय आपको उन सभी को समय से पहले ढूंढने में मदद करेगा।
ओवेन जॉनसन

6
मेमटेस्ट आपको बताएगा कि मेमोरी के इंटर्नल में कोई खामियां हैं या नहीं। यह बाइट्स के पैटर्न के साथ-साथ एक त्रुटि को ट्रिगर करने के प्रयास में मेमोरी में बाइट्स के यादृच्छिक सेटों को संग्रहीत करके करता है। कार्यक्रम एक "पास" चला सकता है ताकि आपको पता चल सके कि स्मृति अच्छी है लेकिन मैं आमतौर पर सुनिश्चित करने के लिए रात भर में कई पास चलाता हूं। मेमटेस्ट के बारे में अच्छी बात यह है कि यह मुझे बताता है कि सिस्टम को तैनात करने से पहले मेमोरी खराब है या नहीं। इसने कई बार RMA को ट्रिगर किया है और मुझे बहुत सारे सिरदर्द से बचाया है। एक बार मशीन को आरएसएमए मेमोरी में @ss में दर्द को तैनात किया जाता है।
अटारी 911

2
@OwenJohnson आम तौर पर जब आप MemTest86 (+) चलाते हैं, तो आप उन ECC त्रुटियों को ट्रिगर करने की उम्मीद कर रहे हैं जब आप मशीन को उत्पादन में
डालते हैं

6

मैं नहीं करता, लेकिन मैंने ऐसे लोगों को देखा है जो करते हैं। मैंने कभी नहीं देखा कि वे इससे कुछ हासिल कर रहे हैं, मुझे लगता है कि यह एक हैंगओवर या अंधविश्वास हो सकता है।

व्यक्तिगत रूप से, मैं आप की तरह हूँ कि ECC त्रुटि दर मेरे लिए अधिक उपयोगी हैं - मान लें कि RAM DOA नहीं है, लेकिन तब आपको पता चलेगा कि किसी भी तरह।


6

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

ECC ram के लिए यह कुछ भी नहीं करेगा मेमोरी कंट्रोलर खुद नहीं करेगा इसलिए यह वास्तव में कोई मतलब नहीं है। यह सिर्फ समय की बर्बादी है।

मेरे अनुभव में, जो लोग जलने पर जोर देते हैं, वे आमतौर पर बूढ़े होते हैं जिन्होंने हमेशा इसे ऐसे ही किया है और जो इसे सच में सोचने वाली चीजों के बिना आदत से बाहर रखते हैं।
या वे बूढ़े लोगों द्वारा लिखी गई निर्धारित प्रक्रिया का पालन करने वाले युवा हैं।


बुरा ज्ञान, पीढ़ियों के नीचे सौंप दिया?
ewwhite

@ewwhite हाँ, जहाँ तक मुझे पता है। और मेरे पास एक Bsc है। कंप्यूटर हार्डवेयर तकनीक में, इसलिए मुझे पता है कि मैं किस बारे में बात कर रहा हूं :-)
टन

उन सभी घटनाओं को छोड़कर जो वास्तव में त्रुटियां पाई गईं, जैसा कि धागे में दिखाया गया है। इसके अलावा, यदि यह स्पष्ट नहीं है, तो उत्पादन में सर्वर लेने से पहले या 24x7 पर चलने वाले DB सर्वर पर रैम को बदलने के लिए भागों को अलग-अलग करने में अंतर होता है। जब तक यह दिखावा नहीं है कि यह एक "बढ़ी हुई त्रुटि" है और बाकी सब सिर्फ पुराना है और कार्गो पंथ सामान है, लेकिन यह अभी भी नुकसान होने वाला है एक ऑफ़लाइन सर्वर ऑफ़लाइन है।
फ्लोरियन हीगल

1
@FlorianHeigl मैं इसकी खातिर रैम में जलने की वकालत नहीं करता, लेकिन मैं कभी भी सर्वर को प्रोडक्शन में लगाने का समर्थन नहीं करूंगा, इसके बिना कम से कम 24 घंटे तक तनाव का परीक्षण किया जाए। रैम आमतौर पर समस्या नहीं है। परतदार एचडीडी, RAID नियंत्रक, आईपीएमआई कार्ड, बिजली की आपूर्ति, सीपीयू की, वीआरएम की ... मैंने यह सब देखा है। (और अक्सर सर्वर प्रारंभिक स्थापित ठीक बच जाता है। यह लोड और / या हीथ है जो इसे तब करता है जब इसे वास्तव में काम करना पड़ता है।)
टॉनी

3

निर्भर करता है।

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

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


तुम्हारी बात में दम है। Btu चलो इसका सामना करते हैं, हम में से अधिकांश कभी भी उस बड़े की तैनाती नहीं करेंगे। (जब तक आप एक नया Google डेटा-केंद्र नहीं बना रहे हैं।) हम में से अधिकांश आमतौर पर एक ही समय में अधिकतम 5 से 10 सर्वरों पर तैनात होते हैं। सबसे बड़ा एक जो मैंने व्यक्तिगत रूप से किया था वह 16 ईएसएक्स नोड्स (4x 4-नोड क्लस्टर) थे, जिनमें से प्रत्येक में 8 डीआईएमएम लिया गया था। यह 3 साल पहले था और तब से 1 डीआईएमएम (2 महीने पहले) विफल रहा। उन्हीं मशीनों पर 5 बिजली-आपूर्ति को बदलना था। पहले से ही एक सप्ताह के बाद पहले 1। लेकिन ये एचपी प्रोलिएंट हैं जिनकी हम उम्मीद करते हैं। (एचपी और बिजली की आपूर्ति .. मुझे शुरू कर दिया मत हो ...)
Tonny
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.