केही वर्षअघि कुबेरनेट पहिले नै छलफल आधिकारिक GitHub ब्लगमा। त्यसबेलादेखि, यो सेवाहरू प्रयोग गर्नको लागि मानक प्रविधि भएको छ। Kubernetes ले अब आन्तरिक र सार्वजनिक सेवाहरूको महत्त्वपूर्ण भाग प्रबन्ध गर्दछ। हाम्रा क्लस्टरहरू बढ्दै जाँदा र कार्यसम्पादन आवश्यकताहरू थप कडा हुँदै गएपछि, हामीले कुबेरनेटका केही सेवाहरूले छिटपुट रूपमा विलम्बताको अनुभव गरिरहेका थिए जुन एप्लिकेसनको लोडले नै व्याख्या गर्न सकिँदैन।

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

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

असफलता निम्त्याउने श्रृंखलामा अनावश्यक जटिलता हटाउने

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

क्लाइन्ट (Vegeta) ले क्लस्टरमा कुनै पनि नोडसँग TCP जडान सिर्जना गर्दछ। Kubernetes ले ओभरले नेटवर्कको रूपमा काम गर्दछ (अवस्थित डाटा सेन्टर नेटवर्कको शीर्षमा) जुन प्रयोग गर्दछ IPIP, त्यो हो, यसले डाटा सेन्टरको आईपी प्याकेटहरू भित्र ओभरले नेटवर्कको आईपी प्याकेटहरू समावेश गर्दछ। पहिलो नोडमा जडान गर्दा, नेटवर्क ठेगाना अनुवाद गरिन्छ नेटवर्क ठेगाना अनुवाद (NAT) IP ठेगाना र Kubernetes नोडको पोर्टलाई IP ठेगाना र ओभरले नेटवर्कमा पोर्टमा अनुवाद गर्न स्टेटफुल (विशेष गरी, अनुप्रयोगको साथ पोड)। आगमन प्याकेटहरूको लागि, कार्यहरूको उल्टो अनुक्रम प्रदर्शन गरिन्छ। यो धेरै राज्य र धेरै तत्वहरूको साथ एक जटिल प्रणाली हो जुन सेवाहरू तैनात र सारियो रूपमा निरन्तर अद्यावधिक र परिवर्तन हुन्छन्।

उपयोगिता tcpdump Vegeta परीक्षणमा TCP ह्यान्डशेक (SYN र SYN-ACK बीच) को समयमा ढिलाइ हुन्छ। यो अनावश्यक जटिलता हटाउन, तपाईं प्रयोग गर्न सक्नुहुन्छ hping3 SYN प्याकेटहरूसँग सरल "पिङहरू" को लागि। हामी प्रतिक्रिया प्याकेटमा ढिलाइ भएको जाँच गर्छौं, र त्यसपछि जडान रिसेट गर्नुहोस्। हामी डाटा फिल्टर गर्न सक्छौं केवल 100ms भन्दा ठूला प्याकेटहरू समावेश गर्न र Vegeta को पूर्ण नेटवर्क तह 7 परीक्षण भन्दा समस्या पुन: उत्पादन गर्न सजिलो तरिका प्राप्त गर्न। यहाँ 30927ms अन्तरालहरूमा सेवा "नोड पोर्ट" (10) मा TCP SYN/SYN-ACK प्रयोग गरेर Kubernetes नोड "पिङहरू" छन्, सबैभन्दा ढिलो प्रतिक्रियाहरूद्वारा फिल्टर गरिएको:

theojulienne@shell ~ $ sudo hping3 172.16.47.27 -S -p 30927 -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}.'


len=46 ip=172.16.47.27 ttl=59 DF id=0 sport=30927 flags=SA seq=1485 win=29200 rtt=127.1 ms
len=46 ip=172.16.47.27 ttl=59 DF id=0 sport=30927 flags=SA seq=1486 win=29200 rtt=117.0 ms
len=46 ip=172.16.47.27 ttl=59 DF id=0 sport=30927 flags=SA seq=1487 win=29200 rtt=106.2 ms
len=46 ip=172.16.47.27 ttl=59 DF id=0 sport=30927 flags=SA seq=1488 win=29200 rtt=104.1 ms
len=46 ip=172.16.47.27 ttl=59 DF id=0 sport=30927 flags=SA seq=5024 win=29200 rtt=109.2 ms

len=46 ip=172.16.47.27 ttl=59 DF id=0 sport=30927 flags=SA seq=5231 win=29200 rtt=109.2 ms

तुरुन्तै पहिलो अवलोकन गर्न सक्नुहुन्छ। अनुक्रम संख्या र समयहरू द्वारा न्याय गर्दै, यो स्पष्ट छ कि यी एक पटकको भीडहरू होइनन्। ढिलाइ प्रायः जम्मा हुन्छ र अन्ततः प्रशोधन गरिन्छ।

