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

एक बार मैं एल्विन की बड़ी देरी के कारण एक असंतुष्ट पत्र से उठा, जिसे हमने निकट भविष्य में लॉन्च करने की योजना बनाई थी। विशेष रूप से, क्लाइंट को हमारे विलंब बजट के ऊपर, लगभग ५० से ९ ० सेंटीमीटर की देरी का सामना करना पड़ा। यह आश्चर्यजनक था, क्योंकि मैंने पूरी तरह से सेवा का परीक्षण किया, विशेष रूप से देरी के लिए, क्योंकि यह लगातार शिकायतों का विषय है।

एल्विन को परीक्षण के लिए देने से पहले, मैंने प्रति सेकंड (QPS) 40 हजार अनुरोधों के साथ कई प्रयोग किए, सभी में 10 एमएस से कम की देरी दिखाई गई। मैं यह घोषित करने के लिए तैयार था कि मैं उनके परिणामों से सहमत नहीं हूँ। लेकिन एक बार फिर पत्र को देखते हुए, मैंने कुछ नया करने के लिए ध्यान आकर्षित किया: मैंने निश्चित रूप से उन स्थितियों का परीक्षण नहीं किया, जिनका उन्होंने उल्लेख किया था, उनका क्यूपीएस मेरी तुलना में बहुत कम था। मैंने 40k QPS पर परीक्षण किया, और उन्होंने केवल 1k पर। मैंने एक और प्रयोग किया, इस बार कम QPS के साथ, बस उन्हें खुश करने के लिए।

चूँकि मैं इस बारे में अपने ब्लॉग पर लिखता हूँ, आप शायद पहले ही समझ गए हों: उनकी संख्या सही निकली। मैंने अपने वर्चुअल क्लाइंट को एक ही परिणाम के साथ बार-बार परीक्षण किया: कम संख्या में अनुरोधों से न केवल देरी बढ़ जाती है, बल्कि 10 एमएस से अधिक की देरी के साथ अनुरोधों की संख्या भी बढ़ जाती है। दूसरे शब्दों में, यदि 40k QPS में प्रति सेकंड 50 अनुरोध 50 ms से अधिक हो जाते हैं, तो प्रत्येक सेकंड में 1k QPS में 50 ms से ऊपर 100 अनुरोध थे। विरोधाभास!

अपनी खोज को संक्षिप्त करें

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



एक अच्छा प्रारंभिक बिंदु पूर्ण I / O संक्रमण (नेटवर्क कॉल / डिस्क खोज, आदि) की एक सूची है। आइए यह जानने की कोशिश करें कि देरी कहाँ है। क्लाइंट के साथ स्पष्ट I / O के अलावा, एल्विन एक अतिरिक्त कदम उठाता है: वह डेटा वेयरहाउस तक पहुंचता है। हालांकि, यह स्टोरेज एल्विन के साथ एक ही क्लस्टर में काम करता है, इसलिए क्लाइंट के साथ इसमें देरी कम होनी चाहिए। तो, संदिग्धों की सूची:

1. क्लाइंट से एल्विन तक नेटवर्क कॉल।
   
2. एल्विन से डेटा वेयरहाउस तक नेटवर्क कॉल।
   
3. डेटा वेयरहाउस में डिस्क पर खोजें।
   
4. डेटा वेयरहाउस से एल्विन तक नेटवर्क कॉल।
   
5. एल्विन से क्लाइंट को नेटवर्क कॉल।

चलो कुछ बिंदुओं को पार करने की कोशिश करते हैं।

डेटा वेयरहाउस

मैंने जो पहला काम किया, वह एल्विन को एक पिंग-पिंग सर्वर में बदल दिया, जो अनुरोधों को संभालता नहीं है। अनुरोध प्राप्त करने पर, यह एक खाली प्रतिक्रिया देता है। यदि देरी कम हो जाती है, तो एल्विन या डेटा वेयरहाउस के कार्यान्वयन में त्रुटि अनसुनी है। पहले प्रयोग में, हमें निम्नलिखित ग्राफ मिलता है:



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

1. क्लाइंट से एल्विन तक नेटवर्क कॉल।
   
2. एल्विन से क्लाइंट को नेटवर्क कॉल।

वाह! सूची तेजी से सिकुड़ रही है। मुझे लगा कि मैंने इसका कारण लगभग पता लगा लिया है।

gRPC

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

स्टैक में gRPC की उपस्थिति ने एक नया सवाल उठाया: शायद यह मेरा कार्यान्वयन है या क्या gRPC स्वयं एक विलंब समस्या का कारण है? नए संदिग्ध की सूची में जोड़ें:

1. क्लाइंट gRPC लाइब्रेरी को कॉल करता है
   
