Kubernetes: सीएफएस कोटा अनावश्यक थ्रॉटलिंग का कारण बन सकता है

/ सिग नोड
/ तरह बग

क्या यह # 51135 का डुप्लिकेट है?

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

जहां तक ​​मैं समझता हूं कि यह या तो सीएफएस कोटा ( --cpu-cfs-quota=false ) को अक्षम करने का एक और कारण है या इसे कॉन्फ़िगर करने योग्य (# 63437) है।

मुझे यह भी पता चलता है (कर्नेल पैच से जुड़ा हुआ) देखने के लिए बहुत दिलचस्प है (प्रभाव को नापने के लिए): https://gist.github.com/bobrik/2030ff040fad360327a5fab7a09c4b1

cc @adityakali

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

Imo इस क्यूबलेट को इस स्थिति से बचने के लिए हाइपरथ्रेड्स को वास्तविक cpus नहीं मानना ​​चाहिए।

@juliantaylor जैसा कि मैंने # 51135 में बताया कि CPU कोटा बंद करना भरोसेमंद वर्कलोड चलाने वाले अधिकांश k8 क्लस्टर्स के लिए सबसे अच्छा तरीका हो सकता है।

क्या इसे बग के रूप में माना जाता है?

अगर वास्तव में अपनी सीपीयू सीमा समाप्त नहीं करते हुए कुछ पॉड्स थ्रॉटल किए जाते हैं, तो यह मेरे लिए एक बग की तरह लगता है।

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

यहाँ अजीब बात यह है कि मैंने सीमा बढ़ाने की कोशिश की, 40m से 100m या 200m , और प्रक्रियाएँ अभी भी थर्रा रही थीं।
मैं इस थ्रॉटलिंग को चालू कर सकने वाले वर्कलोड को इंगित करते हुए कोई अन्य मैट्रिक्स नहीं देख सकता।

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

@ prune998 देखिये @vishh की टिप्पणी और इस जुमले : कर्नेल पर आक्रामक तरीके से, भले ही गणित आपको https://www.slideshare.net/try_except_/optimizing-kubernetes-resource-requestscits-for-costefficiency-and-latency-highload

साभार @hjacobs
मैं Google GKE पर हूं और मुझे इसे अक्षम करने का कोई आसान तरीका नहीं दिखता, लेकिन मैं खोज करता रहता हूं ...।

@ prune998 AFAIK, Google ने अभी तक आवश्यक knobs उजागर नहीं किया है। हमने सीएफएस को अपस्ट्रीम में निष्क्रिय करने की संभावना के ठीक बाद एक सुविधा अनुरोध दायर किया, तब से कोई खबर नहीं सुनी।

मैं Google GKE पर हूं और मुझे इसे अक्षम करने का कोई आसान तरीका नहीं दिखता, लेकिन मैं खोज करता रहता हूं ...।

क्या आप अभी तक अपने कंटेनरों से सीपीयू सीमा हटा सकते हैं?

CPU प्रबंधक डॉक्स के अनुसार, CFS quota is not used to bound the CPU usage of these containers as their usage is bound by the scheduling domain itself. लेकिन हम सीएफएस थ्रॉटलिंग का अनुभव कर रहे हैं।

यह स्थैतिक सीपीयू प्रबंधक को ज्यादातर CPU के रूप में निरर्थक बनाता है क्योंकि गारंटीकृत QoS वर्ग को प्राप्त करने के लिए थ्रॉलिंग के कारण किसी भी लाभ को नकार दिया जाता है।

क्या यह एक बग है कि सीएफएस कोटा स्थिर सीपीयू पर फली के लिए बिल्कुल निर्धारित है?

अतिरिक्त संदर्भ के लिए (यह कल सीखा): @hrzbrg (MyTaxi) ने सीपीयू थ्रॉटलिंग को निष्क्रिय करने के लिए कोप्स को एक ध्वज का योगदान दिया: https://github.com/kubernetes/kops/issues/5826

कृपया समस्या का सारांश यहाँ साझा करें। यह बहुत स्पष्ट नहीं है कि समस्या क्या है और किन परिदृश्यों में उपयोगकर्ता प्रभावित होते हैं और इसे ठीक करने के लिए वास्तव में क्या आवश्यक है?

वर्तमान में हमारी समझ यह है कि जब हम सीमा पार करते हैं तो हम दंडित और थ्रोट हो जाते हैं। तो कहते हैं कि हमारे पास 3 कोर का एक सीपीयू कोटा है और पहले 5ms में हमने 3 कोर का उपभोग किया फिर 100ms के स्लाइस में हम 95ms के लिए थ्रॉटल हो जाएंगे, और इस 95ms में हमारे कंटेनर कुछ भी नहीं कर सकते। और हमने देखा है कि जब सीपीयू स्पाइक्स उपयोग मैट्रिक्स में दिखाई नहीं देते हैं तब भी थ्रोटल हो जाते हैं। हम मानते हैं कि यह इसलिए है क्योंकि सीपीयू उपयोग को मापने का समय विंडो सेकंड में है और थ्रॉटलिंग माइक्रो सेकंड के स्तर पर हो रहा है, इसलिए यह औसत है और दिखाई नहीं देता है। लेकिन यहां बताए गए बग ने हमें अब भ्रमित कर दिया है।

कुछ सवाल:

• जब नोड 100% सीपीयू पर है? क्या यह एक विशेष मामला है जिसमें सभी कंटेनरों को उनके उपयोग की परवाह किए बिना गला घोंटा जाता है?

• जब ऐसा होता है तो सभी कंटेनरों को 100% सीपीयू थ्रोटल मिल जाता है?

• नोड में ट्रिगर होने के लिए इस बग को क्या ट्रिगर करता है?

• का उपयोग नहीं कर बीच क्या अंतर है limits और अक्षम करने cpu.cfs_quota ?

• क्या limits एक जोखिम भरा समाधान अक्षम नहीं है जब कई फोड़ने योग्य फली हैं और एक फली नोड में अस्थिरता पैदा कर सकती है और अन्य पॉड्स को प्रभावित कर सकती है जो उनके अनुरोधों पर चल रहे हैं?

• कर्नेल डॉक्टर प्रक्रिया के अनुसार अलग-अलग होने पर, माता-पिता का कोटा पूरी तरह से भस्म हो सकता है। यहां कंटेनर संदर्भ में माता-पिता क्या है (क्या यह इस बग से संबंधित है)? https://www.kernel.org/doc/Documentation/scheduler/sched-bwc.txt
  There are two ways in which a group may become throttled: a. it fully consumes its own quota within a period b. a parent's quota is fully consumed within its period

• उन्हें ठीक करने के लिए क्या आवश्यक है? अपग्रेड कर्नेल संस्करण?

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

यहाँ किसी भी मदद की बहुत सराहना की है।

cc @justinsb

हमारे उपयोगकर्ताओं में से एक ने सीपीयू की सीमा निर्धारित की और समय-समय पर अपनी जांच को आगे बढ़ाते हुए अपनी सेवा को समाप्त कर दिया।

हम सीपीयू में कंटेनरों को पिन करते समय भी थ्रॉटलिंग देख रहे हैं। उदाहरण के लिए 1 सीपीयू की सीमा और उस कंटेनर को केवल एक सीपीयू पर चलाने के लिए पिन करना। किसी भी अवधि में दिए गए कोटा से अधिक होना असंभव है यदि आपका कोटा बिल्कुल आपके पास सीपीयू की संख्या है, फिर भी हम हर मामले में थ्रॉटलिंग देखते हैं।

मैंने सोचा कि मैंने इसे कहीं पोस्ट किया है कि कर्नेल 4.18 समस्या को हल करता है। मैंने अभी तक इसका परीक्षण नहीं किया है, इसलिए अच्छा होगा यदि कोई पुष्टि कर सके।

4.18 में https://github.com/torvalds/linux/commit/512ac999d2755d2b7109e996a76b6fb8b888631d इस मुद्दे के लिए प्रासंगिक पैच लगता है।

@mariusgrigoriu मैं आपको यहाँ वर्णित एक ही https://github.com/kubernetes/kubernetes/issues/67577#issuecomment -462534360।

सीपीयूएनेजर स्थिर नीति के साथ गारंटीकृत क्यूओएस वर्ग में हम पॉड्स पर सीपीयू थ्रॉटलिंग का निरीक्षण करते हैं (जो कि कोई मतलब नहीं लगता है)।

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

@vishh ने उपरोक्त परिस्थितियों को देखते हुए, कार्रवाई का सबसे अच्छा कोर्स क्या होगा? ऐसा लगता है जैसे कर्नेल में अपग्रेड करना 4.11 (जिसमें cfs cpu अकाउंटिंग फिक्स है) और (शायद) cfs कोटा अवधि कम करना?

एक सामान्य नोट पर, हम सुझाव देते हैं कि हमारे द्वारा फेंके जा रहे कंटेनरों से सिर्फ limits हटाएं, स्पष्ट चेतावनी होनी चाहिए:
1) यदि ये गारंटीशुदा QoS वर्ग में पॉड्स होते हैं, तो पूर्णांक संख्या में कोर और CPUMnanager स्थिर नीति के साथ - इन पॉड्स को अब समर्पित CPU कोर नहीं मिलेंगे क्योंकि इन्हें बर्स्टेबल QoS क्लास में रखा जाएगा (कोई अनुरोध नहीं होने पर = सीमाएं
2) ये पॉड्स कितने सीपीयू का उपभोग कर सकते हैं और संभावित रूप से कुछ परिस्थितियों में काफी नुकसान पहुंचा सकते हैं।

आपकी प्रतिक्रिया / मार्गदर्शन की बहुत सराहना की जाएगी।

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

मैं थोड़ी देर के लिए इस मुद्दे के विभिन्न पहलुओं पर शोध कर रहा हूं। मेरे शोध को संक्षेप में एलकेएमएल में पोस्ट किया गया है।
https://lkml.org/lkml/2019/3/18/706
कहा जा रहा है, मैं इस समस्या को पुन: पेश करने में सक्षम नहीं हूं जैसा कि यहां पूर्व 512ac99 कर्नेल में वर्णित है। मैंने हालांकि बाद में 512ac99 कर्नेल में एक प्रदर्शन प्रतिगमन देखा है। ताकि फ़िक्स ठीक न हो।

धन्यवाद @mariusgrigoriu, हम उन्नयन और आशा कुछ हद तक मदद मिलेगी कर्नेल के लिए जा रहे हैं, भी की जाँच https://github.com/kubernetes/kubernetes/issues/70585 - ऐसा लगता है कोटा वास्तव में cpuset साथ गारंटी फली (के लिए सेट कर रहे हैं कि यानी पिसा हुआ सीपीस), इसलिए यह मेरे लिए बग जैसा लगता है।