अर्को, हामी भीडको घटनामा कुन कम्पोनेन्टहरू संलग्न हुन सक्छ भनेर पत्ता लगाउन चाहन्छौं। हुनसक्छ यी NAT मा सयौं iptables नियमहरू हुन्? वा नेटवर्कमा IPIP टनेलिङको साथ कुनै समस्या छ? यसलाई जाँच गर्ने एउटा तरिका भनेको प्रणालीको प्रत्येक चरणलाई मेटाएर परीक्षण गर्नु हो। यदि तपाईंले NAT र फायरवाल तर्क हटाउनुभयो भने, IPIP भाग मात्र छोडेर के हुन्छ:

सौभाग्यवश, यदि मेसिन एउटै नेटवर्कमा छ भने लिनक्सले आईपी ओभरले तहलाई सीधा पहुँच गर्न सजिलो बनाउँछ:

theojulienne@kube-node-client ~ $ sudo hping3 10.125.20.64 -S -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}.'


len=40 ip=10.125.20.64 ttl=64 DF id=0 sport=0 flags=RA seq=7346 win=0 rtt=127.3 ms
len=40 ip=10.125.20.64 ttl=64 DF id=0 sport=0 flags=RA seq=7347 win=0 rtt=117.3 ms

len=40 ip=10.125.20.64 ttl=64 DF id=0 sport=0 flags=RA seq=7348 win=0 rtt=107.2 ms

नतिजा हेर्दा, समस्या अझै बाँकी छ! यसले iptables र NAT समावेश गर्दैन। त्यसोभए समस्या TCP हो? एक नियमित ICMP पिंग कसरी जान्छ हेरौं:

theojulienne@kube-node-client ~ $ sudo hping3 10.125.20.64 --icmp -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}.'


len=28 ip=10.125.20.64 ttl=64 id=42594 icmp_seq=104 rtt=110.0 ms
len=28 ip=10.125.20.64 ttl=64 id=49448 icmp_seq=4022 rtt=141.3 ms
len=28 ip=10.125.20.64 ttl=64 id=49449 icmp_seq=4023 rtt=131.3 ms
len=28 ip=10.125.20.64 ttl=64 id=49450 icmp_seq=4024 rtt=121.2 ms
len=28 ip=10.125.20.64 ttl=64 id=49451 icmp_seq=4025 rtt=111.2 ms
len=28 ip=10.125.20.64 ttl=64 id=49452 icmp_seq=4026 rtt=101.1 ms
len=28 ip=10.125.20.64 ttl=64 id=50023 icmp_seq=4343 rtt=126.8 ms
len=28 ip=10.125.20.64 ttl=64 id=50024 icmp_seq=4344 rtt=116.8 ms
len=28 ip=10.125.20.64 ttl=64 id=50025 icmp_seq=4345 rtt=106.8 ms

len=28 ip=10.125.20.64 ttl=64 id=59727 icmp_seq=9836 rtt=106.1 ms

नतिजाले देखाउँछ कि समस्या हटेको छैन। सायद यो IPIP सुरुङ हो? परीक्षणलाई थप सरल बनाउनुहोस्:

के यी दुई होस्टहरू बीच सबै प्याकेटहरू पठाइन्छ?

theojulienne@kube-node-client ~ $ sudo hping3 172.16.47.27 --icmp -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}.'


len=46 ip=172.16.47.27 ttl=61 id=41127 icmp_seq=12564 rtt=140.9 ms
len=46 ip=172.16.47.27 ttl=61 id=41128 icmp_seq=12565 rtt=130.9 ms
len=46 ip=172.16.47.27 ttl=61 id=41129 icmp_seq=12566 rtt=120.8 ms
len=46 ip=172.16.47.27 ttl=61 id=41130 icmp_seq=12567 rtt=110.8 ms
len=46 ip=172.16.47.27 ttl=61 id=41131 icmp_seq=12568 rtt=100.7 ms
len=46 ip=172.16.47.27 ttl=61 id=9062 icmp_seq=31443 rtt=134.2 ms
len=46 ip=172.16.47.27 ttl=61 id=9063 icmp_seq=31444 rtt=124.2 ms
len=46 ip=172.16.47.27 ttl=61 id=9064 icmp_seq=31445 rtt=114.2 ms

len=46 ip=172.16.47.27 ttl=61 id=9065 icmp_seq=31446 rtt=104.2 ms

हामीले एकअर्कालाई कुनै पनि प्याकेट, ICMP पिङ पठाउने दुई Kubernetes नोडहरूमा स्थितिलाई सरलीकृत गरेका छौं। यदि लक्षित होस्ट "खराब" छ भने तिनीहरू अझै पनि विलम्बता देख्छन् (केही अरू भन्दा खराब)।

