जिस दिन डोडो आईएस रुका। अतुल्यकालिक स्क्रिप्ट

नमस्कार, हेब्र! हमारी टीम के प्रत्येक एसआरई ने एक बार रात में शांति से सोने का सपना देखा। सपने सच होते हैं। इस लेख में मैं इस बारे में बात करूंगा और हम अपने डोडो आईएस प्रणाली के प्रदर्शन और स्थिरता को कैसे प्राप्त करेंगे।

डोडो आईएस * प्रणाली के पतन के बारे में लेखों की एक श्रृंखला :

1. जिस दिन डोडो आईएस रुका। समकालिक लिपि।
2. जिस दिन डोडो आईएस रुका। अतुल्यकालिक स्क्रिप्ट।

* मास्को में डॉटनेक्स्ट 2018 में मेरे प्रदर्शन के आधार पर सामग्री लिखी गई ।

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

हम शब्द संगामिति का परिचय देते हैं

इससे पहले कि आप async करने के लिए, आप शब्द संगामिति दर्ज करना होगा।

कतारबद्ध सिद्धांत में, कंजेरिअन उन ग्राहकों की संख्या है जो वर्तमान में सिस्टम के अंदर हैं। समसामयिकता कभी-कभी समानांतरवाद के साथ भ्रमित होती है, लेकिन वास्तव में ये दो अलग-अलग चीजें हैं।

पहली बार कॉनएरेबिलिटी के नए लोगों के लिए, मैं रोब पाइक के वीडियो की सिफारिश करता हूं । जब हम एक ही समय में कई चीजों के साथ काम कर रहे होते हैं, और जब हम एक ही समय में कई चीजें कर रहे होते हैं, तब समानता होती है।

कंप्यूटर में, कई चीजें समानांतर में नहीं होती हैं। ऐसी एक चीज कई प्रोसेसर पर कंप्यूटिंग है। समानांतरता की डिग्री सीपीयू थ्रेड्स की संख्या से सीमित है।

वास्तव में, थ्रेड्स प्रीमेप्टिव मल्टीटास्किंग कॉन्सेप्ट का एक हिस्सा है, एक प्रोग्राम में कॉन्सिलर को मॉडल करने का एक तरीका है जब हम कॉन्सैरेक्ट प्रश्न में ऑपरेटिंग सिस्टम पर भरोसा करते हैं। यह मॉडल तब तक उपयोगी रहता है जब तक हम समझते हैं कि हम विशेष रूप से कॉनक्युलर मॉडल के साथ काम कर रहे हैं, न कि कंसीडर के साथ।

Async / प्रतीक्षारत स्टेट मशीन के लिए सिन्सेटिक शुगर है, एक और उपयोगी कंसीलर मॉडल जो एकल-थ्रेडेड वातावरण में चल सकता है। संक्षेप में, यह सहकारिता मल्टीटास्किंग है - मॉडल खुद को समानतावाद को बिल्कुल भी ध्यान में नहीं रखता है। मल्टीथ्रेडिंग के संयोजन में, हमें एक मॉडल दूसरे के ऊपर मिलता है, और जीवन बहुत जटिल है।

दो मॉडलों की तुलना

यह प्रीमेप्टिव मल्टीटास्किंग मॉडल में कैसे काम करता है

मान लीजिए कि हमारे पास प्रति सेकंड प्रोसेसिंग में 20 थ्रेड्स और 20 अनुरोध हैं। तस्वीर एक ही समय में सिस्टम में एक चोटी - 200 अनुरोधों को दिखाती है। यह कैसे हो सकता है:

• अनुरोधों को समूहीकृत किया जा सकता है यदि एक ही समय में 200 ग्राहकों ने एक बटन क्लिक किया हो;
• कचरा संग्राहक कई दसियों मिलीसेकंड के अनुरोधों को रोक सकता है;
• यदि प्रॉक्सी कतार का समर्थन करता है तो अनुरोधों को किसी भी कतार में विलंबित किया जा सकता है।

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

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



