6 पाठ gitlab.com में एक बड़ी समस्या का हल खोजने से सीखे। भाग २

हम आपके ध्यान में समय के अत्याचार के खिलाफ gitlab.com टीम के संघर्ष पर सामग्री के अनुवाद का दूसरा भाग प्रस्तुत करते हैं।



→ यहाँ, वैसे, पहला भाग है ।

रिक्वेस्ट प्रोसेसिंग स्पीड लिमिट

इस बिंदु पर, हम केवल MaxStartups पैरामीटर के मूल्यों को बढ़ाने में रुचि नहीं रखते थे। यद्यपि इस पैरामीटर में 50% की वृद्धि अच्छी साबित हुई, लेकिन पर्याप्त कारण के बिना इसकी और वृद्धि समस्या के बजाय कच्चे समाधान की तरह लग रहा था। निश्चित रूप से कुछ और था जो हम कर सकते थे।

खोजों ने मुझे HAProxy स्तर पर लाया, जो SSH सर्वरों के सामने स्थित था। HAProxy में एक अच्छा rate-limit sessions विकल्प है जो सिस्टम के उस हिस्से को प्रभावित करता है जो आने वाले अनुरोधों को स्वीकार करता है। यदि यह विकल्प कॉन्फ़िगर किया गया है, तो इसका उपयोग प्रति सेकंड नए टीसीपी अनुरोधों की संख्या को सीमित करने के लिए किया जाता है, जो कि सीक्वेंस अतिरिक्त आवक कनेक्शन को टीसीपी सॉकेट पर छोड़ते हुए बैकएंड को भेजता है। यदि आने वाले अनुरोधों की गति सीमा से अधिक हो जाती है (प्रत्येक मिलीसेकंड बदल जाती है), तो नए कनेक्शन बस विलंबित होते हैं। टीसीपी क्लाइंट (इस मामले में, एसएसएच) बस टीसीपी कनेक्शन स्थापित करने से पहले देरी देखता है। यह, मेरी राय में, एक बहुत ही सुंदर कदम है। जिस गति से अनुरोध प्राप्त होते हैं, उस समय तक, बहुत अधिक समय के लिए, सीमा बहुत अधिक होने से, सिस्टम अच्छी तरह से काम करेगा।

अगला प्रश्न rate-limit sessions विकल्प के मूल्य का चयन था, जिसका हमें उपयोग करना चाहिए। इस प्रश्न का उत्तर खोजना इस तथ्य से जटिल था कि हमारे पास 27 SSH बैकएंड और 18 HAProxy फ्रंटेंड्स (16 मुख्य और 2 ऑल-एसश) हैं, साथ ही तथ्य यह है कि फ्रंट रिक्वेस्ट प्रोसेसिंग की गति के संबंध में एक-दूसरे के साथ समन्वय नहीं करते हैं। । इसके अलावा, हमें इस बात पर ध्यान देना होगा कि नए SSH सत्र के प्रमाणीकरण कदम में कितना समय लगता है। मान लीजिए कि MaxStartups का पहला मूल्य 150 है। इसका मतलब है कि यदि प्रमाणीकरण चरण में दो सेकंड लगते हैं, तो हम प्रत्येक बैकेंड के प्रत्येक 75 नए सत्र को प्रति सेकंड स्थानांतरित कर सकते हैं। यहां आप rate-limit sessions के मूल्य की गणना के बारे में विवरण पा सकते हैं, मैं यहां विवरण में नहीं जाऊंगा। मैं केवल यह ध्यान देता हूं कि इस मान की गणना करने के लिए, चार मापदंडों को ध्यान में रखा जाना चाहिए। पहला और दूसरा दोनों प्रकार के सर्वरों की संख्या है। तीसरा MaxStartups का मान है। चौथा T - SSH सत्र को प्रमाणित करने में कितना समय लगता है। T मान अत्यंत महत्वपूर्ण है, लेकिन इसे केवल लगभग घटाया जा सकता है। हमने सिर्फ 2 सेकंड में परिणाम छोड़ दिया। नतीजतन, हमें फ्रंट-एंड के लिए rate-limit मान मिला, जो 112.5 था। हमने इसे 110 पर गोल किया।

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