अब अन्तिम प्रश्न: किन ढिलाइ क्युबे-नोड सर्भरहरूमा मात्र हुन्छ? र के यो हुन्छ जब kube-node प्रेषक वा प्राप्तकर्ता हो? सौभाग्य देखि, Kubernetes बाहिर एक होस्टबाट प्याकेट पठाएर यो पत्ता लगाउन पनि धेरै सजिलो छ, तर उही "ज्ञात खराब" प्राप्तकर्तासँग। तपाईले देख्न सक्नुहुन्छ, समस्या हराएको छैन:

theojulienne@shell ~ $ sudo hping3 172.16.47.27 -p 9876 -S -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}.'


len=46 ip=172.16.47.27 ttl=61 DF id=0 sport=9876 flags=RA seq=312 win=0 rtt=108.5 ms
len=46 ip=172.16.47.27 ttl=61 DF id=0 sport=9876 flags=RA seq=5903 win=0 rtt=119.4 ms
len=46 ip=172.16.47.27 ttl=61 DF id=0 sport=9876 flags=RA seq=6227 win=0 rtt=139.9 ms

len=46 ip=172.16.47.27 ttl=61 DF id=0 sport=9876 flags=RA seq=7929 win=0 rtt=131.2 ms

हामी त्यसपछि अघिल्लो स्रोत क्युब-नोडबाट बाह्य होस्टमा उही अनुरोधहरू चलाउनेछौं (जसले स्रोत होस्टलाई समावेश गर्दैन किनभने पिङले RX र TX दुवै घटक समावेश गर्दछ):

theojulienne@kube-node-client ~ $ sudo hping3 172.16.33.44 -p 9876 -S -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}.' ^C --- 172.16.33.44 hping statistic --- 22352 packets transmitted, 22350 packets received, 1% packet loss round-trip min/avg/max = 0.2/7.6/1010.6 ms

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

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

कसरी मा एक सूक्ष्म भिन्नता छ नेटवर्क कार्डहरू आधुनिक सर्भरहरू (जस्तै हाम्रो डाटा सेन्टरमा भएका) TCP वा ICMP भएको प्याकेटहरू प्रक्रिया गर्दछ। जब प्याकेट आइपुग्छ, नेटवर्क एडाप्टरले "प्रति जडान यसलाई ह्यास गर्दछ", अर्थात्, यसले जडानहरूलाई लामहरूमा तोड्न र प्रत्येक लामलाई छुट्टै प्रोसेसर कोरमा पठाउने प्रयास गर्छ। TCP को लागि, यो ह्यासले स्रोत र गन्तव्य IP ठेगाना र पोर्ट दुवै समावेश गर्दछ। अन्य शब्दहरूमा, प्रत्येक जडान ह्यास गरिएको छ (सम्भावित रूपमा) फरक रूपमा। ICMP का लागि, IP ठेगानाहरू मात्र ह्यास गरिन्छ, किनकि त्यहाँ कुनै पोर्टहरू छैनन्।

अर्को नयाँ अवलोकन: यस अवधिमा हामी दुई होस्टहरू बीचको सबै सञ्चारहरूमा ICMP ढिलाइ देख्छौं, तर TCP ले गर्दैन। यसले हामीलाई RX लाम ह्यासिङसँग सम्भावित कारण सम्बन्धित छ भनी बताउँछ: भीड लगभग निश्चित रूपमा RX प्याकेटहरूको प्रशोधनमा छ, प्रतिक्रियाहरू पठाउनमा होइन।

यसले सम्भावित कारणहरूको सूचीबाट प्याकेटहरू पठाउन हटाउँछ। हामीलाई अब थाहा छ कि प्याकेट प्रशोधन समस्या केही क्युब-नोड सर्भरहरूमा प्राप्त पक्षमा छ।

लिनक्स कर्नेलमा प्याकेट प्रशोधन बुझ्दै

केहि क्युब-नोड सर्भरहरूमा रिसीभरमा किन समस्या हुन्छ भनेर बुझ्नको लागि, लिनक्स कर्नेलले प्याकेटहरू कसरी प्रशोधन गर्छ हेरौं।

सरल परम्परागत कार्यान्वयनमा फर्केर, नेटवर्क कार्डले प्याकेट प्राप्त गर्दछ र पठाउँछ बाधा लिनक्स कर्नेल त्यहाँ एउटा प्याकेज छ जुन प्रशोधन गर्न आवश्यक छ। कर्नेलले अन्य काम रोक्छ, अन्तर्निहित ह्यान्डलरमा सन्दर्भ स्विच गर्छ, प्याकेट प्रशोधन गर्छ, र हालको कार्यहरूमा फर्कन्छ।

यो कन्टेक्स्ट स्विचिङ ढिलो छ: 10 को दशकमा 90Mbps नेटवर्क कार्डहरूमा विलम्बता देख्न नसक्ने हुन सक्छ, तर आधुनिक 10G कार्डहरूमा अधिकतम थ्रुपुट 15 मिलियन प्याकेट प्रति सेकेन्डमा, सानो आठ-कोर सर्भरको प्रत्येक कोर लाखौं अवरोध हुन सक्छ। प्रति सेकेन्ड पटक।