इस स्थिति में, सर्वर का कॉन्सिलिअर लेवल बाहरी सिस्टम = 200 के दृष्टिकोण से है। सर्वर को पहले ही ये अनुरोध मिल चुके हैं, लेकिन अभी तक इसे पूरा नहीं किया है। हालाँकि, मल्टीथ्रेडिंग प्रतिमान में चल रहे एक आवेदन के लिए, एक साथ अनुरोधों की संख्या थ्रेड पूल के वर्तमान आकार = 20 से सीमित है। इसलिए, हम कॉन्सिरेन्सी = 20 की डिग्री के साथ काम कर रहे हैं।

कैसे अब सब कुछ async मॉडल में काम करता है

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



हमारे आवेदन के लिए इसका क्या अर्थ होगा? बाहरी चित्र समान है - Concurrency = 200 का स्तर। उसी समय, अंदर की स्थिति बदल गई है। पहले, अनुरोध थ्रेडपूल कतार में "भीड़" थे, अब आवेदन कॉन्सिलिअरी की डिग्री भी 200 है, क्योंकि हमारे पास टास्कसीड्यूलर के हिस्से पर कोई प्रतिबंध नहीं है। हुर्रे! हमने Async के लक्ष्य को प्राप्त कर लिया है - आवेदन "सामना" लगभग किसी भी डिग्री के साथ है!

परिणाम: सिस्टम की गैर-गिरावट

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

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

ऐसा क्यों हो रहा है?

दूसरे क्रम के कारण:

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

पहला आदेश कारण:

• विवाद, जिस पर पिछले लेख में थोड़ी चर्चा की गई थी।

अंत में, async सीमित संसाधनों के खिलाफ लड़ता है और ... जीतता है! डेटाबेस विफल हो जाता है और धीमा होने लगता है। इस से, सर्वर आगे बढ़कर कॉनक्यूरेन्सी बढ़ाता है, और सिस्टम अब सम्मान के साथ इस स्थिति से बाहर नहीं निकल सकता है।

सर्वर सडन डेथ सिंड्रोम

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

सिस्टम क्यों मर गया?

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

अलंकारिक प्रश्न: क्या सर्वर अत्यधिक लोड के कारण टूटना चाहिए था? क्या वे ऐसा करते हैं?

हम एक सर्वर क्रैश स्थिति का अनुकरण करते हैं

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

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

आइए एक मॉडल बनाने की कोशिश करें जो गणितीय रूप से लोड के तहत सर्वर की तरह काम करता है। अगला, हम सर्वर की विशेषताओं का अध्ययन करेंगे। हम वास्तविक सर्वरों की गैर-मौजूदगी को त्याग देते हैं और ऐसी स्थिति का अनुकरण करते हैं जहां रेखीय मंदी तब होती है जब लोड नाममात्र से ऊपर हो जाता है। आवश्यकतानुसार दो बार अनुरोध - हम दो बार धीमी गति से सेवा करते हैं।

यह दृष्टिकोण अनुमति देगा:

• विचार करें कि सबसे अच्छा क्या होगा;
• सटीक मेट्रिक्स लें।

अनुसूचित नेविगेशन:

• नीला - सर्वर से अनुरोधों की संख्या;
• हरा - सर्वर प्रतिक्रियाएं;
• पीला - टाइमआउट;
• डार्क ग्रे - रिक्वेस्ट जो सर्वर रिसोर्स पर होती हैं क्योंकि क्लाइंट टाइमआउट के जवाब का इंतजार नहीं करता था। कभी-कभी एक ग्राहक डिस्कनेक्ट द्वारा सर्वर को यह रिपोर्ट कर सकता है, लेकिन सामान्य तौर पर, इस तरह की लक्जरी तकनीकी रूप से संभव नहीं हो सकती है, उदाहरण के लिए, यदि सर्वर क्लाइंट के साथ सहयोग के बिना सीपीयू-बाउंड काम करता है।

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

केस "विश्व कप"

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

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

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

इस बीच, संपर्क केंद्र सर्वर धीरे-धीरे झुकना शुरू कर देता है और अधिक से अधिक धीरे-धीरे अनुरोधों की सेवा करता है। सिस्टम घटक, इस मामले में, कॉल सेंटर वेब सर्वर, अस्थिर है।