परिणामस्वरूप, हम लॉग में वापस चले गए (और, अंत में, HAProxy जानकारी के लिए) और यह सुनिश्चित करने में सक्षम थे कि क्वेरी प्रोसेसिंग गति सीमा कम से कम काम करती है जैसा कि हम उम्मीद करते हैं। पहले, संबंधित संकेतक अधिक थे, इससे हमें यह निष्कर्ष निकालने की अनुमति मिली कि हम उस गति को सफलतापूर्वक सीमित कर देते हैं जिसके साथ प्रसंस्करण के लिए आने वाले अनुरोध भेजे जाते हैं। लेकिन यह स्पष्ट था कि जिस दर पर अनुरोध आए थे वह अभी भी बहुत अधिक है। हालांकि यह भी स्पष्ट था कि यह उन स्तरों के करीब भी नहीं आया था जब यह सिस्टम पर ध्यान देने योग्य प्रभाव डाल सकता था। जब हमने बैकएंड्स का चयन करने की प्रक्रिया का विश्लेषण किया (HAProxy लॉग्स के अनुसार), तो हमने वहां एक अजीबता देखी। घंटे की शुरुआत में, बैकएंड कनेक्शन असमान रूप से SSH सर्वरों में वितरित किए गए थे। विश्लेषण के लिए चुने गए समय अंतराल में, विभिन्न सर्वरों पर प्रति सेकंड कनेक्शन की संख्या 30 से 121 तक भिन्न होती है। और इसका मतलब है कि हमारे लोड संतुलन ने अपना काम अच्छी तरह से नहीं किया। कॉन्फ़िगरेशन के विश्लेषण से पता चला कि हमने balance source विकल्प का उपयोग किया है, ताकि एक विशिष्ट आईपी पते वाला ग्राहक हमेशा एक ही बैकएंड से जुड़ा हो। यह उन मामलों में एक सकारात्मक घटना के रूप में माना जा सकता है जहां सत्र बंधन की आवश्यकता होती है। लेकिन हम एसएसएच के साथ काम कर रहे हैं, इसलिए हमें इसकी जरूरत नहीं है। यह विकल्प एक बार हमारे द्वारा कॉन्फ़िगर किया गया था, लेकिन हमें ऐसा कोई संकेत नहीं मिला कि यह क्यों किया गया था। हमें इसका उपयोग करने के लिए एक योग्य कारण नहीं मिला। नतीजतन, हमने कम से कम स्विच करने का फैसला किया। इस विकल्प के लिए धन्यवाद, नए आने वाले कनेक्शन वर्तमान कनेक्शन की न्यूनतम संख्या के साथ बैकएंड देते हैं। इसने हमारे SSH (Git) सर्वरों द्वारा प्रोसेसर संसाधनों के उपयोग को प्रभावित किया। यहाँ इसी अनुसूची है।


सबसे कम विकल्प को लागू करने से पहले और बाद में सर्वर द्वारा सीपीयू की खपत

यह देखने के बाद, हमें पता चला कि कम से कम उपयोग करना एक अच्छा विचार है। ग्राफ़ के निचले भाग में जो दो लाइनें हैं, वे हमारे कैनरी सर्वर हैं, आप उन्हें अनदेखा कर सकते हैं। लेकिन इससे पहले, विभिन्न सर्वरों के लिए सीपीयू लोड मूल्यों के प्रसार को 2: 1 (30% से 60% तक) के रूप में सहसंबद्ध किया गया था। यह स्पष्ट रूप से इंगित करता है कि पहले हमारे कुछ बैकेंड ग्राहकों के कनेक्शन के कारण दूसरों की तुलना में अधिक लोड किए गए थे। यह मेरे लिए एक आश्चर्य के रूप में आया। यह अपेक्षा करना उचित प्रतीत होता है कि क्लाइंट IP पतों की एक विस्तृत श्रृंखला हमारे सर्वर को अधिक समान रूप से लोड करने के लिए पर्याप्त थी। लेकिन, जाहिर है, सर्वर लोड संकेतकों को विकृत करने के लिए, कई बड़े ग्राहक पर्याप्त थे, जिनमें से व्यवहार कुछ औसत विकल्प से भिन्न होता है।

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