लगातार अवरोधहरू ह्यान्डल नगर्नको लागि, धेरै वर्ष पहिले लिनक्स थपियो NAPI: नेटवर्क API जुन सबै आधुनिक ड्राइभरहरूले उच्च गतिमा प्रदर्शन सुधार गर्न प्रयोग गर्छन्। कम गतिमा कर्नेलले अझै पनि पुरानो तरिकामा नेटवर्क कार्डबाट अवरोधहरू प्राप्त गर्दछ। एकपटक पर्याप्त प्याकेटहरू थ्रेसहोल्ड भन्दा बढि आइपुग्दा, कर्नेलले अवरोधहरू असक्षम पार्छ र यसको सट्टा सञ्जाल एडाप्टरमा मतदान गर्न र प्याकेटहरू टुक्रामा उठाउन थाल्छ। प्रशोधन softirq मा प्रदर्शन गरिन्छ, अर्थात्, in सफ्टवेयर अवरोधहरूको सन्दर्भ प्रणाली कलहरू र हार्डवेयर अवरोधहरू पछि, जब कर्नेल (प्रयोगकर्ता ठाउँको विपरित) पहिले नै चलिरहेको हुन्छ।

यो धेरै छिटो छ, तर फरक समस्या निम्त्याउँछ। यदि त्यहाँ धेरै प्याकेटहरू छन् भने, त्यसपछि सबै समय नेटवर्क कार्डबाट प्याकेटहरू प्रशोधन गर्न खर्च गरिन्छ, र प्रयोगकर्ता स्पेस प्रक्रियाहरूसँग यी लामहरू खाली गर्न समय हुँदैन (TCP जडानहरू, आदिबाट पढ्दै)। अन्ततः लामहरू भरिन्छ र हामी प्याकेटहरू छोड्न थाल्छौं। सन्तुलन खोज्ने प्रयासमा, कर्नेलले softirq सन्दर्भमा प्रशोधन गरिएका प्याकेटहरूको अधिकतम संख्याको लागि बजेट सेट गर्दछ। यो बजेट नाघेपछि छुट्टै थ्रेड जाग्छ ksoftirqd (तपाईले ती मध्ये एक देख्नुहुनेछ ps प्रति कोर) जसले यी softirqs लाई सामान्य syscall/inrupt path बाहिर ह्यान्डल गर्दछ। यो थ्रेड मानक प्रक्रिया अनुसूचक प्रयोग गरेर अनुसूचित गरिएको छ, जसले स्रोतहरू उचित रूपमा बाँडफाँड गर्ने प्रयास गर्दछ।

कर्नेलले प्याकेटहरू कसरी प्रशोधन गर्छ भन्ने अध्ययन गरिसकेपछि, तपाईंले देख्न सक्नुहुन्छ कि त्यहाँ भीड हुने निश्चित सम्भावना छ। यदि softirq कलहरू कम बारम्बार प्राप्त हुन्छन् भने, प्याकेटहरूले नेटवर्क कार्डमा RX लाममा प्रशोधन गर्न केही समय पर्खनुपर्छ। यो प्रोसेसर कोर ब्लक गर्ने केहि कार्यको कारण हुन सक्छ, वा अन्य केहि कोर लाई softirq चल्नबाट रोकिरहेको छ।

प्रशोधनलाई कोर वा विधिमा संकुचित गर्दै

Softirq ढिलाइ अहिलेको लागि अनुमान मात्र हो। तर यसले अर्थ राख्छ, र हामीलाई थाहा छ कि हामी केहि धेरै समान देखिरहेका छौं। त्यसैले अर्को चरण यो सिद्धान्त पुष्टि गर्न हो। र यदि यो पुष्टि भयो भने, ढिलाइको कारण पत्ता लगाउनुहोस्।

हाम्रो ढिलो प्याकेटहरूमा फर्कौं:

len=46 ip=172.16.53.32 ttl=61 id=29573 icmp_seq=1953 rtt=99.3 ms


len=46 ip=172.16.53.32 ttl=61 id=29574 icmp_seq=1954 rtt=89.3 ms
len=46 ip=172.16.53.32 ttl=61 id=29575 icmp_seq=1955 rtt=79.2 ms
len=46 ip=172.16.53.32 ttl=61 id=29576 icmp_seq=1956 rtt=69.1 ms
len=46 ip=172.16.53.32 ttl=61 id=29577 icmp_seq=1957 rtt=59.1 ms
len=46 ip=172.16.53.32 ttl=61 id=29790 icmp_seq=2070 rtt=75.7 ms
len=46 ip=172.16.53.32 ttl=61 id=29791 icmp_seq=2071 rtt=65.6 ms

len=46 ip=172.16.53.32 ttl=61 id=29792 icmp_seq=2072 rtt=55.5 ms

