कैसे ढेर अतिप्रवाह काम करता है - लोहा

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

आंकड़े

• 148,084,883 HTTP हमारे लोड बैलेंसर के लिए अनुरोध करता है
• 36,095,312 जिनमें से सच्चे पृष्ठ लोड हैं
• 833,992,982,627 बाइट्स (776 GB) HTTP ट्रैफ़िक भेजा गया
• 286,574,644,032 बाइट्स (267 जीबी) ट्रैफ़िक प्राप्त हुए
• 1,125,992,557,312 बाइट्स (1,048 जीबी) ट्रैफ़िक भेजा गया
• HTTP प्रश्नों के लिए 334,572,103 SQL प्रश्न
• 412,865,051 रिडिस सर्वर से अनुरोध
• टैग हैंडलर (अलग सेवा) के लिए 3,603,418 अनुरोध
• 558,224,585 एमएस (155 घंटे) एसक्यूएल प्रश्नों को संसाधित करने में खर्च किया गया था
• 99,346,916 एमएस (27 घंटे) में रेडिस सर्वर से प्रतिक्रिया के लिए इंतजार करना पड़ा
• टैग द्वारा अनुरोध प्रसंस्करण पर 132,384,059 एमएस (36 घंटे) बीत गए
• 2,728,177,045 एमएस (757 घंटे) ASP.Net स्क्रिप्ट ने काम किया

हमें निश्चित रूप से एक पोस्ट लिखने की आवश्यकता होगी कि हमें ये नंबर कैसे मिलते हैं, लेकिन इन आँकड़ों (यातायात को छोड़कर) की गणना केवल HTTP लॉग्स के लिए की जाती है। एक दिन में इतने घंटे कैसे हो गए? हम इसे जादू कहते हैं। अधिकांश लोग इसे "मल्टी-कोर प्रोसेसर के साथ कई सर्वर" कहते हैं, लेकिन हम इसे जादू की विशेषता देते हैं। स्टैक एक्सचेंज निम्न हार्डवेयर पर चलता है:

• 4 एमएस SQL ​​सर्वर
• 11 IIS वेब सर्वर
• 2 रेडिस सर्वर
• 3 सर्वर टैग प्रसंस्करण में शामिल हैं (उदाहरण के लिए अनुरोधों से संबंधित सभी चीजें (उदाहरण के लिए अनुरोध / प्रश्न / टैग / सी ++ )
• 3 लोचदार खोज सर्वर
• 2 लोड बैलेन्सर ( HAProxy कार्यान्वयन)
• 2 स्विच (प्रत्येक नेक्सस 5596 + फैब्रिक एक्सटेंडर पर आधारित)
• 2 सिस्को 5525-एक्स एएसएएस फ़ायरवॉल
• 2 सिस्को 3945 राउटर

पहली फोटो (ऊपर) में यह सब कैसे दिखता है।

हम केवल हमारी साइटों की मेजबानी नहीं कर रहे हैं। निकटतम रैक वर्चुअलाइजेशन (vmware) और सहायक बुनियादी ढांचे के लिए एक सर्वर है, जो सीधे सेवा के संचालन को प्रभावित नहीं करता है, उदाहरण के लिए, तैनाती मशीन, डोमेन नियंत्रक, निगरानी, ​​प्रशासकों के लिए एक अतिरिक्त डेटाबेस इत्यादि। ऊपर दी गई सूची से 2 SQL सर्वर हाल तक बैकअप सर्वर थे - अब उनका उपयोग केवल-पढ़ने के लिए क्वेरी के लिए किया जाता है, ताकि हम लंबे समय तक डेटाबेस लोड के बारे में चिंता किए बिना पैमाने पर जारी रख सकें। उस सूची के 2 वेब सर्वर विकास और परिधीय कार्यों के लिए डिज़ाइन किए गए हैं, इसलिए वे बहुत कम ट्रैफ़िक का उपभोग करते हैं।

उपकरण के बारे में

यदि इस समय हम कल्पना करते हैं कि कुछ हुआ है और बुनियादी ढांचे के सभी अतिरेक चला गया है, तो पूरे स्टैक एक्सचेंज प्रदर्शन में नुकसान के बिना निम्नलिखित उपकरणों पर काम कर सकते हैं:

• 2 SQL सर्वर (एक मशीन पर ढेर अतिप्रवाह, दूसरे पर सब कुछ, हालांकि हमें यकीन है कि वे एक सर्वर पर काम कर सकते हैं)
• 2 वेब सर्वर (शायद तीन, लेकिन मेरा मानना ​​है कि दो पर्याप्त होंगे)
• 1 रेडिस सर्वर
• टैग प्रसंस्करण के लिए 1 सर्वर
• 1 इलास्टिक खोज सर्वर
• 1 लोड बैलेंसर
• 1 स्विच
• 1 एएसए ब्रांडमॉयर
• 1 राउटर

हमें विशेष रूप से व्यवहार में सत्यापित करने के लिए कुछ सर्वरों को डिस्कनेक्ट करने का प्रयास करना होगा। :)

नीचे औसत हार्डवेयर कॉन्फ़िगरेशन है:

• SQL सर्वर 384 GB RAM पर 1.8 GB फ़ाइल संग्रहण (SSD) के साथ चलता है
• रेडिस सर्वर 96 जीबी रैम के साथ मशीनों पर चलते हैं
• इलास्टिकसर्च सर्वर - 196 जीबी रैम
• टैग प्रोसेसिंग सर्वर के लिए सबसे तेज प्रोसेसर की आवश्यकता होती है जिसे हम खरीद सकते हैं।
• स्विच - 10 जीबी प्रति पोर्ट।
• वेब सर्वर अलग नहीं हैं - 32 जीबी रैम, 2 क्वाड-कोर प्रोसेसर और प्रत्येक के लिए 300 जीबी एसएसडी स्टोरेज।
• जिन सर्वरों में 2x10 Gbit / s नेटवर्क नहीं होता है (जैसे SQL) चार 1 Gbit / s कनेक्शन से जुड़े होते हैं।

क्या 20Gbps बहुत अधिक लगता है? हां, उदाहरण के लिए, चरम पर SQL सर्वर नेटवर्क को 100-200 Mbit / s से अधिक लोड नहीं करते हैं, लेकिन बैकअप लेने के बारे में मत भूलना, टोपोलॉजी को फिर से बनाना - यह किसी भी समय आवश्यक हो सकता है और फिर नेटवर्क को पूर्ण करने के लिए उपयोग किया जाएगा। इस तरह की मेमोरी और SSD इस चैनल को पूरी तरह से डाउनलोड कर सकेंगे।

कोष

वर्तमान में हमारे पास एसक्यूएल में लगभग 2 टीबी डेटा है (18 एसएसडी के पहले क्लस्टर पर 1.06 / 1.16 टीबी और दूसरे पर 0.889 / 1.45 टीबी, जिसमें 4 एसएसडी शामिल हैं)। यह बादलों के बारे में सोचने लायक हो सकता है, लेकिन अब हम SSDs का उपयोग कर रहे हैं और डेटाबेस को लिखने का समय सचमुच 0 मिलीसेकंड है। स्मृति में एक डेटाबेस और इसके सामने दो कैश स्तर के साथ, स्टैक ओवरफ्लो में 40 से 60 का रीड-राइट अनुपात है। हां, यह सही है, यह डेटाबेस के समय का 60% लिखता है।
वेब सर्वर RAID1 में 320 जीबी एसएसडी का उपयोग करते हैं।
ElasticSearch सर्वर भी 300 GB SSDs के साथ आते हैं। यह महत्वपूर्ण है क्योंकि ओवरराइटिंग और इंडेक्सिंग अक्सर वहां किए जाते हैं।

हमने SAN का भी उल्लेख नहीं किया। यह 24 SAS 10K डिस्क और एक 2x10 Gb / s कनेक्शन के साथ DELL इक्वल लॉजिक PS6110X है । इसका उपयोग VmWare वर्चुअल सर्वर के लिए एक क्लाउड के रूप में स्टोरेज के रूप में किया जाता है और साइट के साथ ही जुड़ा नहीं है। यदि यह सर्वर क्रैश हो जाता है, तो साइटों को इसके बारे में कुछ समय के लिए पता भी नहीं चलेगा।

आगे क्या है?

इससे हम क्या करेंगे? हम अधिक प्रदर्शन चाहते हैं - यह हमारे लिए बहुत महत्वपूर्ण है। 12 नवंबर को, पृष्ठ औसत 28 मिलीसेकंड पर लोड हुआ। हम डाउनलोड गति को 50 मिलीसेकंड से अधिक नहीं रखने का प्रयास करते हैं। उस दिन लोकप्रिय पृष्ठों के औसत लोड आँकड़े यहां दिए गए हैं:

• उत्तर वाले प्रश्न पृष्ठ - 28 मिलीसेकंड (29.7 मिलियन अनुरोध)
• उपयोगकर्ता प्रोफ़ाइल - 39 मिलीसेकंड (1.7 मिलियन। अनुरोध)
• सवालों की सूची - 78 मिलीसेकंड (1.1 मिलियन अनुरोध)
• मुखपृष्ठ 65 मिलीसेकंड (1 मिलियन अनुरोध) है, जो बहुत धीमा है। हम जल्द ही इसे ठीक कर लेंगे।

हम समय की रिकॉर्डिंग करके डाउनलोड गति की निगरानी करते हैं। इसके लिए धन्यवाद, हम एक बहुत ही दृश्य कार्यक्रम तैयार कर सकते हैं:

भविष्य में स्केलेबिलिटी

जाहिर है, सभी सेवाएं अब कम लोड पर संचालित होती हैं। वेब सर्वर औसतन 5-15% प्रोसेसर, 15.5 जीबी रैम और 20-40 एमबी / एस नेटवर्क बैंडविड्थ का उपभोग करते हैं। डेटाबेस सर्वर का औसत प्रोसेसर लोड 5-10%, 365 जीबी रैम और 100-200 एमबी / एस नेटवर्क बैंडविड्थ है। इसके लिए धन्यवाद, हम पूरी तरह से विकसित हो सकते हैं और, बहुत महत्वपूर्ण बात, हम बढ़ते भार के मामले में गिरने के खिलाफ बीमा करते हैं - कोड में एक त्रुटि या अन्य विफलता।

यहाँ Opserver से एक स्क्रीनशॉट है:



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

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