@chiluk क्या आप थोड़ा विस्तार कर सकते हैं? क्या आपका मतलब है कि पैच 4.18 (https://github.com/kubernetes/kubernetes/issues/67577#issuecomment-466609030 में ऊपर वर्णित) वास्तव में समस्या हल नहीं करता है?

512ac99 कर्नेल पैच कुछ लोगों के लिए एक समस्या को हल करता है, लेकिन हमारे कॉन्फ़िगरेशन के लिए एक समस्या का कारण बना। पैच को जिस तरह से समय स्लाइस cfs_rq के बीच वितरित किया जाता है, उसमें वे अब सही ढंग से समाप्त हो जाते हैं। पहले वे समाप्त नहीं होंगे।

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

4.19.30 कर्नेल का उपयोग करने पर मुझे ऐसी पॉड्स दिखाई देती हैं जिनके बारे में मुझे उम्मीद है कि कम थ्रॉटलिंग देखने के लिए अभी भी थ्रॉटल किए गए हैं और कुछ पॉड्स जो पहले से थ्रॉटल नहीं किए जा रहे थे उन्हें अब काफी गंभीर रूप से थ्रॉटल किया जा रहा है (क्यूब 2 एआईएम उदाहरण से थ्रॉटल किए गए अधिक सेकंड की रिपोर्ट कर रहा है। , किसी न किसी तरह)

CoreOS 4.19.25-coreos पर मैं प्रोमेथियस को सिस्टम में हर एक पॉड पर लगभग CPUThrottlingHigh अलर्ट ट्रिगर करता हुआ देखता हूं।

@williamsandrew @teralype यह @chiluk के निष्कर्षों को दर्शाता है।

विभिन्न आंतरिक चर्चाओं के बाद हमने वास्तव में cfs कोटा को पूरी तरह से निष्क्रिय करने का फैसला किया (क्यूबलेट का झंडा --cpu-cfs-quota=false ), यह उन सभी मुद्दों को हल करने के लिए लगता है जो हम बर्स्टेबल और गारंटीड (cpu पिन किए गए या मानक) दोनों पॉड्स के लिए कर रहे हैं।

इस (और कुछ अन्य विषयों) के बारे में यहाँ एक उत्कृष्ट डेक है: https://www.slideshare.net/try_except_/ensuring-kubernetes-cost-efficiency-across-many-clusters-devops-gathering-2019

अत्यधिक अनुशंसित पढ़ने: +1:

दीर्घकालिक-जारी (स्वयं के लिए नोट)

@ dannyk81 सिर्फ पूर्णता के लिए: लिंक की https://www.youtube.com/watch?v=4QyecOoPsGU

@ स्खलन , बात पसंद आई! बहुत बहुत धन्यवाद...
किसी भी विचार कैसे AKS या GKE पर इस सुधार को लागू करने के लिए?
धन्यवाद

@agolomoodysaada हमने कुछ समय पहले GKE के साथ एक फीचर अनुरोध दायर किया था। हालांकि यह सुनिश्चित नहीं है कि स्थिति क्या है, मैं अब GKE के साथ गहन रूप से काम नहीं करता हूं।

मैं अज़ूर के समर्थन में पहुंच गया और उन्होंने कहा कि यह अगस्त 2019 तक उपलब्ध नहीं होगा।

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

यह किस कर्नेल पर था?

" चिल्लुक " 4.15.0-1037-एज़्योर "

ताकि कर्नेल प्रतिबद्ध 512ac99 शामिल न हो। यहाँ संगत है
स्रोत।
https://kernel.ubuntu.com/git/kernel-ppa/mirror/ubuntu-azure-xenial.git/tree/kernel/sched/fair.c?h=Ubuntu-azure-4.15.0-1037.39_16.04.1 और आईडी = 19b0066cc4829f45321a52a802b640bab14d0f67

जिसका अर्थ है कि आप 512ac99 में बताए गए मुद्दे को मार सकते हैं। में रखना
मन कि 512ac99 हमारे लिए अन्य प्रतिगमन लाया।

शुक्र पर, 5 अप्रैल, 2019 को दोपहर 12:08 बजे मूडी साडा सूचनाएं @github.com
लिखा था:

@chiluk https://github.com/chiluk "4.15.0-1037-azure"

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/67577#issuecomment-480350946 ,
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/ACDI05YeS6wfUE9XkiMbxrLvPllYQZ7Iks5vd4MOgaJpZM4WDUF3
।

मैंने अब इस बारे में LKML को पैच पोस्ट किए हैं।
https://lkml.org/lkml/2019/4/10/1068

अतिरिक्त परीक्षण की बहुत सराहना की जाएगी।

मैंने इन पैचेज़ को अब दस्तावेज़ परिवर्तनों के साथ फिर से सबमिट कर दिया है।
https://lkml.org/lkml/2019/5/17/581

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

इसके लायक क्या है, यह विशेष परियोजना https://github.com/tensorflow/serves इस मुद्दे से बुरी तरह प्रभावित होती है। और यह ज्यादातर C ++ एप्लीकेशन है।

@chiluk , क्या कोई वर्कअराउंड है जिसे हम लागू कर सकते हैं जबकि पैच रोल आउट हो जाता है?
आपका बहुत बहुत धन्यवाद

हम Kubernetes पर इस कर्नेल बग के गंभीर प्रभाव और किसी और को सीएफएस कोटा का उपयोग करने का कलेक्ट प्रशंसा पत्र @chiluk मदद करनी चाहिए।

ज़ोलैंडो ने पिछले सप्ताह अपनी प्रस्तुति में शामिल किया कि वर्तमान कर्नेल के साथ उनके बुरे अनुभवों का मतलब है कि वे सीएफएस कोटा को वर्तमान सर्वोत्तम अभ्यास के रूप में अक्षम करने पर विचार करते हैं, क्योंकि वे मानते हैं कि यह अच्छे से अधिक नुकसान करता है।
https://www.youtube.com/watch?v=6sDTB4eV4F8

अधिक से अधिक कंपनियों सीपीयू थ्रॉटलिंग, जैसे mytaxi, Datadog, Zalando ( ट्विटर थ्रेड ) को अक्षम कर रहे हैं

@derekwaynecarr @ dchen1107 @ kubernetes / sig-node-feature-request-Dawn, Derek, क्या यह डिफ़ॉल्ट बदलने का समय है? और / या प्रलेखन?

हां @ पार्इसरॉन ने अपंग अनुप्रयोगों के थ्रॉटलिंग की रिपोर्ट एकत्र करना और साझा करना, और यह गलत व्यवहार के कारण बंद किया जा रहा है, जहां उचित होगा lkml थ्रेड पर भागीदारी का स्वागत किया जाएगा। फिलहाल ऐसा लग रहा है कि यह सिर्फ मुझे इस मुद्दे के बारे में शिकायत कर रहा है।

@agolomoodysaada वर्कफ़्लो अस्थायी रूप से cfs कोटा अक्षम करने या प्रभावित अनुप्रयोगों के लिए अधिक-आवंटित सीपीयू कोटा * है (सभी अनुप्रयोगों को यह हिट नहीं होगा, लेकिन बहु-थ्रेडेड उपयोगकर्ता-इंटरैक्टिव अनुप्रयोगों के बहुमत शायद हैं)।

आवेदन थ्रेड काउंट को कम करने के आस-पास भी सर्वोत्तम अभ्यास हैं जो भी मदद करता है।
गोलंग सेट के लिए GOMAXPROCS ~ = छत (कोटा)
जावा के लिए नए JVM को स्थानांतरित करें जो सीपीयू कोटा सीमाओं को पहचानते हैं और उनका सम्मान करते हैं। इससे पहले jvms ने सीपीयू कोर की संख्या के आधार पर थ्रेड्स की स्थापना की, न कि एप्लिकेशन को उपलब्ध कोर की संख्या के आधार पर।
ये दोनों हमारे लिए प्रदर्शन के लिए बड़े वरदान रहे हैं।

मॉनिटर और रिपोर्ट एप्लिकेशन जो थ्रॉटलिंग मार रहे हैं ताकि आपके डेवलपर्स कोटा समायोजित कर सकें।

FYI करने के बाद, मैंने इस धागे को Azure AKS सपोर्ट की ओर इशारा किया, मुझे उत्तर दिया गया कि पैच को रोल आउट किया जाएगा जब वे कर्नेल 5.0 में अपग्रेड करते हैं, देर से, सबसे अच्छे रूप में।
तब तक, ठीक है, सीमा का उपयोग करना बंद करें :)

@ prune998 अगर आप CPUmanager (यानी गारंटीड QoS में पॉड्स को समर्पित cpu आवंटन) का उपयोग कर रहे हैं, तो वहां एक छोटी सी चेतावनी है।

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

यदि आप CPUmanager का उपयोग नहीं करते हैं - कोई नुकसान नहीं हुआ है, लेकिन इस दिशा में किसी के लिए भी FYI करें।

