एक और कारण डॉकटर कंटेनर धीमा हो जाता है

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

इससे पहले, हमने कुबेरनेट्स आंतरिक क्लस्टर में b CI / CD के विकास से संबंधित कार्यों की एक श्रृंखला शुरू की। सबकुछ ठीक होगा, लेकिन जब आप "डॉकटराइज" एप्लिकेशन लॉन्च करते हैं, तो प्रदर्शन अचानक नाटकीय रूप से गिर जाता है। हमने कंजूसी नहीं की: प्रत्येक कंटेनर में पॉड कॉन्फ़िगरेशन के माध्यम से कंप्यूटिंग शक्ति और मेमोरी (5 सीपीयू / 30 जीबी रैम) की सीमाएं थीं। इस तरह के मापदंडों के साथ एक आभासी मशीन पर, परीक्षणों के लिए एक छोटे डेटा सेट (10 Kb) से हमारे सभी अनुरोध उड़ जाएंगे। हालांकि, 72 सीपीयू / 512 जीबी रैम के साथ डॉकर एंड कुबेरनेट्स में, हम उत्पाद की 3-4 प्रतियां लॉन्च करने में कामयाब रहे, और फिर ब्रेक शुरू हो गए। कुछ मिलिसेकंड के एक जोड़े को पूरा करने वाली क्वेरीज़ अब 1 से 2 सेकंड के लिए लटका दी गई थी, और इसने सीआई कार्य पाइपलाइन में सभी प्रकार की विफलताओं का कारण बना। मुझे डिबगिंग के साथ निकटता से निपटना था।

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

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

1. मुख्य कारण लिनक्स कर्नेल में ही है। कर्नेल में डेंट्री कैश ऑब्जेक्ट्स की संरचना के कारण, एक प्रक्रिया के व्यवहार ने कॉल को __d_lookup_loop कर्नेल पर __d_lookup_loop , जिसने सीधे दूसरे के प्रदर्शन को प्रभावित किया।
2. लेखक ने कर्नेल में बग का पता लगाने के लिए perf का उपयोग किया। एक महान डिबगिंग टूल जिसका हमने पहले कभी उपयोग नहीं किया है (जो एक दया है!)।

perf (जिसे कभी-कभी perf_events या perf tools कहा जाता है; पूर्व में Linux, PCL के लिए प्रदर्शन काउंटर के रूप में जाना जाता है) कर्नेल संस्करण 2.6.31 से उपलब्ध लिनक्स प्रदर्शन विश्लेषण उपकरण है। यूजर स्पेस मैनेजमेंट यूटिलिटी, perf, कमांड लाइन से उपलब्ध है और यह subcommands का संग्रह है।

यह पूरे सिस्टम (कर्नेल और उपयोगकर्ता स्थान) की सांख्यिकीय रूपरेखा करता है। यह उपकरण हार्डवेयर और सॉफ़्टवेयर के प्रदर्शन काउंटर (उदाहरण के लिए, हर्टिमर) प्लेटफार्मों, ट्रेस पॉइंट्स और डायनेमिक सैंपल (जैसे, केप्रोब्स या अपब्रोज़) का समर्थन करता है। 2012 में, दो आईबीएम इंजीनियरों ने ओप्रेफाइल के साथ परफैक्ट (ओप्रोफाइल के साथ) को लिनक्स पर दो सबसे अधिक इस्तेमाल किए जाने वाले प्रदर्शन काउंटर प्रोफाइलिंग टूल्स में से एक के रूप में मान्यता दी।

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

नीचे एक स्वस्थ (तेज) मशीन (बाएं) और कंटेनर के अंदर (दाएं) चल रहे थॉटस्पॉट के पहले 10 सेकंड की संपूर्ण प्रविष्टियां दी गई हैं।

यह तुरंत स्पष्ट है कि दाईं ओर पहले 5 कॉल कर्नेल के साथ जुड़े हुए हैं। समय मुख्य रूप से कर्नेल स्थान पर बिताया जाता है, जबकि बाईं ओर - अधिकांश समय उपयोगकर्ता अंतरिक्ष में चलने वाली हमारी अपनी प्रक्रियाओं पर खर्च किया जाता है। लेकिन सबसे दिलचस्प बात यह है कि posix_fadvise कॉल हर समय लेता है।

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

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

यह थर्ड-पार्टी लॉगिंग लाइब्रेरी है जिसे glog कहा जाता है। हमने प्रोजेक्ट के लिए इसका इस्तेमाल किया। विशेष रूप से, यह रेखा ( LogFileObject::Write ) संभवतः पूरी लाइब्रेरी का सबसे महत्वपूर्ण पथ है। इसे सभी घटनाओं के लिए "लॉग इन फाइल" (लॉग फाइल करने के लिए) कहा जाता है, और हमारे उत्पाद के कई उदाहरण अक्सर लॉग होते हैं। स्रोत कोड पर एक त्वरित नज़र से पता चलता है कि fadvise भाग को --drop_log_memory=false पैरामीटर सेट करके अक्षम किया जा सकता है:

  if (file_length_ >= logging::kPageSize) { // don't evict the most recent page uint32 len = file_length_ & ~(logging::kPageSize — 1); posix_fadvise(fileno(file_), 0, len, POSIX_FADV_DONTNEED); } } 

जो हम, निश्चित रूप से, और ... बुल्सआई में!

कुछ सेकंड लेने के लिए क्या किया जाता है अब 8 (आठ!) Milliseconds में किया जाता है। थोड़ा गुगली, हमें यह मिला: https://issues.apache.org/jira/browse/MESOS-920 और यह भी: https://github.com/google/glog/pull/145 , जो एक बार फिर से पुष्टि की निषेध के असली कारण के बारे में हमारा कूबड़। सबसे अधिक संभावना है, आभासी मशीन / नंगे धातु पर एक ही बात हुई थी, लेकिन चूंकि हमारे पास प्रति मशीन / कर्नेल की प्रक्रिया की 1 प्रति थी, इसलिए फडवीस कॉल की तीव्रता बहुत कम थी, जो अतिरिक्त संसाधन खपत की कमी बताती थी। लॉगिंग प्रक्रियाओं को 3-4 गुना बढ़ाना और उनके लिए एक सामान्य कोर को उजागर करना, हमने देखा कि यह वास्तव में खराब हो गया है।

और निष्कर्ष में:

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