मैच खत्म होने पर तीसरी चोटी आएगी। प्रशंसक और सिस्टम दंड का इंतजार कर रहे हैं।

हम सर्वर क्रैश के कारणों का विश्लेषण करते हैं

क्या हुआ? सर्वर 100 सशर्त अनुरोधों को पकड़ सकता है। हम समझते हैं कि यह इस शक्ति के लिए बनाया गया है और अब इसे खड़ा नहीं करेगा। एक शिखर आता है, जो अपने आप में इतना बड़ा नहीं है। लेकिन Concurrency का ग्रे क्षेत्र बहुत अधिक है।

मॉडल को इसलिए डिज़ाइन किया गया है कि Concurrency संख्यात्मक रूप से प्रति सेकंड ऑर्डर की संख्या के बराबर है, इसलिए ग्राफ़ पर नेत्रहीन यह समान पैमाने का होना चाहिए। हालाँकि, यह बहुत अधिक है क्योंकि यह जम जाता है।

हम यहां ग्राफ़ से एक छाया देखते हैं - ये अनुरोध हैं जो क्लाइंट को लौटाना शुरू कर दिया, निष्पादित (पहले लाल तीर द्वारा दिखाया गया है)। समय ऑफसेट को देखने के लिए समय स्केल सशर्त है। दूसरी चोटी ने पहले ही हमारा सर्वर खटखटाया है। वह दुर्घटनाग्रस्त हो गया और सामान्य से चार गुना कम अनुरोधों को संसाधित करना शुरू कर दिया।



ग्राफ़ के उत्तरार्ध में, यह स्पष्ट है कि कुछ अनुरोधों को अभी भी पहले निष्पादित किया गया था, लेकिन फिर पीले धब्बे दिखाई दिए - अनुरोध पूरी तरह से बंद हो गए।



एक बार फिर से पूरा कार्यक्रम। यह देखा जा सकता है कि कॉनक्यूरेन्सी वाइल्ड हो रही है। एक विशाल पर्वत दिखाई देता है।



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

लेकिन इतना बड़ा पहाड़ कहां से आया? सबसे बड़ी लोड चोटी लंबे समय से गुजर गई है!

थोड़ा कानून

लिटिल का नियम कॉनएरेमॉन को नियंत्रित करता है

L (सिस्टम के भीतर ग्राहकों की संख्या) = λ (उनके रहने की गति) time W (समय वे सिस्टम के अंदर खर्च करते हैं)

यह एक औसत है। हालांकि, हमारी स्थिति नाटकीय रूप से विकसित हो रही है, औसत हमें सूट नहीं करता है। हम इस समीकरण को अलग करेंगे, फिर एकीकृत करेंगे। ऐसा करने के लिए, जॉन लिटिल की पुस्तक को देखें, जिन्होंने इस सूत्र का आविष्कार किया था, और वहां अभिन्न को देखते हैं।



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



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

लेकिन कॉन्सेप्ट क्यों बढ़ रहा है? हम निरंतर के अभिन्न को देखते हैं। हमारे सिस्टम में कुछ भी नहीं बदलता है, लेकिन अभिन्न एक रेखीय फ़ंक्शन की तरह दिखता है जो केवल बढ़ता है।

क्या हम खेलेंगे?

यदि आपको गणित याद नहीं है तो इंटीग्रल्स के साथ स्पष्टीकरण जटिल है। यहां मैंने गेम को गर्म करने और खेलने का प्रस्ताव दिया।

गेम नंबर 1

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

कल्पना कीजिए कि आपको एक अनुरोध मिला है। कार्य की केवल 3 इकाइयाँ, पहली प्रसंस्करण अवधि के अंत में 2 इकाइयाँ शेष हैं।

दूसरी अवधि में, एक और अनुरोध स्तरित है, अब दोनों सीपीयू व्यस्त हैं। उन्होंने पहले दो प्रश्नों के लिए एक इकाई का काम किया। यह क्रमशः पहले और दूसरे अनुरोध के लिए 1 और 2 इकाइयों को पूरा करने के लिए बना हुआ है।