पूरी तरह से समर्पित सीपीयू के साथ पॉड्स के लिए सीएफएस कोटा पूरी तरह से अक्षम करने के लिए पीआर (https://github.com/kubernetes/kubernetes/issues/70585) है लेकिन अभी तक इसे विलय नहीं किया गया था।

हमने सीएफएस कोटा प्रणाली को भी विस्तृत करने का विकल्प चुना है, जैसा कि ऊपर दिया गया है और अब तक कोई समस्या नहीं है।

@ dannyk81 https://github.com/kubernetes/kubernetes/issues/70585 एक पीआर नहीं है जिसे विलय किया जा सकता है (यह एक कोड स्निपेट के साथ एक समस्या है)। क्या आप (या कोई और) कृपया एक PR फाइल कर सकते हैं?

एक पहले से ही है: https://github.com/kubernetes/kubernetes/pull/75682

@dims मैंने इस मुद्दे को पीआर से जोड़ा है ... पीआर से जुड़ा नहीं है, लेकिन यह मुद्दा वास्तव में https://github.com/kubernetes/kubernetes/pull/75682 से जुड़ा हुआ है और यह कुछ समय से वहां लटका हुआ है, इसलिए यदि आप इसे आगे बढ़ा सकते हैं तो यह बहुत अच्छा होगा क्योंकि यह वास्तव में एक कष्टप्रद मुद्दा है।

साभार: +1:

ओह! धन्यवाद @ dannyk81 मैंने लोगों को सौंपा और मील का पत्थर जोड़ा

एफडब्ल्यूआईडब्ल्यू हम इस मुद्दे में भी भागे, और पाया कि सीएफएस कोटा अवधि को डिफ़ॉल्ट 100ms के बजाय 10ms तक छोड़ने के कारण नाटकीय रूप से सुधार करने के लिए हमारी पूंछ अंत विलंबता का कारण बनी। मुझे लगता है कि यह इसलिए है क्योंकि अगर आप कर्नेल बग में भाग लेते हैं, तो भी कोटा की एक छोटी राशि बर्बाद हो जाती है यदि इसका उपयोग नहीं किया जाता है, और प्रक्रिया बहुत जल्दी (छोटे आवंटन में) अधिक कोटा प्राप्त कर सकती है। यह सिर्फ एक वर्कअराउंड है, लेकिन जो लोग पूरी तरह से CFS कोटा को अक्षम नहीं करना चाहते हैं, उनके लिए यह एक बैंडेड हो सकता है जब तक कि फिक्स लागू नहीं किया जाता है। k8s 1.12 में cpuCFSQuotaPeriod सुविधा गेट और - सीपीयू-सीएफएस-कोटा-अवधि क्यूबलेट ध्वज के साथ ऐसा करने का समर्थन करता है।

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

@chiluk मेरे आम आदमी की समझ यह है कि डिफ़ॉल्ट स्लाइस 5ms है, इसलिए इसे उस पर सेट करना या कम करना इसे प्रभावी रूप से अक्षम कर रहा है, लेकिन जब तक अवधि 5ms से अधिक है तब भी कोटा प्रवर्तन होना चाहिए। निश्चित रूप से मुझे बताएं कि क्या यह सही नहीं है।

--feature-gates=CustomCPUCFSQuotaPeriod=true --cpu-cfs-quota-period=10ms के साथ मेरी फली वास्तव में शुरू करने के लिए संघर्ष करती है। संलग्न प्रोमेथियस ग्राफ में, कंटेनर शुरू करने का प्रयास करता है, जब तक यह मारा नहीं जाता है तब तक इसकी जांच को पूरा करने के आस-पास कहीं भी नहीं मिलता है (आम तौर पर कंटेनर लगभग 5 सेकंड में शुरू होता है - यहां तक ​​कि लाइनिंग को बढ़ाते हुए शुरुआती 60 सेकंड में मदद नहीं की) और फिर एक नए की जगह।

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

FYI करें: सीपीयू थ्रॉटलिंग को अक्षम करने के विषय के बारे में वर्तमान ट्विटर धागा: https://twitter.com/it_supertramp/status/113364829133226393936

इन सीपीयू थ्रॉटलिंग ग्राफ से पहले / बाद में हम --cpu-cfs-quota-period=10ms उत्पादन के लिए 2 अक्षांशीय संवेदनशील विश्लेषण के लिए चले गए हैं:

ये सेवाएं अलग-अलग उदाहरण प्रकार (विभिन्न taints / सहनशीलता के साथ) पर चलती हैं। दूसरी सेवा के उदाहरणों को पहले CFS कोटा अवधि के लिए ले जाया गया था।

परिणाम लोड पर बहुत निर्भर होना चाहिए।

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

हमारे लिए यह थ्रॉटलिंग के बजाय विलंबता को मापने के लिए बहुत अधिक उपयोगी था। cfs-quota नाटकीय रूप से सुधरी हुई विलंबता को अक्षम करना। मैं cfs-quota-period बदलने के लिए समान परिणाम देखना चाहूंगा।

@chiluk हमने वास्तव में कोटा आवंटन बढ़ाने की कोशिश की (प्रति पॉकेट में कुबेरनेट्स द्वारा समर्थित अधिकतम), और किसी भी मामले में टेल एंड लेटेंसीज़ नहीं थे और न ही थ्रॉटलिंग बहुत कम हो गए थे। p99 लेटेंसी 4 कोर की सीमा के बारे में 98ms से 16 कोर की सीमा पर 86ms तक चली गई। सीएफएस कोटे को घटाकर 10ms p99 करने पर 4 कोर पर 20ms गया।

@blakebarnett ने एक बेंचमार्क प्रोग्राम विकसित किया, विलंबता को मापा, और वे 10ms-100ms की रेंज से चले गए, लगभग --cpu-cfs-quota-period 18ms के औसत से पहले

संपादित करें: मुझे उन संपादनों के लिए खेद है, जिन्हें मुझे वापस जाना था और अपनी संख्या को दोगुना करना था।

@ d-shi, आप तब 512ac999 द्वारा हल की गई समस्या को मार रहे थे।

@chiluk अपने पैच को बार-बार पढ़ने के बाद, मुझे इस कोड के प्रभाव को समझने के लिए संघर्ष करना होगा:

    if (cfs_rq->expires_seq == cfs_b->expires_seq) {
-       /* extend local deadline, drift is bounded above by 2 ticks */
-       cfs_rq->runtime_expires += TICK_NSEC;
-   } else {
-       /* global deadline is ahead, expiration has passed */
-       cfs_rq->runtime_remaining = 0;
-   }

ऐसे मामले में, जहां कोटा समाप्त हो रहा है, भले ही रनटाइम_्रेमिंग ने वैश्विक पूल से कुछ समय उधार लिया हो। सबसे कम समय में आप 5_ के लिए समय-सारणी के आधार पर थ्रॉटल हो जाएंगे। यह नहीं है?
क्या मुझे कुछ याद है?

@chiluk हाँ मुझे लगता है कि सही हैं। हमारे उत्पादन सर्वर अभी भी कर्नेल 4.4 पर हैं, इसलिए यह ठीक नहीं है। शायद एक बार जब हम एक नए कर्नेल में अपग्रेड करते हैं तो हम सीएफएस कोटा की अवधि को डिफ़ॉल्ट रूप से वापस ले जा सकते हैं, लेकिन अभी के लिए यह हमारे टेल एंड लेटेंसीज़ को बेहतर बनाने के लिए काम कर रहा है और हमने अभी तक किसी भी प्रतिकूल प्रभाव पर ध्यान नहीं दिया है। हालांकि यह केवल एक दो हफ्तों के लिए ही रहा है।

@chiluk कर्नेल में इस मुद्दे की स्थिति का सारांश? लगता है जैसे एक पैच था, 512ac999, लेकिन इसमें समस्याएं थीं। क्या मैंने कहीं पढ़ा कि यह उल्टा हो गया? या यह पूरी तरह से / आंशिक रूप से तय है? यदि हां, तो क्या संस्करण?

@mariusgrigoriu यह तय नहीं है, @chiluk ने एक पैच बनाया है जिसे इसे ठीक करना चाहिए जिसे आगे के परीक्षण की आवश्यकता है (मैं अगले कुछ दिनों में अपना कुछ समय इसके लिए आवंटित करने जा रहा हूं)

नवीनतम स्थिति के लिए https://github.com/kubernetes/kubernetes/issues/67577#issuecomment -482198124 देखें

@ वैश्विक पूल को cfs_b-> runtime_remaining में संग्रहीत किया जाता है। जैसा कि प्रति सीपीयू रन कतार (cfs_rq) को सौंपा गया है, वैश्विक पूल में बची हुई राशि का क्षय हो जाता है। cfs_bandwidth_slice_us cpu रनटाइम की राशि है जो वैश्विक पूल से प्रति-सीपीयू रन कतार में स्थानांतरित हो जाती है। यदि आप थ्रॉटल हो गए हैं, तो इसका मतलब है कि आपको चलाने की जरूरत है और cfs_b-> runtime_remaining == 0. आपको वर्तमान अवधि के अंत तक (डिफ़ॉल्ट रूप से 100ms से) इंतजार करना होगा, कोटा के लिए cfs_b को फिर से भरना होगा और फिर वितरित किया जाएगा। आपका cfs_rq मुझे हाल ही में पता चला है कि एक्सपायरी रनटाइम की राशि, प्रति cfs_rq में अधिकतम 1ms है, इस तथ्य के कारण कि सुस्त टाइमर प्रति-सीपीयू रन क्यू से अनुपयोगी कोटे के 1ms से हटा देता है। उस अवधि के अंत में 1ms बर्बाद / समाप्त हो गया है। एक बदतर स्थिति में, जहां आवेदन 88 cpus के फैलता है जो संभावित रूप से प्रति 100ms अवधि में 88ms बर्बाद कोटा हो सकता है। यह वास्तव में एक वैकल्पिक प्रस्ताव का कारण बना, जो सुस्त टाइमर को बेकार प्रति कोटा से सभी अनुपयोगी कोटा को हटा देने की अनुमति देता था।

लाइनों के लिए के रूप में आप विशेष रूप से प्रकाश डाला। मेरा प्रस्ताव रनटाइम की समाप्ति को हटाने के लिए है जिसे प्रति-सीपीयू रन-क्वीन्स को पूरी तरह से सौंपा गया है। वे लाइनें 512ac999 के लिए फिक्स का हिस्सा हैं। यह एक मुद्दा तय करता है, जहां प्रति-सीपीयू रन क्वीज के बीच क्लॉक तिरछा होने के कारण कोटा समय से पहले समाप्त हो जाता है, जिससे थ्रॉटलिंग एप्लिकेशन जो अभी तक कोटा (afaiu) का उपयोग करते हैं। मूल रूप से वे प्रत्येक अवधि सीमा पर expires_seq वेतन वृद्धि करते हैं। expires_seq को प्रत्येक cfs_rq के बीच मेल खाना चाहिए, जब वे समान अवधि पर हों।

@ मर्सिएग्रिगिओयू - यदि आप कम सीपीयू उपयोग के साथ उच्च थ्रॉटलिंग मार रहे हैं और आपका कर्नेल पूर्व-512ac999 है, तो आपको संभवतः 512ac999 की आवश्यकता होगी। यदि आप 512ac999 पोस्ट कर रहे हैं, तो संभवतः आप उस मुद्दे को मार रहे हैं जो मैंने ऊपर समझाया था कि वर्तमान में lkml पर चर्चा की जा रही है।
इस समस्या को कम करने के बहुत सारे तरीके हैं।

• सीपीयू पिनिंग
• आपके आवेदन स्पॉन की संख्या घटाना
• थ्रॉटलिंग का अनुभव करने वाले अनुप्रयोगों के लिए ओवर-आवंटित कोटा।
• अभी के लिए कठिन सीमाएँ बंद करें।
• प्रस्तावित परिवर्तनों में से किसी एक के साथ एक कस्टम कर्नेल बनाएँ।

@chiluk कोई भी मौका जो आपने पहले से ही इस पैच का एक संस्करण पोस्ट किया है जो कर्नेल 4.14 के साथ पहले से ही संगत है? मैं इसे बहुत आक्रामक तरीके से परख रहा हूं क्योंकि हमने अभी कुछ हजार मेजबानों को 4.14.121 (4.9.62 से) अपग्रेड किया है और देख रहे हैं:

1. ज्ञापन, mysql, nginx, आदि के लिए थ्रॉटलिंग में कमी
2. हमारे जावा एप्लिकेशन के लिए थ्रॉटलिंग में वृद्धि

वास्तव में यहां दोनों दुनिया का सर्वश्रेष्ठ पाने के लिए आगे बढ़ना चाहते हैं। मैं इसे अगले सप्ताह खुद पर पोर्ट करने का प्रयास कर सकता हूं, लेकिन अगर आपके पास पहले से ही एक है, तो यह भयानक होगा।

@PaulFurtado
मैंने वास्तव में बेन सेगुल के सुझावों को देखते हुए पिछले कुछ दिनों में पैच को फिर से लिखा है। जैसे ही मुझे हमारे समूहों पर कुछ परीक्षण का समय मिल सकता है, एक नया कर्नेल पैच आगामी हो जाएगा।

@ पिच पर कोई अपडेट? अगर कोई चिंता नहीं है, तो मैं सिर्फ यह सुनिश्चित कर रहा हूं कि मैं पैच को याद नहीं कर रहा हूं

@PaFFurtado , CFS लेखक द्वारा पैच को "अनुमोदित" कर दिया गया है, और मैं बस अनुसूचक अनुरक्षकों के लिए इसे एकीकृत करने और इसे लाइनस पर धकेलने की प्रतीक्षा कर रहा हूं।

@chiluk धन्यवाद!

मैंने बस कर्नेल 4.14 पर पैच को बैकपोर्ट किया, जो कि हमारा वर्तमान उत्पादन कर्नेल है।
मैंने यहाँ आपके फ़ाइबर से बैकपोर्ट और कुछ परिणामों के साथ एक जिस्ट बनाया: https://gist.github.com/PaulFurtado/ff6c67ec87416b66ba1c6fc70f7beec1

वर्तमान पीढ़ी c5.9xlarge और m5.24xlarge ec2 उदाहरण पर, जिसका उपयोग हम अपने कुबेरनेट और मैसोस क्लस्टर में करते हैं, पैच आपके फ़ाइबेस्टेस्ट प्रोग्राम के प्रदर्शन को दोगुना कर देता है। पिछली पीढ़ी के r4.16xlarge उदाहरण प्रकार पर, यह 1.5 गुना अधिक CPU उपयोग का प्रबंधन करता है, लेकिन बमुश्किल किसी भी अतिरिक्त पुनरावृत्तियों (जो मैं मान रहा हूं कि केवल सीपीयू पीढ़ी और रिट्रेसमेंट अनुक्रम की घातीय प्रकृति के कारण है)। अगर मैं 5s डिफ़ॉल्ट के बजाय 30 के लिए परीक्षण बढ़ाता हूं, तो ये संख्याएं बहुत सटीक रूप से पकड़ लेती हैं।

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

@PaulFurtado ने परीक्षण के लिए सबसे पहले आपको धन्यवाद दिया। मुझे लगता है कि आप कर्नेल.ऑर्ग 4.14 या ubuntu 4.14 चला रहे हैं, दोनों को इसमें 512ac999 है। के रूप में के रूप में पूरा किए गए फ़ाइबेस्टेस्ट इटरेशंस cpu समय का उपयोग करने के लिए उतना महत्वपूर्ण नहीं है, क्योंकि पूरा किए गए पुनरावृत्तियों cpu mhz द्वारा परीक्षण को चलाते समय भारी रूप से प्रभावित हो सकते हैं (विशेष रूप से क्लाउड में, जहां मुझे यकीन नहीं है कि आपका उस पर कितना नियंत्रण है)।

मुझे लगता है कि आप कर्नेल.ऑर्ग 4.14 या ubuntu 4.14 चला रहे हैं, दोनों को इसमें 512ac999 है।

हां, हम मुख्य लाइन 4.14 चलाते हैं (अच्छी तरह से, अमेज़ॅन लिनक्स 2 कर्नेल से पैच सेट, लेकिन उन पैच में से कोई भी इस मामले में मायने नहीं रखता है)।

512ac999 मेनलाइन 4.14.95 में उतरा, और हमने 4.14.77 से 4.14.121+ में अपग्रेड होने पर इसका प्रभाव देखा। इसने हमारे ज्ञापन वाले कंटेनरों (बहुत कम थ्रेड काउंट) को बेवजह थ्रॉटलिंग से थ्रॉटलिंग तक जाने दिया, लेकिन हमारे गोलंग और जावा कंटेनर (बहुत उच्च थ्रेड काउंट) को थ्रॉटलिंग का अधिक अनुभव दिया।

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

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

पहले परीक्षण के लिए धन्यवाद

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

बस एक नोट छोड़ना चाहते थे, कर्नेल पैच के बारे में चर्चा की जा रही है ...।

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

पैच आज सुबह टिप पर उतरा।
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=de53fd7aedb100f03e5d2231cfce0e4993282425

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

मैंने पैच (ubuntu 18.04, 5.2.7 कर्नेल, नोड: 56 कोर सीपीयू E5-2660 v4 @ 2.00GHz) का परीक्षण किया है, जो कि हमारे सीपीयू-भारी इमेज प्रोसेसिंग के साथ गोलंग माइक्रोसर्विस है और बहुत प्रभावशाली परिणाम मिला है। प्रदर्शन की तरह अगर मैं नोड पूर्णता पर सीएफएस को अक्षम करता हूं।

मुझे लगभग ५-३५% कम विलंबता और ५-५५% अधिक आरपीएस निकटवर्ती / सीपीयू उपयोग के आधार पर शून्य थ्रॉटलिंग दर पर मिला है।

धन्यवाद, @chiluk !

जैसा कि @jhertert ने कहा, cfs कोटा 100ms में वापस होना चाहिए, मैंने कम अवधि के साथ परीक्षण किया है और उच्च थ्रॉटलिंग और प्रदर्शन में गिरावट आई है।

गोलंग के साथ और अधिक प्रदर्शन के लिए GOMAXPROCS को छत (कोटा) +2 पर सेट करें। प्लस 2 कुछ संगणना की गारंटी है।

@chiluk का GOMAXPROCS = 8 बनाम GOMAXPROCS = 10 के साथ cpu.limit = 8 के साथ परीक्षण किया गया - बड़ा अंतर नहीं, 1-2% के बारे में कुछ।

@zigmund ऐसा इसलिए है क्योंकि आपका cpu.limit पूरे नंबर 8 पर सेट है, जिसे आपकी प्रक्रियाओं को 8 cpus के cpuset से बाँधना चाहिए। आपका 1-2% का अंतर सिर्फ आपके 8 cpu कार्यस्थल पर अपने 2 अतिरिक्त गोरोइन धावक के साथ संदर्भ के लिए ओवरहेड में वृद्धि है।

मुझे कहना चाहिए कि GOMAXPROCS = # को सेट करना गो कार्यक्रमों के लिए एक अच्छा समाधान है जब तक कि कर्नेल पैच व्यापक रूप से वितरित नहीं हो जाते।

हमने अपने उत्पादन समूहों को पैच कर्नेल में स्थानांतरित कर दिया है और अब मैं आपको कुछ दिलचस्प क्षण साझा कर सकता हूं।
हमारे समूहों में से एक से आँकड़े - 72 के 72 नोड्स E5-2695 v4 @ 2.10GHz, 128 जीबी रैम, डेबियन 9, 5.2.7 कर्नेल पैच के साथ।
हमारे पास मिश्रित भार हैं जिनमें ज्यादातर गोलंग सेवाएं शामिल हैं, लेकिन इसमें php और python भी हैं।

Golang। विलंबता कम है, सही GOMAXPROCS की स्थापना बिल्कुल होनी चाहिए। यहां डिफ़ॉल्ट GOMAXPROCS = 72 के साथ सेवा है। हमने ~ 16 पर कर्नेल बदल दिया है और उसके बाद विलंबता कम हो गई है और CPU उपयोग भारी हो गया है। 21:15 पर मैंने GOMAXPROCS और CPU उपयोग को सामान्यीकृत किया।

अजगर। पैच बिना किसी अतिरिक्त आंदोलनों के साथ सब कुछ बेहतर हो गया - सीपीयू उपयोग और विलंबता नीचे चली गई।

पीएचपी। सीपीयू का उपयोग समान है, विलंबता कुछ सेवाओं पर कम हो गई है। बड़ा लाभ नहीं।

धन्यवाद @zigmund
जब आप I setted correct GOMAXPROCS कहते हैं, तो मुझे यकीन नहीं है
मुझे लगता है कि आप 72 कोर नोड पर केवल एक पॉड नहीं चला रहे हैं, इसलिए आपने GOMAXPROCS को कुछ कम करने के लिए सेट किया है, शायद पॉड की सीपीयू सीमा के बराबर है?

धन्यवाद @zigmund जो परिवर्तन अपेक्षित था, उसके अनुरूप परिवर्तन बहुत अधिक हैं।

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

@ prune998 क्षमा करें, शायद गलत वर्तनी। मैंने GOMAXPROCS = limit.cpu निर्धारित किया है। फिलहाल हमारे पास इस क्लस्टर में प्रति नोड लगभग ~ 110 पॉड हैं।

@chiluk मैं अजगर में मजबूत नहीं हूं और यह नहीं जानता कि निचली परत पर पैच कैसे प्रभावित होता है। लेकिन आवेदन बिना किसी समस्या के स्वस्थ है, मैंने इसे कर्नेल परिवर्तन के बाद जाँच लिया है।

@chiluk क्या आप बताएंगे कि कैसे हम विभिन्न लिनक्स

@Nuru https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html?highlight=stable%20rules ... मूल रूप से मैं अपने पैच हिट्स लाइनस के एक बार लिनक्स-स्थिर के माध्यम से प्रस्तुत करूंगा। ' पेड़, * (शायद पहले), और फिर डिस्ट्रोस के सभी को लिनक्स-स्थिर प्रक्रिया का पालन करना चाहिए, और स्थिर अनुचर द्वारा उनके डिस्ट्रो विशिष्ट कर्नेल को स्वीकार किए गए पैच में खींचना चाहिए। यदि वे नहीं हैं, तो आपको अपना डिस्ट्रोस नहीं चलाना चाहिए।

@chiluk मैं लिनक्स विकास प्रक्रिया के बारे में कुछ नहीं जानता। "लाइनस ट्री" से क्या आपका मतलब https://github.com/torvalds/linux से है ?

लाइनस का पेड़ यहां रहता है, https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/। मेरे परिवर्तन वर्तमान में linux-next पर विकसित किए गए हैं जो विकास एकीकरण वृक्ष है। हाँ कर्नेल विकास अंधेरे युग में थोड़ा अटक गया है, लेकिन यह काम करता है।

वह संभवतः 5.3-जारी होने के बाद लिनक्स-अगले पेड़ से होने वाले बदलावों की ओर आकर्षित होगा और 5.4-आरसी 0 पर विकास शुरू करेगा। यह समय सीमा के आसपास है, मुझे उम्मीद है कि स्थिर गुठली इस फिक्स में खींचना शुरू कर देगी। जब भी लिनस को लगता है कि 5.3 स्थिर है तो किसी का अनुमान है।

[लिनस] संभवतः released.३ जारी होने के बाद लिनक्स-अगले पेड़ से होने वाले बदलावों की ओर खींचेगा और वह ५.४-आरसी ० पर विकास शुरू करता है। यह समय सीमा के आसपास है, मुझे उम्मीद है कि स्थिर गुठली इस फिक्स में खींचना शुरू कर देगी। जब भी लिनस को लगता है कि 5.3 स्थिर है तो किसी का अनुमान है।

@ लिलुक की तरह लगता है कि लिनस ने फैसला किया कि 5.3 15 सितंबर, 2019 को स्थिर था। तो, "linux-next" क्या है और हम अगले चरणों के माध्यम से आपके पैच की प्रगति को कैसे ट्रैक करते हैं?

क्या किसी ने डेबियन स्ट्रेच पैकेज और / या AWS छवि बनाई है जिसमें यह पैच शामिल है? मैं https://github.com/kubernetes-sigs/image-builder/tree/master/images/kube-deploy/imagebuilder का उपयोग करने वाला हूं

अगर यह पहले से मौजूद है तो मैंने सोचा कि मैं नकल के प्रयासों से बचूंगा

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

क्या किसी को पता है कि कैसे पालन करना है / अगर यह परिवर्तन इसे CentOS (7) में बदल देता है? यह सुनिश्चित नहीं है कि बैकपोर्टिंग आदि कैसे काम करता है।

@till https://github.com/kubernetes/kubernetes/issues/67577#issuecomment -531370333

स्थिर कर्नेल बातचीत के लिए यहाँ चल रहा है।
https://lore.kernel.org/stable/CAC=E7cUXpUDgpvsmMaMU6sAydbfD0FEJiK25R1r=e9=YtcPjGw@mail.gmail.com/

साथ ही क्यूबकॉन जाने वालों के लिए, मैं इस मुद्दे को वहां प्रस्तुत करूंगा।
https://sched.co/Uae1

अनुसूचक अनुरक्षकों के किसी भी शब्द पुन: ack ग्रेग एच.के. यह स्थिर पेड़ (ओं) में पाने के लिए देख रहा था?

ग्रेग केएच ने इस पैच के बारे में निर्णय लेने पर रोक लगा दी है क्योंकि अनुसूचक अनुरक्षक अनुत्तरदायी रहे हैं (संभवतः मेल से चूक गए थे)। एलकेएमएल पर मेरे अलावा किसी और से टिप्पणी करें जिसने इस पैच का परीक्षण किया है और सोचता है कि इसे बैकपोर्ट किया जाना चाहिए।

CoreOS का उपयोग करने वाले लोगों के लिए, एक खुला मुद्दा है जिसमें अनुरोध किया गया है कि @chiluk का पैच बैकपोर्ट हो।

CoreOS कर्नेल 4.19.82 में फ़िक्सेस हैं: https://github.com/coreos/linux/pull/364
CoreOS कंटेनर लिनक्स 2317.0.1 (अल्फा चैनल) में फ़िक्सेस हैं: https://github.com/coreos/coreos-overlay/pull/3796 http://coreos.com/releases/#2317.0.1

लिनक्स स्थिर के लिए बैकपॉट्स ठप दिखाई देते हैं क्योंकि पैच साफ-सुथरे ढंग से लागू नहीं होते हैं । @chiluk क्या आप लिनक्स के लिए kops ? हालांकि मुझे लगता है कि इसे "खिंचाव" में लाने के लिए 6 महीने तक का समय लगने वाला है और शायद तब तक kops "बस्टर" में माइग्रेट हो गया होगा।

@Nuru , मैंने पैच को बैकपोर्ट किया और स्ट्रेच पैकेज (स्ट्रेच-बैकस्पोर्ट्स कर्नेल के आधार पर) और एक kops 1.11-फ्रेंडली एएमआई यदि आप परीक्षण करना चाहते हैं:

https://pm-kops-dev.s3.amazonaws.com/kernel-packages/linux-4.19.67-pm_4.19.67-1_amd64.buildinfo
https://pm-kops-dev.s3.amazonaws.com/kernel-packages/linux-image-4.19.67-pm_4.19.67-1_amd64.deb
https://pm-kops-dev.s3.amazonaws.com/kernel-packages/linux-image-4.19.67-pm-dbg_4.19.67-1_amd64.deb
https://pm-kops-dev.s3.amazonaws.com/kernel-packages/linux-headers-4.19.67-pm_4.19.67-1_amd64.deb
https://pm-kops-dev.s3.amazonaws.com/kernel-packages/linux-4.19.67-pm_4.19.67-1_amd64.changes
https://pm-kops-dev.s3.amazonaws.com/kernel-packages/linux-libc-dev_4.19.67-1_amd64.deb

293993587779 / k8s-1.11-डेबियन-खिंचाव-amd64-hvm-EBS-2019/09/26

@blakebarnett आपके प्रयास के लिए धन्यवाद, और आपको परेशान करने के लिए क्षमा करें, लेकिन मैं थोड़ा भ्रमित हूं।

• "खिंचाव" लिनक्स 4.9 पर आधारित है, लेकिन आपके सभी लिंक 4.19 के लिए हैं।
• आप कहते हैं कि आपने "पैच" को वापस भेज दिया है, लेकिन 3 पैच हैं (मुझे लगता है कि तीसरा वास्तव में महत्वपूर्ण नहीं है:
  
  
  
  1. 512ac999 शेड्यूल / फेयर: बैंडविड्थ टाइमर घड़ी बहाव की स्थिति को ठीक करें
  
  
  2. de53fd7ae शेड्यूल / फेयर: सीपीयू-स्थानीय लोगों की समाप्ति को हटाकर उच्च थ्रॉटलिंग के साथ कम सीपीयू उपयोग को ठीक करें
  
  
  3. 763a9ec06 शेड्यूल / फेयर: फिक्स-वंचित-लेकिन-सेट-चर चेतावनियाँ
  
  

क्या आपने सभी 3 पैच को 4.9 पर वापस कर दिया है? (मुझे नहीं पता कि डेबियन पैकेज को देखने और देखने के लिए क्या करना है अगर परिवर्तन वहां हैं, और "परिवर्तन" दस्तावेज़ यह नहीं बताता है कि वास्तव में क्या बदल गया है।)

इसके अलावा, आपका एएमआई किन क्षेत्रों में उपलब्ध है?

नहीं, मैंने स्ट्रेच-बैकस्पोर्ट कर्नेल का उपयोग किया, जो कि 4.19 है, क्योंकि इसमें फिक्स हैं जो हमें AWS पर भी आवश्यक हैं (विशेष रूप से M5 / C5 उदाहरण के प्रकार के लिए)

मैंने एक ऐसा तरीका लागू किया है जिसमें मेरे द्वारा विश्वास किए गए सभी पैच शामिल हैं, मुझे 4.19 में चरों के अतिरिक्त संदर्भों को हटाने के लिए इसे थोड़ा बदलना पड़ा, जिसे मैंने कहीं और हटा दिया था, मैंने पहली बार यह https://github.com/kubernetes/kubernetes/issues/67577 लागू किया था

--- kernel/sched/fair.c 2019-09-25 16:06:02.954933954 -0700
+++ kernel/sched/fair.c-b   2019-09-25 16:06:56.341615817 -0700
@@ -4928,8 +4928,6 @@

    cfs_b->period_active = 1;
    overrun = hrtimer_forward_now(&cfs_b->period_timer, cfs_b->period);
-   cfs_b->runtime_expires += (overrun + 1) * ktime_to_ns(cfs_b->period);
-   cfs_b->expires_seq++;
    hrtimer_start_expires(&cfs_b->period_timer, HRTIMER_MODE_ABS_PINNED);
 }

--- kernel/sched/sched.h    2019-08-16 01:12:54.000000000 -0700
+++ sched.h.b   2019-09-25 13:24:00.444566284 -0700
@@ -334,8 +334,6 @@
    u64         quota;
    u64         runtime;
    s64         hierarchical_quota;
-   u64         runtime_expires;
-   int         expires_seq;

    short           idle;
    short           period_active;
@@ -555,8 +553,6 @@

 #ifdef CONFIG_CFS_BANDWIDTH
    int         runtime_enabled;
-   int         expires_seq;
-   u64         runtime_expires;
    s64         runtime_remaining;

    u64         throttled_clock;

एएमआई हमें-पश्चिम -1 से प्रकाशित होता है

उम्मीद है की वो मदद करदे!

मैंने इन पैचों को वापस भेज दिया है और उन्हें लिनक्स-स्थिर गुठली के लिए प्रस्तुत किया है
v4.14 https://lore.kernel.org/stable/[email protected]/
v4.19 https://lore.kernel.org/stable/[email protected]/ #t

नमस्ते,
4.19 शाखा पर पैच के एकीकरण के बाद, मैंने बीन पर एक बग रिपोर्ट खोली है, जो बस्टर और स्ट्रेच-बैकपोर्ट पर कीनर के उचित उन्नयन के लिए है:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946144

डेबियन पैकेज के उन्नयन के लिए नई टिप्पणी जोड़ने में संकोच न करें।

आशा है कि यह बहुत अधिक स्पैम नहीं है, लेकिन मैं इस मुद्दे से जुड़े कई पृष्ठभूमि विवरण @chiluk से इस उत्कृष्ट बातचीत को जोड़ना चाहता था https://youtu.be/UE7QX98-kO0।

क्या जीकेटी पर थ्रॉटलिंग से बचने का एक तरीका है? हमारे पास बहुत बड़ा मुद्दा था जहां php कंटेनर पर एक विधि सामान्य 0.1 s के बजाय 120s ले रही थी

सीपीयू सीमा हटा दें

हमने पहले ही किया था, सीपीयू अनुरोध बहुत छोटा होने पर कंटेनर को थ्रॉटल किया जा रहा है। यह समस्या का मूल है, सीमाओं की कमी और केवल सीपीयू अनुरोधों का उपयोग करना अभी भी थ्रॉटलिंग को जन्म देगा :(

@bartoszhernas मुझे लगता है कि आप यहाँ गलत शब्द का उपयोग कर रहे हैं। जब इस थ्रेड पर लोग "थ्रॉटलिंग" का संदर्भ देते हैं तो वे cfs बैंडविड्थ नियंत्रण की बात कर रहे हैं, crroup के लिए cpu.stat में nr_throttled। यह केवल तभी सक्षम होता है जब सीपीयू सीमाएं सक्षम होती हैं। जब तक जीके आपकी जानकारी के बिना आपकी पॉड में सीमाएं जोड़ रहा है, तब तक मैं यह नहीं कहूंगा कि आप थ्रॉटलिंग के रूप में क्या कह रहे हैं।

मुझे लगता है कि आपने "प्रोसेसर के लिए विवाद" का वर्णन किया है। मुझे संदेह है कि आपके पास संभवतः कई गलत आकार के अनुप्रयोग * (अनुरोध) हैं, जो बॉक्स पर प्रोसेसर या अन्य संसाधन के लिए प्रतिस्पर्धा कर रहे हैं क्योंकि वे अक्सर अनुरोध किए गए से अधिक का उपयोग कर रहे हैं। यह सटीक कारण है कि हम सीमा का उपयोग करते हैं। ताकि उन अनुचित आकार के एप्लिकेशन केवल बॉक्स पर अन्य अनुप्रयोगों को इतना प्रभावित कर सकें।

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

90 डी निष्क्रियता के बाद मुद्दे बासी हो जाते हैं।
/remove-lifecycle stale साथ ताज़ा अंक को चिह्नित करें।
अतिरिक्त 30 डी निष्क्रियता के बाद बासी मुद्दे सड़ जाते हैं और अंततः बंद हो जाते हैं।

यदि यह समस्या अब बंद करने के लिए सुरक्षित है, तो कृपया /close साथ ऐसा करें।

सिग-टेस्टिंग, कुबेरनेट्स / टेस्ट-इन्फ्रा और / या फ़ेज्टा पर प्रतिक्रिया भेजें।
/ जीवनचक्र बासी

/ हटाने-जीवन चक्र बासी

मेरी समझ से, कर्नेल में अंतर्निहित मुद्दा तय हो गया और उदाहरण के लिए https://github.com/coreos/bugs/issues/2623 में कंटेनर उपलब्ध कराया गया
किसी को भी इस कर्नेल पैच के बाद शेष मुद्दों के बारे में पता है?

@sfudeus Kubernetes को लिनक्स के किसी भी स्वाद पर चलाया जा सकता है, या AFAIK, यूनिक्स के किसी भी पॉसिट-कंप्लेंट फ्लेवर पर। यह बग कभी भी लिनक्स का उपयोग नहीं करने वाले लोगों के लिए एक मुद्दा था, कुछ लिनक्स-व्युत्पन्न वितरण के लिए तय किया गया है, और दूसरों के लिए तय नहीं किया गया है।

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

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

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

यकीन नहीं होता है कि यह लोगों को सूचित करने के लिए सही जगह है, लेकिन वास्तव में यह सुनिश्चित नहीं है कि इसे कहां लाया जाए:

हम डेबियन बस्टर पर 5.4 लिनक्स कर्नेल (बस्टर-बैकपोर्ट कर्नेल का उपयोग करके) k8s 1.15.10 क्लस्टर का उपयोग कर रहे हैं और हम अभी भी इसके साथ समस्याएँ देख रहे हैं। विशेष रूप से उन पॉड्स के लिए जो आमतौर पर बहुत कम होते हैं (क्यूब-डाउनस्केलर वह उदाहरण है जिसे हम वापस लौटाते रहते हैं, जिसमें आमतौर पर लगभग 3 मी सीपीयू की आवश्यकता होती है) और जिनके पास बहुत कम सीपीयू संसाधन हैं (हमारे में क्यूब-डाउनस्कॉलर के मामले में 50 मीटर) क्लस्टर) हम अभी भी एक बहुत उच्च थ्रॉटलिंग मान देखते हैं। संदर्भ के लिए, क्यूब-डाउनस्कूलर मूल रूप से एक पायथन लिपि है, जो कुछ भी करने से पहले 30 मिनट के लिए sleep चलती है। cAdvisor इस कंटेनर के कंटेनर /cpu_cfs_throttled_periods_total की वृद्धि को दर्शाता है कि इस कंटेनर के कंटेनर_cpu_cfs_periods_total मान के समान हमेशा कम या ज्यादा होते हैं (दोनों 5m अंतराल पर वृद्धि की जाँच करते समय 250 के आसपास होते हैं)। हम उम्मीद करेंगे कि थ्रॉटल अवधि 0 के पास होगी।

क्या हम इसे गलत तरीके से माप रहे हैं? क्या cAdvisor गलत डेटा आउटपुट कर रहा है? क्या हमारी धारणा सही है कि हमें थ्रॉटल अवधि में गिरावट दिखनी चाहिए? किसी भी सलाह की यहाँ सराहना की जाएगी।

5.4 कर्नेल पर स्विच करने के बाद हमने देखा कि इस समस्या के साथ पॉड्स की संख्या थोड़ी कम (लगभग 40%) है, लेकिन हम वर्तमान में अनिश्चित हैं कि हम जो देख रहे हैं वह वास्तविक समस्या है या नहीं। मुख्य रूप से, जब हम उपरोक्त आंकड़ों को देखते हैं तो हमें यकीन नहीं होता है कि "थ्रॉटलिंग" का वास्तव में यहाँ क्या मतलब है अगर हमें ये मूल्य 3 मी औसत सीपीयू उपयोग के साथ मिलते हैं। यह जिस नोड पर चल रहा है, वह बिल्कुल भी ओवरकम नहीं है और इसमें 10% से कम का औसत CPU उपयोग होता है।

@ टाइमस्टॉप अंतराल के बारे में जो अनुसूचक की परवाह करता है, वे माइक्रोसेकंड के दायरे में हैं, 30 मिनट की बड़ी सीमाएं नहीं। यदि कंटेनर में 50 मिली सेकेंड की सीपीयू सीमा है और वह 100 माइक्रोसेकंड की अवधि में 50 मिली सेकेंड का उपयोग करता है, तो यह 30 मिनट बेकार बिताने की परवाह किए बिना, थ्रॉटल हो जाएगा। सामान्य तौर पर, 50 मिली सेकेंड एक बहुत छोटी सीपीयू सीमा होती है। यदि एक अजगर कार्यक्रम भी एक HTTPS अनुरोध को एक सीमा से कम कर देता है, तो यह बहुत अधिक गला घोंटना है।

यह जिस नोड पर चल रहा है, वह बिल्कुल भी ओवरकम नहीं है और इसमें 10% से कम का औसत CPU उपयोग होता है।

बस स्पष्ट करने के लिए: नोड का भार और उस पर अन्य कार्यभार का थ्रॉटलिंग से कोई लेना-देना नहीं है। थ्रॉटलिंग केवल कंटेनर / cgroup की अपनी सीमा पर विचार कर रहा है।

@PaFFurtado आपके उत्तर के लिए धन्यवाद! हालाँकि, पॉड में उस नींद के दौरान औसतन 3 m cpu का उपयोग होता है और यह अभी भी थ्रॉटल हो रहा है। यह उस दौरान कोई अनुरोध नहीं कर रहा है, यह नींद पर इंतजार कर रहा है। मुझे उम्मीद है कि यह ऐसा कर सकता है, जबकि 50 मी नहीं मार रहा है, है ना? या फिर यह एक गलत धारणा है?

मुझे लगता है कि यह सिर्फ इतनी कम संख्या होने की संभावना है कि सटीकता के मुद्दे होने जा रहे हैं। और 50 मीटर इतना कम है कि कुछ भी इसे यात्रा कर सकता है। पायथन का रनटाइम आपके सोते समय भी थ्रेड्स में बैकग्राउंड टास्क कर रहा हो सकता है।

आप सही थे, मैं ऐसी धारणाएँ बना रहा था जो सच नहीं थीं। आपके मार्गदर्शन के लिए धन्यवाद! यह अब मेरे लिए समझ में आ रहा है।

बस में कूदना चाहता था और कहना चाहता था कि कर्नेल पैच के 4.19 एलटीएस कर्नेल पर हिट करने के बाद से यहां चीजों में काफी सुधार हुआ है, और यह कोरओएस / फ्लैटकार पर दिखाई दिया। इस समय, केवल चीजें जो मुझे थर्राती हुई दिखाई दे रही हैं, वे एक दो चीजें हैं, जिन पर मुझे शायद सीमा बढ़ानी चाहिए। :मुस्कुराओ:

@sfudeus @chiluk यह देखने के लिए कोई सरल परीक्षण है कि क्या आपके कर्नेल में यह तय है या नहीं?

मैं नहीं बता सकता कि क्या kope.io/k8s-1.15-debian-stretch-amd64-hvm-ebs-2020-01-17 (वर्तमान आधिकारिक kops छवि) पैच किया गया है या नहीं।

मैं स्थिर सीपीयू नीति के तहत अनन्य सीपीयू पर चलने वाली पॉड्स के लिए @ मर्सिएग्रिगोरियू से सहमत हूं, हम बस सीपीयू कोटा सीमा को अक्षम कर सकते हैं - यह केवल वैसे भी अपने विशेष सीपीयू सेट पर चल सकता है। ऊपर पैच इस उद्देश्य के लिए है और केवल इस प्रकार की फली के लिए है।

@Nuru मैंने https://github.com/indeedeng/fibtest लिखा है
यह एक परीक्षण के बारे में निश्चित है जैसा कि आप प्राप्त कर सकते हैं, लेकिन आपको सी कंपाइलर की आवश्यकता होगी।

पूर्ण किए गए पुनरावृत्तियों की संख्या पर ध्यान न दें, लेकिन एकल थ्रेडेड मल्टी-थ्रेडेड रन के लिए उपयोग किए जाने वाले समय की मात्रा पर ध्यान दें।

मुझे यह देखने का एक अच्छा तरीका है कि क्या कर्नेल को पैच किया गया है, @chiluk (इस btw के लिए धन्यवाद) से अंतिम स्लाइड्स में से एक है https://www.youtube.com/watch?v=UE7QX98-kO0

कर्नेल 4.15.0-67 में पैच लगता है (https://launchpad.net/ubuntu/+source/linux/4.15.0-67.76) हालांकि, हम अभी भी कुछ पॉड्स में थ्रॉटलिंग देख रहे हैं जहां अनुरोध / सीमा ऊपर है उनके CPU उपयोग।
मैं लगभग 50ms के उपयोग के बारे में बात कर रहा हूँ, जो 250 मी पर सेट है और 500 मी तक सीमित है। हम लगभग 50% CPU पीरियड्स को थ्रोट होने के रूप में देख रहे हैं, क्या यह मान शायद काफी कम है जो अपेक्षित है और स्वीकार किया जा सकता है? मैं इसे शून्य से नीचे देखना चाहता हूं, अगर उपयोग सीमा के करीब भी नहीं है, तो हमें बिल्कुल भी नहीं फेंकना चाहिए।

क्या कोई नए गद्देदार कर्नेल का उपयोग कर रहा है जो अभी भी कुछ थ्रॉटलिंग कर रहा है?

@ vgarcia-te एक सूची से जानने के लिए अभी तक बहुत सारे कर्नेल घूम रहे हैं जिन्हें पैच किया गया है और जो नहीं किया गया है। इस मुद्दे को संदर्भित करने वाले सभी कमिटों को देखें। सैंकडो। उबंटू के लिए चैंज के मेरे पढ़ने से पता चलता है कि 4.15 को अभी तक पैच नहीं किया गया है (एज़्योर पर चलने के लिए mabye को छोड़कर), और आपके द्वारा लिंक किए गए पैच को अस्वीकार कर दिया गया था।

व्यक्तिगत रूप से, मुझे 4.9 सीरीज़ में दिलचस्पी है क्योंकि यही kops का उपयोग कर रहा है, और जब वे एएमआई को एक फिक्स के साथ जारी करते हैं, तो यह जानना चाहेंगे।

इस बीच, आप @bobrik का परीक्षण चलाने की कोशिश कर सकते हैं जो मुझे बहुत अच्छा लगता है।

wget https://gist.githubusercontent.com/bobrik/2030ff040fad360327a5fab7a09c4ff1/raw/9dcf83b821812064fa7fb056b8f22cbd5c4364f1/cfs.go

sudo docker run --rm -it --cpu-quota 20000 --cpu-period 100000 -v $(pwd):$(pwd) -w $(pwd) golang:1.9.2 go run cfs.go -iterations 15 -sleep 1000ms

ठीक से काम करने वाले सीएफएस के साथ, जला समय हमेशा 5ms होगा। प्रभावित गुठली के साथ, मैंने उपरोक्त संख्याओं का उपयोग करके परीक्षण किया है, मैं अक्सर 99ms का जला हुआ समय देखता हूं। 6ms से अधिक कुछ भी एक समस्या है।

@ इस मुद्दे को खोजने के लिए स्क्रिप्ट के लिए धन्यवाद वहाँ है या नहीं।

@justinsb कृपया सुझाव दें कि डिफ़ॉल्ट कोप्स इमेज में पैच है या नहीं
https://github.com/kubernetes/kops/blob/master/channels/stable

एक मुद्दा खोला: https://github.com/kubernetes/kops/issues/8954

https://github.com/kubernetes/kubernetes/issues/67577#issuecomment -617586330

अद्यतन: kops 1.15 छवि में परीक्षण दौड़ा, गैर-आवश्यक थ्रॉटलिंग है https://github.com/kubernetes/kops/issues/8954#issuecomment -617673755

@Nuru

2020/04/22 11:02:48 [0] burn took 5ms, real time so far: 5ms, cpu time so far: 6ms
2020/04/22 11:02:49 [1] burn took 5ms, real time so far: 1012ms, cpu time so far: 12ms
2020/04/22 11:02:50 [2] burn took 5ms, real time so far: 2017ms, cpu time so far: 18ms
2020/04/22 11:02:51 [3] burn took 5ms, real time so far: 3023ms, cpu time so far: 23ms
2020/04/22 11:02:52 [4] burn took 5ms, real time so far: 4028ms, cpu time so far: 29ms
2020/04/22 11:02:53 [5] burn took 5ms, real time so far: 5033ms, cpu time so far: 35ms
2020/04/22 11:02:54 [6] burn took 5ms, real time so far: 6038ms, cpu time so far: 40ms
2020/04/22 11:02:55 [7] burn took 5ms, real time so far: 7043ms, cpu time so far: 46ms
2020/04/22 11:02:56 [8] burn took 5ms, real time so far: 8049ms, cpu time so far: 51ms
2020/04/22 11:02:57 [9] burn took 5ms, real time so far: 9054ms, cpu time so far: 57ms
2020/04/22 11:02:58 [10] burn took 5ms, real time so far: 10059ms, cpu time so far: 63ms
2020/04/22 11:02:59 [11] burn took 5ms, real time so far: 11064ms, cpu time so far: 69ms
2020/04/22 11:03:00 [12] burn took 5ms, real time so far: 12069ms, cpu time so far: 74ms
2020/04/22 11:03:01 [13] burn took 5ms, real time so far: 13074ms, cpu time so far: 80ms
2020/04/22 11:03:02 [14] burn took 5ms, real time so far: 14079ms, cpu time so far: 85ms

उन परिणामों से हैं

Linux <servername> 4.15.0-96-generic #97-Ubuntu SMP Wed Apr 1 03:25:46 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

यह ubuntu 18.04 में एक डिफ़ॉल्ट नवीनतम स्थिर ubuntu कर्नेल है।

तो, ऐसा लगता है कि पैच है ।

@zerkms उबुन्टु 18.04 पर आपने अपने परीक्षण कहाँ चलाए? यह मुझे ऐसा लगता है जैसे पैच ने इसे केवल एज़्योर के लिए कर्नेल में बनाया हो। यदि आप एक रिलीज़ नोट यह कहते हुए पा सकते हैं कि यह उबंटू linux पैकेज के लिए लागू किया गया था तो कृपया साझा करें। मैं इसे नहीं ढूँढ सकता।

यह भी ध्यान दें कि यह परीक्षण कोरओएस पर समस्या को पुन: पेश करने में सक्षम नहीं था। यह हो सकता है कि डिफ़ॉल्ट कॉन्फ़िगरेशन में सीएफएस शेड्यूलिंग विश्व स्तर पर अक्षम थी।

@Nuru

उबुन्टु १ tests.०४ पर आपने अपने परीक्षण कहाँ चलाए?

मेरा एक सर्वर।

मैंने रिलीज़ नोटों की जांच नहीं की, मुझे यह भी पता नहीं है कि क्या देखना है, और फिर भी - यह सभी की तरह एक डिफ़ॉल्ट कर्नेल है। 🤷

पैच यहां ubuntus कर्नेल गिट में होना चाहिए:
https://kernel.ubuntu.com/git/ubuntu/ubuntu-bionic.git/commit/?id=aadd794e744086fb50cdc752d54044fbc14d4adb

और यहाँ ubuntu बग इसके बारे में:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1832151

यह बायोनिक में जारी किया जाना चाहिए।
आप apt-get source linux चलाकर सुनिश्चित कर सकते हैं और डाउनलोड किए गए स्रोत कोड में जांच कर सकते हैं।

@zerkms द्वारा "आपने अपने परीक्षण कहां चलाए" मेरा मतलब है कि यह आपके कार्यालय में एक सर्वर, जीसीपी, एडब्ल्यूएस, एज़्योर या कहीं और का सर्वर था?

जाहिर है कि बहुत कुछ मुझे इस बारे में समझ नहीं आया कि उबंटू को कैसे वितरित और रखरखाव किया जाता है। मैं आपके uname -a आउटपुट से भी भ्रमित हूं। उबंटू रिलीज नोट्स कहते हैं:

18.04.4 में v5.0 आधारित कर्नेल से अद्यतन v5.3 आधारित लिनक्स कर्नेल के साथ 18.04.4 जहाज।

और यह भी कहते हैं कि 18.04.4 12 फरवरी, 2020 को जारी किया गया था। आपका आउटपुट कहता है कि आप 1 अप्रैल, 2020 को संकलित एक v4.15 कर्नेल चला रहे हैं।

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

जब मैं लॉन्चपैड बग टिप्पणियों को देखता हूं तो देखता हूं

• यह बग पैकेज linux-azure - 5.0.0-1027.29 में तय किया गया था
• यह बग पैकेज linux-azure - 5.0.0-1027.29 ~ 18.04.1 में तय किया गया था

लेकिन यह विशिष्ट पैच ( sched/fair: Fix low cpu usage with high throttling by removing expiration of cpu-local slices ) के अंतर्गत सूचीबद्ध नहीं है

• यह बग पैकेज लाइनक्स में तय किया गया था - 4.15.0-69.78

मैं "1832151" को भी Ubuntu 18.04.4 रिलीज़ नोटों में सूचीबद्ध नहीं देखता।

एक पिछली टिप्पणी में कहा गया था कि इसे 4.15.0-67.76 में पैच किया गया था लेकिन मुझे कोई linux-image-4.15.0-67-generic पैकेज नहीं दिखता है।

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

मुझे आशा है कि अब आप देखेंगे कि मुझे विश्वास नहीं है कि यह पैच वास्तव में Ubuntu 18.04.4 में शामिल किया गया था, जो कि 18.04 का वर्तमान संस्करण है। My _best का अनुमान है कि यह 18.04.4 के रिलीज़ होने के बाद कर्नेल अपडेट के रूप में जारी किया गया था, और संभवत: इसमें शामिल है यदि आपके Ubuntu कर्नेल 4.15.0-69 या बाद में रिपोर्ट करता है, लेकिन यदि आप सिर्फ 18.04.4 डाउनलोड करते हैं और इसे अपडेट नहीं करते हैं, तो यह पैच नहीं होगा।

मैंने अभी-अभी उस टेस्ट (बहुत उपयोगी) को कर्नेल 4.15.0-72 में एक डेटासेंटर में नंगेमेट सर्वर में चलाया और ऐसा लगता है कि पैच वहाँ है:

2020/04/22 21:24:27 [0] burn took 5ms, real time so far: 5ms, cpu time so far: 7ms
2020/04/22 21:24:28 [1] burn took 5ms, real time so far: 1010ms, cpu time so far: 13ms
2020/04/22 21:24:29 [2] burn took 5ms, real time so far: 2015ms, cpu time so far: 20ms
2020/04/22 21:24:30 [3] burn took 5ms, real time so far: 3020ms, cpu time so far: 25ms
2020/04/22 21:24:31 [4] burn took 5ms, real time so far: 4025ms, cpu time so far: 32ms
2020/04/22 21:24:32 [5] burn took 5ms, real time so far: 5030ms, cpu time so far: 38ms
2020/04/22 21:24:33 [6] burn took 5ms, real time so far: 6036ms, cpu time so far: 43ms
2020/04/22 21:24:34 [7] burn took 5ms, real time so far: 7041ms, cpu time so far: 50ms
2020/04/22 21:24:35 [8] burn took 5ms, real time so far: 8046ms, cpu time so far: 56ms
2020/04/22 21:24:36 [9] burn took 5ms, real time so far: 9051ms, cpu time so far: 63ms
2020/04/22 21:24:37 [10] burn took 5ms, real time so far: 10056ms, cpu time so far: 68ms
2020/04/22 21:24:38 [11] burn took 5ms, real time so far: 11061ms, cpu time so far: 75ms
2020/04/22 21:24:39 [12] burn took 5ms, real time so far: 12067ms, cpu time so far: 81ms
2020/04/22 21:24:40 [13] burn took 5ms, real time so far: 13072ms, cpu time so far: 86ms
2020/04/22 21:24:41 [14] burn took 5ms, real time so far: 14077ms, cpu time so far: 94ms

मैं यह भी देख सकता हूँ कि कर्नेल में समान 4.9.164 एक ही प्रकार के सर्वर शो 5ms से अधिक जलते हैं:

2020/04/22 21:24:41 [0] burn took 97ms, real time so far: 97ms, cpu time so far: 8ms
2020/04/22 21:24:42 [1] burn took 5ms, real time so far: 1102ms, cpu time so far: 12ms
2020/04/22 21:24:43 [2] burn took 5ms, real time so far: 2107ms, cpu time so far: 16ms
2020/04/22 21:24:44 [3] burn took 5ms, real time so far: 3112ms, cpu time so far: 24ms
2020/04/22 21:24:45 [4] burn took 83ms, real time so far: 4197ms, cpu time so far: 28ms
2020/04/22 21:24:46 [5] burn took 5ms, real time so far: 5202ms, cpu time so far: 32ms
2020/04/22 21:24:47 [6] burn took 94ms, real time so far: 6297ms, cpu time so far: 36ms
2020/04/22 21:24:48 [7] burn took 99ms, real time so far: 7397ms, cpu time so far: 40ms
2020/04/22 21:24:49 [8] burn took 100ms, real time so far: 8497ms, cpu time so far: 44ms
2020/04/22 21:24:50 [9] burn took 5ms, real time so far: 9503ms, cpu time so far: 52ms
2020/04/22 21:24:51 [10] burn took 5ms, real time so far: 10508ms, cpu time so far: 60ms
2020/04/22 21:24:52 [11] burn took 5ms, real time so far: 11602ms, cpu time so far: 64ms
2020/04/22 21:24:53 [12] burn took 5ms, real time so far: 12607ms, cpu time so far: 72ms
2020/04/22 21:24:54 [13] burn took 5ms, real time so far: 13702ms, cpu time so far: 76ms
2020/04/22 21:24:55 [14] burn took 5ms, real time so far: 14707ms, cpu time so far: 80ms

तो, मेरी समस्या यह है कि मैं अभी भी सीपीयू थ्रॉटलिंग देखता हूं यहां तक ​​कि मेरे कर्नेल को पैच लगता है

@ नरू सही, सॉरी। यह मेरा नंगे धातु सर्वर कार्यालय में होस्ट किया गया था।

और यह भी कहते हैं कि 18.04.4 12 फरवरी, 2020 को जारी किया गया था। आपका आउटपुट कहता है कि आप 1 अप्रैल, 2020 को संकलित एक v4.15 कर्नेल चला रहे हैं।

ऐसा इसलिए है क्योंकि यह एक सर्वर एलटीएस है: आपको नए कर्नेल रखने के लिए स्पष्ट रूप से इसके साथ HWE में ऑप्ट-इन करने की आवश्यकता है, अन्यथा आप केवल रनलाइन चलाते हैं।

और मेनलाइन और HWE कर्नेल दोनों को नियमित रूप से जारी किया जाता है, इसलिए हाल ही में निर्मित कर्नेल होने में कुछ भी संदेह नहीं है: http://changelogs.ubuntu.com/changelogs/pool/main/l/linux-meta/linux-meta_4.15.0.96.87/ बदलाव का

@zerkms जानकारी के लिए धन्यवाद। मैं उलझन में रहता हूं, लेकिन मुझे शिक्षित करने के लिए यह जगह नहीं है।

@ vgarcia-te यदि आपका कर्नेल पैच है, जो ऐसा लगता है, तो थ्रॉटलिंग इस बग के कारण नहीं है। आपके कहने पर मुझे आपकी शब्दावली पर यकीन नहीं है:

मैं लगभग 50ms के उपयोग के बारे में बात कर रहा हूँ, जो 250 मी पर सेट है और 500 मी तक सीमित है। हम लगभग 50% CPU पीरियड्स को थ्रोट होने के रूप में देख रहे हैं, क्या यह मान शायद काफी कम है जो अपेक्षित है और स्वीकार किया जा सकता है?

Kubernetes CPU संसाधन को CPU में मापा जाता है, 1 का अर्थ 1 पूर्ण CPU का 100%, 1m का अर्थ है 1 CPU का 0.1%। तो "500 मी" की आपकी सीमा 0.5 सीपीयू की अनुमति देती है।

सीएफएस के लिए डिफ़ॉल्ट समय-निर्धारण अवधि 100ms है, इसलिए 0.5 सीपीयू की सीमा निर्धारित करने से आपकी प्रक्रिया प्रत्येक 100ms सीपीयू की 50 सेंटीमीटर तक सीमित हो जाएगी। यदि आपकी प्रक्रिया इससे अधिक होने का प्रयास करती है, तो यह थ्रॉटल हो जाएगा। यदि आपकी प्रक्रिया आम तौर पर एक पास में 50ms से अधिक चलती है, तो हाँ, आप यह अपेक्षा करेंगे कि आप एक उचित समयबद्धक द्वारा थ्रॉटल प्राप्त करें।

@Nuru जो समझ में आता है, लेकिन मुझे यह समझने दो, यह देखते हुए कि डिफ़ॉल्ट सीपीयू की अवधि 100ms है, अगर किसी प्रक्रिया में 1 सीपीयू सौंपा जाता है, अगर यह प्रक्रिया एक ही पास में 100ms से अधिक के लिए चलती है, तो क्या इसे थ्रॉटल किया जाएगा?
क्या इसका मतलब यह है कि लिनक्स में, जहां डिफ़ॉल्ट सीपीयू अवधि 100ms है, किसी भी प्रक्रिया जिसमें एक सीमा में 100ms से अधिक के लिए एक सीमा होती है, थ्रोटल होने वाली है?

एक प्रक्रिया के लिए एक अच्छी सीमा विन्यास क्या होगा जो एक ही पास में 100ms से अधिक समय लेता है लेकिन यह अपने बाकी समय में बेकार है?

@ वगरसिया-ते ने पूछा

यह देखते हुए कि डिफ़ॉल्ट सीपीयू अवधि 100ms है, मामले में एक प्रक्रिया को 1 सीपीयू सौंपा जाता है, यदि यह प्रक्रिया एक पास में 100ms से अधिक के लिए चलती है, तो क्या इसे थ्रॉटल किया जाएगा?

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

सभी यूनिक्स प्रक्रिया समय स्लाइस के आधार पर प्रीमेप्टिव शेड्यूलिंग के अधीन हैं। सिंगल कोर सिंगल सीपीयू दिनों में, आपके पास अभी भी "एक साथ" चलने वाली 30 प्रक्रियाएँ थीं। क्या होता है कि वे थोड़ी देर के लिए दौड़ते हैं और या तो सोते हैं या, अपने समय के अंत में स्लाइस करते हैं, ताकि कुछ और चल सके।

कोटा के साथ सीएफएस एक कदम और आगे ले जाता है।

अपने आप से पूछें, हालाँकि, जब आप कहते हैं कि आप 50% सीपीयू का उपयोग करने के लिए एक प्रक्रिया चाहते हैं, तो आप वास्तव में क्या कह रहे हैं? क्या आप यह कह रहे हैं कि यह ठीक है यदि यह 100% सीपीयू को 5 मिनट तक लंबे समय तक टिकाए रखता है तो यह अगले 5 मिनटों तक नहीं चलता है? यह 10 मिनट में 50% उपयोग होगा, लेकिन विलंबता के मुद्दों के कारण यह ज्यादातर लोगों के लिए स्वीकार्य नहीं है।

तो सीएफएस एक "सीपीयू अवधि" को परिभाषित करता है जो उस समय की खिड़की है जिस पर यह कोटा लागू करता है। 4 कोर और 100ms सीपीयू अवधि के साथ एक मशीन पर, अनुसूचक के पास 100ms से अधिक वास्तविक (दीवार घड़ी) समय आवंटित करने के लिए सीपीयू समय होता है। यदि आप निष्पादन के एक एकल धागे को चला रहे हैं, जिसे समानांतर नहीं किया जा सकता है, तो वह धागा अधिकतम 100ms सीपीयू समय प्रति अवधि का उपयोग कर सकता है, जो कि 1 सीपीयू का 100% होगा। यदि आप इसका कोटा 1 सीपीयू पर सेट करते हैं, तो इसे कभी भी थ्रोट नहीं होना चाहिए।

यदि आप कोटा को 500 मीटर (0.5 सीपीयू) पर सेट करते हैं, तो प्रक्रिया प्रत्येक 100ms को चलाने के लिए 50 मी। किसी भी 100ms की अवधि 50ms से कम का उपयोग करती है, इसे थ्रॉटल नहीं किया जाना चाहिए। Ayn 100ms की अवधि यह 50ms चलाने के बाद समाप्त नहीं होती है, यह अगले 100ms की अवधि तक थ्रॉटल हो जाती है। यह विलंबता के बीच एक संतुलन बनाए रखता है (कितनी देर तक इसे चलाने में सक्षम होने के लिए इंतजार करना पड़ता है) और हॉगिंग (कितनी देर तक चलने से अन्य प्रक्रियाओं को रखने की अनुमति है)।

@ मेरी स्लाइड सही है। मैं एक उबंटू डेवलपर * भी हूं (केवल अपने खाली समय में)। आपका सबसे अच्छा शर्त सूत्रों को पढ़ना है, और जब आप के बारे में परवाह किए गए कर्नेल के संस्करण को हिट करते हैं, तो ट्रैक करने के लिए git दोष + टैग की जाँच करें।

@chiluk मैंने आपकी स्लाइड नहीं देखी थी। दूसरों के लिए जो उन्हें नहीं देखा है, यहाँ वे कहते हैं कि पैच कुछ समय पहले उतरा है:

• उबंटू 4.15.0-67 +
• Ubuntu 5.3.0-24 +
• RHEL7 कर्नेल 3.10.0-1062.8.1.el7
  और निश्चित रूप से लिनक्स स्थिर v4.14.154, v4.19.84, 5.3.9। मैंने ध्यान दिया कि यह लिनक्स स्थिर 5.4-आरसी 1 में भी है।

मैं अभी भी विभिन्न सीएफएस अनुसूचक कीड़े को समझने और विश्वसनीय, आसान-से-व्याख्या परीक्षणों को खोजने के लिए संघर्ष कर रहा हूं जो एक छोटे से एडब्ल्यूएस सर्वर पर काम करेंगे, क्योंकि मैं विरासत प्रतिष्ठानों से कई प्रकार की गुठली का समर्थन कर रहा हूं। जैसा कि मैं समयरेखा को समझता हूं, 2014 में लिनक्स कर्नेल v3.16-rc1 में एक बग पेश किया गया था

• [51f2176d74ac](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=51f2176d74ac) sched/fair: Fix unlocked reads of some cfs_b->quota/period ।

इससे विभिन्न सीएफएस थ्रॉटलिंग समस्याएँ उत्पन्न हुईं। मुझे लगता है कि जिन मुद्दों को मैं kops Kubernetes समूहों के तहत देख रहा था, वे इस बग के कारण थे, क्योंकि वे 4.9 गुठली का उपयोग कर रहे थे।

2018 कर्नेल v4.18-rc4 में 51f2176d74ac तय किया गया था

• [512ac999](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=512ac999d2755d2b7109e996a76b6fb8b888631d) sched/fair: Fix bandwidth timer clock drift condition

लेकिन यह बग @chiluk के साथ तय किया गया था

• [de53fd7ae](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=de53fd7aedb100f03e5d2231cfce0e4993282425) sched/fair: Fix low cpu usage with high throttling by removing expiration of cpu-local slices

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

उदाहरण के लिए, देबुआन बस्टर 10 (AWS AMI debian-10-amd64-20191113-76 ) पर, कर्नेल संस्करण को रिपोर्ट किया गया है

Linux ip-172-31-41-138 4.19.0-6-cloud-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux

जहाँ तक मैं बता सकता हूँ, इस कर्नेल के पास 51f2176d74ac होना चाहिए और 512ac999 होना चाहिए और इस प्रकार 512ac999 में वर्णित परीक्षण विफल होना चाहिए, लेकिन ऐसा नहीं होता है। (मैं कहता हूं कि मुझे नहीं लगता कि इसमें 512ac999 क्योंकि यह लिनक्स कर्नेल 4.10 से आकस्मिक रूप से अपग्रेड किया गया था और परिवर्तन लॉग में उस पैच का कोई उल्लेख नहीं है।) हालांकि, 4 cpu AWS VM पर यह विफल नहीं है। चिलुक के fibtest या बोब्रीक के सीएफएस हिचकी परीक्षण, जो बताता है कि कुछ और चल रहा है।

चिलुक के पैच प्राप्त करने से पहले ही कोरोस के साथ किसी भी समय-निर्धारण मुद्दों को पुन: प्रस्तुत करने में मुझे समान समस्याएं थीं।

इस समय मेरी सोच यह है कि बोब्रीक की परीक्षा मुख्य रूप से 51f2176d74ac लिए एक परीक्षा है, डेबियन बस्टर 10 AMI मैं _does_ का उपयोग कर रहा हूँ, 512ac999 , बस स्पष्ट रूप से परिवर्तन लॉग में नहीं बुलाया गया है, और fibtest केवल कुछ कोर के साथ एक मशीन पर बहुत संवेदनशील परीक्षण नहीं है।

एक 4 कोर सीपीयू शायद काफी बड़ा नहीं है जो समस्या को ठीक करने के लिए ठीक किया गया है।

यह केवल 40 cpus के ऊपर के साथ बड़ी मशीनों पर प्रतिलिपि प्रस्तुत करने योग्य होना चाहिए अगर मैं chiluks kubecon बात (https://www.youtube.com/watch?v=UE7QX98-kO0) से स्पष्टीकरण को सही ढंग से समझा।

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

90 डी निष्क्रियता के बाद मुद्दे बासी हो जाते हैं।
/remove-lifecycle stale साथ ताज़ा अंक को चिह्नित करें।
अतिरिक्त 30 डी निष्क्रियता के बाद बासी मुद्दे सड़ जाते हैं और अंततः बंद हो जाते हैं।

यदि यह समस्या अब बंद करने के लिए सुरक्षित है, तो कृपया /close साथ ऐसा करें।

सिग-टेस्टिंग, कुबेरनेट्स / टेस्ट-इन्फ्रा और / या फ़ेज्टा पर प्रतिक्रिया भेजें।
/ जीवनचक्र बासी

/ हटाने-जीवन चक्र बासी

इस धागे में पहले बताए गए परीक्षण वास्तव में मेरे लिए समस्या का पुनरुत्पादन नहीं करते हैं (कुछ जलने में 5ms से अधिक लगते हैं, लेकिन यह उनमें से 0.01% की तरह है) लेकिन हमारे सीएफटी थ्रॉटलिंग मेट्रिक्स अभी भी मध्यम मात्रा में थ्रॉटलिंग दिखाते हैं। हमारे समूहों में अलग-अलग कर्नेल संस्करण हैं लेकिन दो सबसे सामान्य संस्करण हैं:

• Debian 4.19.67-2+deb10u2~bpo9+1 (2019-11-12)
• 5.4.38 का मैन्युअल बैकपोर्ट

मुझे नहीं पता कि क्या दोनों बग्स को इन संस्करणों में तय किया जाना है, लेकिन मैं _think_ वे होना चाहिए, इसलिए मुझे आश्चर्य है कि यदि परीक्षण उपयोगी नहीं है। मैं 16 कोर के साथ मशीनों पर और 36 कोर के साथ परीक्षण कर रहा हूं, अगर मुझे परीक्षण के लिए वैध होने के लिए और भी अधिक कोर की आवश्यकता नहीं है, लेकिन हम अभी भी इन समूहों में थ्रॉटलिंग देखते हैं ...

क्या हमें इस मुद्दे को बंद करना चाहिए और नए लोगों को शुरू करने के लिए मुद्दों का सामना करना चाहिए? यहाँ स्पैमिंग की संभावना है कि किसी भी बातचीत को बहुत मुश्किल बना दिया जाएगा।

^ मैं सहमत हूं। इसके समाधान के लिए बहुत कुछ किया गया है।

/बंद करे

उपरोक्त टिप्पणियों के आधार पर। कृपया आवश्यकतानुसार ताजा अंक खोलें।

@ डिम्स : इस मुद्दे को बंद करना।

कृपया इस मुद्दे पर अनुवर्ती मुद्दों को सूचित करें, इसलिए इस मुद्दे को सदस्यता लेने वाले लोग अनुसरण करने के लिए नए मुद्दों की सदस्यता ले सकते हैं