पहिले छलफल गरिएझैं, यी ICMP प्याकेटहरू एकल RX NIC कतारमा ह्याश गरिएका छन् र एकल CPU कोरद्वारा प्रशोधन गरिन्छ। यदि हामी लिनक्सले कसरी काम गर्छ भनेर बुझ्न चाहन्छौं भने, प्रक्रिया ट्र्याक गर्नका लागि कहाँ (कुन CPU कोरमा) र कसरी (softirq, ksoftirqd) यी प्याकेजहरू प्रशोधन गरिन्छ भनेर जान्न उपयोगी हुन्छ।

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

यहाँ योजना सरल छ: हामीलाई थाहा छ कि कर्नेलले यी ICMP पिंगहरू प्रशोधन गर्दछ, त्यसैले हामी कर्नेल प्रकार्यमा हुक राख्नेछौं। icmp_echo, जसले आगमन ICMP इको अनुरोध प्याकेट स्वीकार गर्दछ र ICMP इको प्रतिक्रिया पठाउन सुरु गर्दछ। हामी icmp_seq नम्बर बढाएर प्याकेट पहिचान गर्न सक्छौं, जसले देखाउँछ hping3 उच्च।

कोड bcc लिपि जटिल देखिन्छ, तर यो जस्तो देखिन्छ जस्तो डरलाग्दो छैन। समारोह icmp_echo बुझाउँछ struct sk_buff *skb: यो "इको अनुरोध" भएको प्याकेट हो। हामी यसलाई ट्र्याक गर्न सक्छौं, क्रम बाहिर निकाल्न सक्छौं echo.sequence (जुनसँग तुलना गर्दछ icmp_seq hping3 द्वारा выше), र प्रयोगकर्ता स्पेसमा पठाउनुहोस्। हालको प्रक्रिया नाम/आईडी क्याप्चर गर्न यो पनि सुविधाजनक छ। कर्नेलले प्याकेटहरू प्रशोधन गर्दा हामीले प्रत्यक्ष देख्ने नतिजाहरू तल छन्:

TGID PID प्रक्रिया नाम ICMP_SEQ 0 0 swapper/11 770 0 0 swapper/11 771 0 0 swapper/11 772 0 0 swapper/11 773 0 0 swapper/11 774 20041 20086 swapper/775 0 0me 11s १ ७७६ ० ० स्वैपर/१ 776 0 0 11 स्वैपर/777 0 0 11 प्रवक्ता-रिपोर्ट-एस 778

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

यस उपकरणको साथ हामी विशिष्ट प्याकेजहरूसँग विशेष प्रक्रियाहरू सम्बद्ध गर्न सक्छौं जसले ढिलाइ देखाउँदछ hping3। यसलाई सरल बनाउनुहोस् grep निश्चित मानहरूको लागि यो क्याप्चरमा icmp_seq। माथिको icmp_seq मानहरूसँग मिल्ने प्याकेटहरू हामीले माथि अवलोकन गरेका RTT सँगसँगै नोट गरिएको थियो (कोष्ठकहरूमा हामीले RTT मानहरू 50 ms भन्दा कमको कारणले फिल्टर गरेका प्याकेटहरूका लागि अपेक्षित RTT मानहरू हुन्):

TGID PID प्रक्रिया नाम ICMP_SEQ ** RTT -- 10137 10436 cadvisor 1951 10137 10436 cadvisor 1952 76 76 ksoftirqd/11 1953 ** 99ms 76 76 d11 softq ** 1954ms 89 d76 soft ir qd/76 11 ** 1955ms 79 76 ksoftirqd/ 76 11 ** 1956ms 69 76 ksoftirqd/76 11 ** 1957ms 59 76 ksoftirqd/76 11 ** (1958ms) 49 76 ksoftirqd/76 11 ** (1959ms) 39 ksoftirqd/76 76 ** (11ms) 1960 ksoftirqd/29ms** (76ms) 76 ksoftirqd/11ms** 1961 ksoft irqd/ 19 76 ** (76ms) 11 1962 ksoftirqd/9 10137 ** (10436ms) -- 2068 10137 cadvisor 10436 2069 76 cadvisor 76 11 2070 ksoftirqd/75 76 softir** qd/76 11 ** 2071ms 65 76 ksoftirqd/ 76 11 ** 2072ms 55 76 ksoftirqd/76 11 ** (2073ms) 45 76 ksoftirqd/76 11 ** (2074ms) 35 76 ksoftirqd/76 11 ** (2075ms ** (25ms) ms ) ७६ ७६ ksoftirqd/76 76 ** (11ms)

परिणामहरूले हामीलाई धेरै कुराहरू बताउँछन्। पहिलो, यी सबै प्याकेजहरू सन्दर्भद्वारा प्रशोधन गरिन्छ ksoftirqd/11। यसको मतलब यो हो कि मेसिनहरूको यो विशेष जोडीको लागि, ICMP प्याकेटहरू प्राप्त गर्ने अन्तमा कोर 11 मा ह्यास गरिएको थियो। हामी यो पनि देख्छौं कि जब त्यहाँ जाम हुन्छ, त्यहाँ प्याकेटहरू छन् जुन प्रणाली कलको सन्दर्भमा प्रशोधन गरिन्छ। cadvisor... त्यसो भए ksoftirqd कार्य लिन्छ र संचित कतारलाई प्रशोधन गर्दछ: ठ्याक्कै पछि जम्मा भएको प्याकेटहरूको संख्या cadvisor.