अब तीसरा अनुरोध आया है, और मज़ा शुरू होता है। ऐसा लगता है कि पहला अनुरोध पूरा हो जाना चाहिए था, लेकिन इस अवधि में तीन अनुरोध पहले से ही सीपीयू संसाधन साझा करते हैं, इसलिए तीनों अनुरोधों के पूरा होने की डिग्री अब तीसरी प्रसंस्करण अवधि के अंत में आंशिक है:



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

चूंकि पहला अनुरोध पूरा हो चुका है, इसलिए उसके लिए संक्षेप में प्रस्तुत करें: यह हमारी अपेक्षा से एक तिहाई लंबा था। यह माना जाता था कि प्रत्येक कार्य की लंबाई क्षैतिज रूप से आदर्श रूप से = 3, कार्य की मात्रा के अनुसार। हम इसे नारंगी के साथ चिह्नित करते हैं, एक संकेत के रूप में कि हम परिणाम से पूरी तरह से संतुष्ट नहीं हैं।



पांचवां निवेदन आता है। Concurrency की डिग्री अभी भी 4 है, लेकिन हम देखते हैं कि पांचवें कॉलम में शेष काम कुल मिलाकर अधिक है। ऐसा इसलिए है क्योंकि तीसरे की तुलना में चौथे कॉलम में अधिक काम बाकी है।

हम तीन और अवधि जारी रखते हैं। जवाब का इंतजार है।
- सर्वर, हैलो!
- ...



"आपका फोन हमारे लिए बहुत महत्वपूर्ण है ..."



खैर, आखिरकार दूसरे अनुरोध का जवाब आया। प्रतिक्रिया समय अपेक्षा के अनुसार दोगुना है।



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

हमारे सर्वर ने एक अवांछनीय स्थिति में प्रवेश किया है, जहां से यह कभी भी अपने आप से बाहर नहीं निकलेगा। खेल खत्म

सर्वर के GameOver राज्य की विशेषता क्या है?

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

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

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

और हम वास्तव में क्या उम्मीद करते थे? आखिरकार, हमने जानबूझकर सर्वर को इतनी अधिक मात्रा में काम दिया कि वह संभाल नहीं सका।

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



चलो फिर से खेलते हैं।

खेल नंबर 2

आवश्यक शर्तें : फिर से हमारे पास दो सीपीयू हैं, 3 इकाइयों के समान कार्य, प्रत्येक अवधि तक पहुंचते हैं, लेकिन अब हम बाउंसर सेट करेंगे, और कार्य स्मार्ट होंगे - यदि वे देखते हैं कि कतार की लंबाई 2 है, तो वे तुरंत घर चले जाते हैं।





तीसरा निवेदन आया। इस अवधि में वह लाइन में खड़ा है। अवधि के अंत में उसका नंबर 3 है। अवशिष्टों में कोई भिन्नात्मक संख्या नहीं होती है, क्योंकि दो सीपीयू दो कार्य करते हैं, एक अवधि के लिए।

हालाँकि हमारे पास तीन अनुरोध हैं, सिस्टम के अंदर Concurrency की डिग्री = 2. तीसरा कतार में है और उसकी गिनती नहीं है।



चौथा आया - एक ही चित्र, हालांकि अधिक काम पहले ही जमा हो चुका है।


...
...

छठी अवधि में, तीसरे अनुरोध को तीसरे अंतराल के साथ पूरा किया गया था, और कॉनकरी की डिग्री पहले से ही = 4 है।



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

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



स्थिति को अंतहीन रूप से दोहराया जा सकता है, जबकि क्वेरी निष्पादन का समय उसी स्तर पर रहता है - जब तक हम चाहेंगे, तब तक दो बार।



हम देखते हैं कि कंसीडर स्तर पर एक साधारण प्रतिबंध सर्वर व्यवहार्यता समस्या को समाप्त करता है।

कैसे संगणना स्तर सीमा के माध्यम से सर्वर व्यवहार्यता बढ़ाने के लिए

आप सबसे सरल "बाउंसर" खुद लिख सकते हैं। नीचे सेमीफोर का उपयोग करके कोड है। बाहर लाइन की लंबाई की कोई सीमा नहीं है। , .