यह पारदर्शिता GitLab के मुख्य मूल्यों में से एक है ।

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

यह देखते हुए कि क्वेरी प्रोसेसिंग गति एक निम्न स्तर पर सेट की गई थी जो हमें सूट करती है, और हम कम से कम उपयोग नहीं कर सकते, हमने MaxStartups पैरामीटर को बढ़ाने की कोशिश की। पहले तो हमने इसे बढ़ाकर 200 कर दिया, इससे कुछ असर हुआ। फिर 250 तक। त्रुटियाँ लगभग पूरी तरह से गायब हो गईं और कुछ भी बुरा नहीं हुआ।

पाठ संख्या ५। हालांकि हाई मैक्सस्टार्टअप्स डराने वाले दिख सकते हैं, डिफ़ॉल्ट प्रदर्शन की तुलना में बहुत अधिक होने पर भी उनके प्रदर्शन पर बहुत कम प्रभाव पड़ता है।

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

यह T पैरामीटर के मेरे अनुमानों के बारे में क्या कहता है, एसएसएच सत्र को स्थापित करने और प्रमाणित करने में कितना समय लगता है? यदि आप कनेक्शन प्रसंस्करण गति सीमा संकेतक की गणना के लिए सूत्र के साथ काम करते हैं, तो यह जानकर कि MaxStartups संकेतक के लिए 200 पर्याप्त नहीं है, और 250 पर्याप्त है, आप यह पता लगा सकते हैं कि T का मूल्य संभवतः 2.7 से 3.4 सेकंड तक है। परिणामस्वरूप, 2 सेकंड का अनुमानित मूल्य सच्चाई से बहुत दूर नहीं था, लेकिन वास्तविक मूल्य, निश्चित रूप से, अपेक्षा से अधिक था। हम थोड़ी देर बाद इस पर वापस आएंगे।

अंतिम चरण

हमने फिर से लॉग पर ध्यान दिया, जो कि हम पहले से ही जानते थे, और कुछ प्रतिबिंब के बाद, यह पता चला कि जिस समस्या के साथ यह शुरू हुआ था, उसे निम्नलिखित संकेतों द्वारा पहचाना जा सकता है। सबसे पहले, यह SD बराबर एक t_state मान है। दूसरे, यह b_read (क्लाइंट द्वारा पढ़े गए बाइट्स) का मान है, 0. के बराबर। जैसा कि पहले ही उल्लेख किया गया है, हम प्रति दिन लगभग 26-28 मिलियन SSH कनेक्शन प्रोसेस करते हैं। यह जानना अप्रिय था कि, आपदा के बीच, इन कनेक्शनों का लगभग 1.5% सकल रूप से टूट गया था। जाहिर है, समस्या का पैमाना बहुत बड़ा था जितना हमने शुरुआत में सोचा था। इसके अलावा, ऐसा कुछ भी नहीं था जिसका हम पहले पता नहीं लगा सके (तब भी जब हमें पता चला कि t_state="SD" ने लॉग में समस्या का संकेत दिया है), लेकिन हमने यह नहीं सोचा कि यह कैसे करना है, हालांकि हम और आपको इसके बारे में सोचना चाहिए। संभवतः इस वजह से, हमने जितना समय खर्च किया है, उससे अधिक समस्या को सुलझाने में अधिक समय और प्रयास खर्च करना होगा।

पाठ संख्या ६। जितनी जल्दी हो सके वास्तविक त्रुटि स्तरों को मापें।

यदि हमें शुरुआत में समस्या के बारे में पता था, तो हम इस पर अधिक ध्यान दे सकते हैं। हालांकि, इसे कैसे देखा जाए, फिर भी विशेषताओं के ज्ञान पर निर्भर करता है जो हमें समस्याओं का वर्णन करने की अनुमति देता है।