2. क्लाइंट पर gRPC लाइब्रेरी सर्वर पर gRPC लाइब्रेरी के लिए नेटवर्क कॉल करता है
   
3. gRPC लाइब्रेरी ने एल्विन का उपयोग किया (पिंग-पोंग सर्वर के मामले में कोई ऑपरेशन नहीं)

आपको यह समझने के लिए कि कोड कैसा दिखता है, मेरा ग्राहक / एल्विन कार्यान्वयन async क्लाइंट-सर्वर उदाहरणों से बहुत अलग नहीं है।

नोट: उपरोक्त सूची थोड़ी सरल है, क्योंकि gRPC आपको अपने स्वयं के (टेम्पलेट?) स्ट्रीम मॉडल का उपयोग करने की अनुमति देता है, जिसमें gRPC निष्पादन gRPC और उपयोगकर्ता कार्यान्वयन gRPC में gRPC होते हैं। सरलता के लिए, हम इस मॉडल से चिपके रहेंगे।

प्रोफाइलिंग सब कुछ ठीक कर देगी

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

मैंने चार प्रोफ़ाइल लीं: उच्च QPS (कम विलंबता) के तहत और कम QPS (उच्च विलंबता) पर एक पिंग-पोंग सर्वर के साथ, क्लाइंट पक्ष और सर्वर पक्ष पर दोनों। और सिर्फ मामले में, मैंने एक नमूना प्रोसेसर प्रोफाइल भी लिया। प्रोफाइल की तुलना करते समय, मैं आमतौर पर एक असामान्य कॉल स्टैक की तलाश करता हूं। उदाहरण के लिए, एक उच्च देरी के साथ खराब पक्ष पर, बहुत अधिक संदर्भ स्विच (10 या अधिक बार) हैं। लेकिन मेरे मामले में, संदर्भ की संख्या लगभग मेल खाती है। मेरे आतंक के लिए, वहाँ कुछ भी महत्वपूर्ण नहीं था।

अतिरिक्त डिबगिंग

मैं हताश था। मुझे नहीं पता था कि अन्य उपकरणों का क्या उपयोग किया जा सकता है, और मेरी अगली योजना अनिवार्य रूप से विभिन्न रूपों के साथ प्रयोगों को दोहराना था, और स्पष्ट रूप से समस्या का निदान नहीं करना था।

क्या हुआ अगर

शुरुआत से ही, मैं 50 एमएस के विशिष्ट विलंब समय के बारे में चिंतित था। यह बहुत बड़ा समय है। मैंने फैसला किया कि मैं कोड से टुकड़ों को काट दूंगा जब तक कि मैं यह पता नहीं लगा सकता कि कौन सा हिस्सा इस त्रुटि का कारण बन रहा था। फिर एक प्रयोग किया जो काम किया।

हमेशा की तरह, पीछे के मन से ऐसा लगता है कि सब कुछ स्पष्ट था। मैंने ग्राहक को एल्विन के साथ एक ही मशीन पर रखा - और अनुरोध को localhost को भेज दिया। और देरी से वृद्धि गायब हो गई है!



नेटवर्क में कुछ गड़बड़ थी।

एक नेटवर्क इंजीनियर के कौशल सीखना

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

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

सबसे पहले, मैंने एल्विन के टीसीपी पोर्ट पर PsPing चलाया। मैंने डिफ़ॉल्ट विकल्पों का उपयोग किया - कुछ खास नहीं। एक हजार से अधिक पिंग्स में से, 10 एमएस से अधिक नहीं, वार्मिंग के लिए पहले के अपवाद के साथ। यह 99 वें प्रतिशत में 50 एमएस की देरी में देखी गई वृद्धि का खंडन करता है: वहां, प्रत्येक 100 अनुरोधों के लिए, हमें 50 एमएस की देरी के साथ एक अनुरोध के बारे में देखना चाहिए।

तब मैंने ट्रेसर्ट की कोशिश की: शायद समस्या एल्विन और क्लाइंट के बीच के मार्ग में से एक नोड पर है। लेकिन ट्रेसर खाली हाथ लौट आया।

इस प्रकार, देरी का कारण मेरा कोड नहीं था, जीआरपीसी का कार्यान्वयन नहीं था, और नेटवर्क नहीं था। मुझे पहले से ही चिंता होने लगी है कि मैं इसे कभी नहीं समझ पाऊंगा।

अब हम किस ओएस पर हैं

gRPC लिनक्स पर व्यापक रूप से उपयोग की gRPC , लेकिन यह विंडोज के लिए विदेशी है। मैंने एक प्रयोग करने का निर्णय लिया जो काम करता है: मैंने लिनक्स वर्चुअल मशीन बनाई, लिनक्स के लिए एल्विन संकलित किया और इसे तैनात किया।



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

नागल एल्गोरिथ्म

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



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

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

निष्कर्ष

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

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

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