यो तुरुन्तै अघि सधैं काम गर्दछ भन्ने तथ्य cadvisor, समस्यामा उनको संलग्नता संकेत गर्दछ। विडम्बना, उद्देश्य cadvisor - यो कार्यसम्पादन समस्या निम्त्याउनुको सट्टा "चलिरहेको कन्टेनरहरूको स्रोत उपयोग र प्रदर्शन विशेषताहरू विश्लेषण गर्नुहोस्"।

कन्टेनरका अन्य पक्षहरू जस्तै, यी सबै उच्च उन्नत उपकरणहरू हुन् र केही अप्रत्याशित परिस्थितिहरूमा कार्यसम्पादन समस्याहरू अनुभव गर्ने आशा गर्न सकिन्छ।

क्याडभाइजरले के गर्छ जसले प्याकेट लामलाई सुस्त बनाउँछ?

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

यो एक सिद्धान्त हो, तर यसलाई कसरी परीक्षण गर्ने? हामीले के गर्न सक्छौं यो प्रक्रियामा CPU कोर ट्रेस गर्न, प्याकेटहरूको संख्या बजेट भन्दा बढी जान्छ र ksoftirqd भनिन्छ भन्ने बिन्दु फेला पार्नुहोस्, र त्यसपछि त्यो बिन्दु भन्दा ठीक अगाडि CPU कोरमा के चलिरहेको थियो भनेर हेर्नको लागि अलि अगाडि हेर्नुहोस्। । यो हरेक केही मिलिसेकेन्डमा CPU लाई एक्स-रे गर्नु जस्तै हो। यो केहि यस्तो देखिनेछ:

सुविधाजनक रूपमा, यो सबै अवस्थित उपकरणहरूसँग गर्न सकिन्छ। उदाहरणका लागि, perf रेकर्ड निर्दिष्ट फ्रिक्वेन्सीमा दिइएको CPU कोर जाँच गर्दछ र प्रयोगकर्ता स्पेस र लिनक्स कर्नेल दुवै सहित चलिरहेको प्रणालीमा कलहरूको तालिका उत्पन्न गर्न सक्छ। तपाइँ यो रेकर्ड लिन सक्नुहुन्छ र कार्यक्रमको सानो फोर्क प्रयोग गरेर यसलाई प्रशोधन गर्न सक्नुहुन्छ फ्लेमग्राफ ब्रेन्डन ग्रेगबाट, जसले स्ट्याक ट्रेसको क्रम सुरक्षित गर्दछ। हामी प्रत्येक 1 ms मा एकल-लाइन स्ट्याक ट्रेसहरू बचत गर्न सक्छौं, र त्यसपछि ट्रेस हिट हुनु अघि नमूना 100 मिलिसेकेन्ड हाइलाइट र बचत गर्न सक्छौं। ksoftirqd:

# record 999 times a second, or every 1ms with some offset so not to align exactly with timers sudo perf record -C 11 -g -F 999 # take that recording and make a simpler stack trace. sudo perf script 2>/dev/null | ./FlameGraph/stackcollapse-perf-ordered.pl | grep ksoftir -B 100

यहाँ परिणामहरू छन्:

(сотни следов, которые выглядят похожими)

cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_nr_lru_pages;mem_cgroup_node_nr_lru_pages cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_nr_lru_pages;mem_cgroup_node_nr_lru_pages cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_iter cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_nr_lru_pages;mem_cgroup_node_nr_lru_pages cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_nr_lru_pages;mem_cgroup_node_nr_lru_pages ksoftirqd/11;ret_from_fork;kthread;kthread;smpboot_thread_fn;smpboot_thread_fn;run_ksoftirqd;__do_softirq;net_rx_action;ixgbe_poll;ixgbe_clean_rx_irq;napi_gro_receive;netif_receive_skb_internal;inet_gro_receive;bond_handle_frame;__netif_receive_skb_core;ip_rcv_finish;ip_rcv;ip_forward_finish;ip_forward;ip_finish_output;nf_iterate;ip_output;ip_finish_output2;__dev_queue_xmit;dev_hard_start_xmit;ipip_tunnel_xmit;ip_tunnel_xmit;iptunnel_xmit;ip_local_out;dst_output;__ip_local_out;nf_hook_slow;nf_iterate;nf_conntrack_in;generic_packet;ipt_do_table;set_match_v4;ip_set_test;hash_net4_kadt;ixgbe_xmit_frame_ring;swiotlb_dma_mapping_error;hash_net4_test ksoftirqd/11;ret_from_fork;kthread;kthread;smpboot_thread_fn;smpboot_thread_fn;run_ksoftirqd;__do_softirq;net_rx_action;gro_cell_poll;napi_gro_receive;netif_receive_skb_internal;inet_gro_receive;__netif_receive_skb_core;ip_rcv_finish;ip_rcv;ip_forward_finish;ip_forward;ip_finish_output;nf_iterate;ip_output;ip_finish_output2;__dev_queue_xmit;dev_hard_start_xmit;dev_queue_xmit_nit;packet_rcv;tpacket_rcv;sch_direct_xmit;validate_xmit_skb_list;validate_xmit_skb;netif_skb_features;ixgbe_xmit_frame_ring;swiotlb_dma_mapping_error;__dev_queue_xmit;dev_hard_start_xmit;__bpf_prog_run;__bpf_prog_run