अगर हम MaxStartups के मूल्यों में वृद्धि के बाद दिखाई देने वाले लाभों के बारे में बात करते हैं और प्रसंस्करण अनुरोधों की गति को देखते हैं, तो हम कह सकते हैं कि त्रुटि स्तर 0.001% तक गिर गया। वह है - एक दिन में कई हजार तक। यह स्थिति बहुत बेहतर दिख रही थी, लेकिन त्रुटियों का एक समान स्तर अभी भी हम जिस तक पहुंचना चाहते हैं, उससे अधिक था। हमने कुछ चीजों का पता लगाने के बाद, हम फिर से सबसे leastconn विकल्प का उपयोग करने में सक्षम थे और त्रुटियों को पूरी तरह से गायब कर दिया। उसके बाद, हम राहत की सांस ले पाए।

भविष्य का काम

जाहिर है, SSH प्रमाणीकरण चरण में अभी भी बहुत समय लगता है। शायद 3.4 सेकंड तक। GitLab एक डेटाबेस में SSH कुंजी के लिए सीधे खोज करने के लिए AuthorizedKeysCommand का उपयोग कर सकते हैं। बड़ी संख्या में उपयोगकर्ताओं के त्वरित संचालन के लिए यह बहुत महत्वपूर्ण है। अन्यथा, SSHD को उपयोगकर्ता की सार्वजनिक कुंजी खोजने के लिए क्रमिक रूप से एक बहुत बड़ी authorized_keys फ़ाइल पढ़ने की आवश्यकता है। यह कार्य ठीक नहीं है। हमने एक निश्चित मात्रा में रूबी कोड का उपयोग करके एक खोज को कार्यान्वित किया जो बाहरी HTTP API पर कॉल करता है। हमारे इंजीनियरिंग विभाग के प्रमुख और गिटलैब पर ज्ञान के एक अटूट स्रोत स्टैन ह्यूग ने पाया कि जीआईटी / एसएसएच सर्वरों के यूनिकॉर्न इंस्टेंसेस उनके द्वारा किए गए अनुरोधों से निरंतर भार के अधीन हैं। यह अनुरोधों को प्रमाणित करने के लिए आवश्यक तीन सेकंड के लिए महत्वपूर्ण योगदान दे सकता है। परिणामस्वरूप, हमें एहसास हुआ कि भविष्य में हमें इस मुद्दे की जांच करनी चाहिए। शायद हम इन नोड्स पर यूनिकॉर्न (या प्यूमा) उदाहरणों की संख्या में वृद्धि करेंगे ताकि एसएसएच सर्वरों को उन्हें एक्सेस करने के लिए इंतजार न करना पड़े। हालांकि, यहां एक निश्चित जोखिम है, इसलिए हमें सावधानी बरतने और सिस्टम संकेतकों के संग्रह और विश्लेषण पर ध्यान देने की आवश्यकता है। उत्पादकता पर काम जारी है, लेकिन अब, मुख्य समस्या हल होने के बाद, चीजें धीमी हो रही हैं। हम MaxStartups के मूल्य को कम करने में सक्षम हो सकते हैं, लेकिन चूंकि इसका उच्च स्तर उस सिस्टम पर नकारात्मक प्रभाव पैदा नहीं करता है जो इसे बनाने लगता है, यह विशेष रूप से आवश्यक नहीं है। सभी के लिए जीना आसान होगा अगर ओपनएसएसएच किसी भी समय हमें बता सकता है कि हम MaxStartups की सीमाओं के कितने करीब हैं। बेहतर होगा कि हम हमेशा सकते में रहें। यह सीखने की तुलना में बहुत अच्छा है कि टूटे हुए कनेक्शन के साथ सीमाएं पार हो जाती हैं।

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

परिणाम

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

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

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

प्रिय पाठकों! क्या आपको समस्याओं का सामना करना पड़ा है जिनकी कहानी इस सामग्री के लिए समर्पित है?