const int MaxConcurrency = 100; SemaphoreSlim bulkhead = new SemaphoreSlim(MaxConcurrency, MaxConcurrency); public async Task ProcessRequest() { if (!await bulkhead.WaitAsync()) { throw new OperationCanceledException(); } try { await ProcessRequestInternal(); return; } finally { bulkhead.Release(); } } 

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

सबसे पहले, हम सर्वर से लोड बेंच पर संभव है, जब तक हम यह निर्धारित नहीं करते हैं कि यह कितने अनुरोधों को पकड़ सकता है, निचोड़ता है। उदाहरण के लिए, हमने निर्धारित किया कि यह 100 है। हम बल्कहेड डालते हैं।

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

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

क्वेरी प्रयोग

पिछले पोस्टमार्टम पर एक नज़र डालें, हम इसे फिर से नहीं देखेंगे।

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

100 अंदर, 100 बाहर

यह पता चला कि हमारा सर्वर बहुत अच्छी तरह से और मज़ेदार रहने लगा। वह अधिकतम शक्ति पर लगातार प्रतिज्ञा करता है। बेशक, जब कोई चोटी होती है, तो वह उसे बाहर निकाल देती है, लेकिन लंबे समय तक नहीं।

सफलता से प्रेरित होकर, हम यह सुनिश्चित करने की कोशिश करेंगे कि वह बिलकुल भी बाउंस न हो। आइए कतार की लंबाई बढ़ाने की कोशिश करें।

100 के अंदर, 500 के बाहर

यह बेहतर हुआ, लेकिन पूंछ बढ़ी। ये अनुरोध हैं जो लंबे समय बाद निष्पादित किए जाते हैं।

100 अंदर, 1000 बाहर

चूंकि कुछ बेहतर हो गया है, आइए इसे बेतुकी बात पर लाने की कोशिश करें। आइए हम एक साथ सेवा कर सकते हैं की तुलना में कतार की लंबाई 10 गुना अधिक है:



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

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

एक और जोखिम है - इस तरह के सर्वर व्यवहार के लिए अन्य सिस्टम घटकों को डिज़ाइन नहीं किया जा सकता है, और, जैसा कि हम पहले से ही जानते हैं, कॉनक्यूरिटी क्लाइंट्स पर अनुमानित है।

इसलिए, हम पहले विकल्प "100 प्रति 100" पर लौटते हैं और सोचते हैं कि अपनी क्षमताओं को कैसे बढ़ाया जाए।

विजेता - 100 अंदर, 100 बाहर

¯ \ _ (ツ) _ / ツ

इन मापदंडों के साथ, रनटाइम में सबसे बड़ी गिरावट "नाममात्र" से ठीक 2 गुना है। इसी समय, क्वेरी निष्पादन समय में यह 100% गिरावट है।

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

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

यह निर्धारित करना और भी महत्वपूर्ण है कि लेटेंसी के उतार-चढ़ाव सर्वर के साथ बातचीत करने वाले अन्य सिस्टम घटकों का सामना कर सकते हैं। इसलिए हमें पता चल जाएगा कि हम वास्तव में पूरी तरह से सेवा खोने के खतरे के बिना मौजूदा प्रणाली से अधिकतम को निचोड़ रहे हैं।

निदान और उपचार

हम बुल्केहेड अलगाव के साथ अनियंत्रित कॉन्सैरेसी का इलाज कर रहे हैं।
इस पद्धति, जैसे कि लेखों की इस श्रृंखला में चर्चा की गई है , पोली लाइब्रेरी द्वारा आसानी से लागू की जाती है ।

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

हालाँकि, हम सभी समस्याओं का समाधान नहीं करते हैं। उदाहरण के लिए, अपर्याप्त सर्वर पावर की समस्या। इस स्थिति में, आपको स्पष्ट रूप से लोड में कूद की स्थिति में "गिट्टी गिराने" का फैसला करना चाहिए, जिसे हमने अत्यधिक के रूप में मूल्यांकन किया था।

आगे के उपाय जो हमारे अध्ययन को संबोधित नहीं करते हैं, उदाहरण के लिए, गतिशील स्केलिंग शामिल हो सकते हैं।