यहाँ धेरै चीजहरू छन्, तर मुख्य कुरा यो हो कि हामीले "ksoftirqd अघि cadvisor" ढाँचा फेला पार्छौं जुन हामीले ICMP ट्रेसरमा पहिले देख्यौं। यसको मतलब के हो?

प्रत्येक रेखा एक निश्चित बिन्दुमा एक CPU ट्रेस हो। रेखामा स्ट्याक डाउन प्रत्येक कल एक अर्धविराम द्वारा अलग गरिएको छ। रेखाहरूको बीचमा हामी देख्छौं कि syscall भनिन्छ: read(): .... ;do_syscall_64;sys_read; ...। त्यसैले क्याडभाइजरले प्रणाली कलमा धेरै समय खर्च गर्दछ read()कार्यहरु संग सम्बन्धित mem_cgroup_* (कल स्ट्याकको शीर्ष/लाइनको अन्त्य)।

कल ट्रेसमा वास्तवमा के पढिरहेको छ भनेर हेर्न असुविधाजनक छ, त्यसैले दौडौं strace र केडभाइजरले के गर्छ हेरौं र 100 ms भन्दा लामो प्रणाली कलहरू फेला पार्नुहोस्:

theojulienne@kube-node-bad ~ $ sudo strace -p 10137 -T -ff 2>&1 | egrep '<0.[1-9]' [pid 10436] <... futex resumed> ) = 0 <0.156784> [pid 10432] <... futex resumed> ) = 0 <0.258285> [pid 10137] <... futex resumed> ) = 0 <0.678382> [pid 10384] <... futex resumed> ) = 0 <0.762328> [pid 10436] <... read resumed> "cache 154234880nrss 507904nrss_h"..., 4096) = 658 <0.179438> [pid 10384] <... futex resumed> ) = 0 <0.104614> [pid 10436] <... futex resumed> ) = 0 <0.175936> [pid 10436] <... read resumed> "cache 0nrss 0nrss_huge 0nmapped_"..., 4096) = 577 <0.228091> [pid 10427] <... read resumed> "cache 0nrss 0nrss_huge 0nmapped_"..., 4096) = 577 <0.207334> [pid 10411] <... epoll_ctl resumed> ) = 0 <0.118113> [pid 10382] <... pselect6 resumed> ) = 0 (Timeout) <0.117717> [pid 10436] <... read resumed> "cache 154234880nrss 507904nrss_h"..., 4096) = 660 <0.159891> [pid 10417] <... futex resumed> ) = 0 <0.917495> [pid 10436] <... futex resumed> ) = 0 <0.208172> [pid 10417] <... futex resumed> ) = 0 <0.190763> [pid 10417] <... read resumed> "cache 0nrss 0nrss_huge 0nmapped_"..., 4096) = 576 <0.154442>

तपाईले अपेक्षा गरे जस्तै, हामी यहाँ ढिलो कलहरू देख्छौं read()। पढ्ने कार्यहरू र सन्दर्भको सामग्रीबाट mem_cgroup यो स्पष्ट छ कि यी चुनौतीहरू read() फाइल सन्दर्भ गर्नुहोस् memory.stat, जसले मेमोरी प्रयोग र cgroup सीमाहरू (डकरको स्रोत अलगाव प्रविधि) देखाउँछ। क्याडभाइजर उपकरणले कन्टेनरहरूको लागि स्रोत प्रयोग जानकारी प्राप्त गर्न यो फाइललाई सोध्छ। यो कर्नेल वा क्याडभाइजरले अप्रत्याशित काम गरिरहेको छ कि छैन जाँच गरौं:

theojulienne@kube-node-bad ~ $ time cat /sys/fs/cgroup/memory/memory.stat >/dev/null

real 0m0.153s user 0m0.000s sys 0m0.152s theojulienne@kube-node-bad ~ $

अब हामी बग पुन: उत्पादन गर्न सक्छौं र लिनक्स कर्नेलले रोगविज्ञानको सामना गरिरहेको छ भनेर बुझ्न सक्छौं।

किन पढ्ने कार्य यति ढिलो छ?

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

समस्या यो हो कि cgroups ले नेमस्पेस (कन्टेनर) भित्र मेमोरी उपयोग खातामा लिन्छ। जब यो cgroup मा सबै प्रक्रियाहरु बाहिर निस्कन्छ, Docker ले मेमोरी cgroup जारी गर्दछ। यद्यपि, "मेमोरी" केवल प्रक्रिया मेमोरी होइन। यद्यपि प्रक्रिया मेमोरी आफैंमा अब प्रयोग गरिएको छैन, यस्तो देखिन्छ कि कर्नेलले अझै पनि क्यास गरिएका सामग्रीहरू, जस्तै डेन्ट्रीहरू र इनोडहरू (डाइरेक्टरी र फाइल मेटाडेटा), जुन मेमोरी cgroup मा क्यास गरिन्छ। समस्या विवरणबाट:

zombie cgroups: cgroups जसमा कुनै प्रक्रियाहरू छैनन् र मेटाइएको छ, तर अझै मेमोरी आवंटित गरिएको छ (मेरो केसमा, डेन्ट्री क्यासबाट, तर यो पृष्ठ क्यास वा tmpfs बाट पनि आवंटित गर्न सकिन्छ)।

cgroup खाली गर्दा क्यासमा सबै पृष्ठहरूको कर्नेल जाँच धेरै ढिलो हुन सक्छ, त्यसैले अल्छी प्रक्रिया छनोट गरिएको छ: यी पृष्ठहरू पुन: अनुरोध नगरेसम्म पर्खनुहोस्, र त्यसपछि अन्तमा cgroup खाली गर्नुहोस् जब मेमोरी वास्तवमा आवश्यक हुन्छ। यस बिन्दु सम्म, तथ्याङ्क सङ्कलन गर्दा cgroup अझै पनि खातामा लिइन्छ।

प्रदर्शन दृष्टिकोणबाट, तिनीहरूले प्रदर्शनको लागि मेमोरी बलिदान दिए: केही क्यास मेमोरी पछाडि छोडेर प्रारम्भिक सफाईको गति बढाउँदै। यो ठीक छ। जब कर्नेलले क्यास मेमोरीको अन्तिम प्रयोग गर्छ, cgroup अन्ततः खाली हुन्छ, त्यसैले यसलाई "लीक" भन्न सकिँदैन। दुर्भाग्यवश, खोज संयन्त्रको विशिष्ट कार्यान्वयन memory.stat यो कर्नेल संस्करणमा (4.9), हाम्रो सर्भरहरूमा मेमोरीको ठूलो मात्रासँग जोडिएको छ, यसको मतलब पछिल्लो क्यास डाटा पुनर्स्थापना गर्न र cgroup zombies खाली गर्न धेरै समय लाग्छ।

यो बाहिर जान्छ कि हाम्रा केही नोडहरूमा यति धेरै cgroup zombies थिए कि पढ्ने र विलम्बता एक सेकेन्ड नाघ्यो।

क्याडभाइजर समस्याको समाधान भनेको प्रणालीभरि तुरुन्तै डेन्ट्री/इनोड क्यासहरू मुक्त गर्नु हो, जसले तुरुन्तै होस्टमा पढ्ने लेटन्सी र नेटवर्क लेटन्सी हटाउँछ, किनकि क्यास खाली गर्दा क्यास गरिएको zombie cgroup पृष्ठहरू सक्रिय हुन्छ र तिनीहरूलाई पनि मुक्त गर्दछ। यो एक समाधान होइन, तर यसले समस्याको कारण पुष्टि गर्दछ।

नयाँ कर्नेल संस्करणहरूमा (4.19+) कल कार्यसम्पादन सुधारिएको थियो memory.stat, त्यसैले यो कर्नेलमा स्विच गर्दा समस्या समाधान भयो। एकै समयमा, हामीसँग Kubernetes क्लस्टरहरूमा समस्याग्रस्त नोडहरू पत्ता लगाउन, तिनीहरूलाई राम्रोसँग निकाल्ने र तिनीहरूलाई रिबुट गर्ने उपकरणहरू थिए। हामीले सबै क्लस्टरहरू कम्बेड गर्यौं, पर्याप्त उच्च विलम्बता भएका नोडहरू फेला पार्यौं र तिनीहरूलाई रिबुट गर्‍यौं। यसले हामीलाई बाँकी सर्भरहरूमा OS अद्यावधिक गर्न समय दियो।

संक्षेप गर्न

किनभने यो बगले सयौं मिलिसेकेन्डहरूको लागि RX NIC कतार प्रशोधन रोकेको छ, यसले एकैसाथ छोटो जडानहरूमा उच्च विलम्बता र MySQL अनुरोधहरू र प्रतिक्रिया प्याकेटहरू बीचको मध्य-जडान विलम्बताको कारण बनायो।

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

स्रोत: www.habr.com

Kubernetes मा नेटवर्क विलम्बता डिबग गर्दै