በ Kubernetes ውስጥ የአውታረ መረብ መዘግየትን ማረም

በ Kubernetes ውስጥ የአውታረ መረብ መዘግየትን ማረም

ከጥቂት ዓመታት በፊት ኩበርኔትስ አስቀድሞ ተወያይቷል። በይፋ GitHub ብሎግ ላይ። ከዚያን ጊዜ ጀምሮ, አገልግሎቶችን ለማሰማራት መደበኛ ቴክኖሎጂ ሆኗል. ኩበርኔትስ አሁን ጉልህ የሆነ የውስጥ እና የህዝብ አገልግሎቶችን ያስተዳድራል። ክላስተሮቻችን እያደጉ ሲሄዱ እና የአፈጻጸም መስፈርቶች ይበልጥ እየጠነከሩ ሲሄዱ፣ በ Kubernetes ላይ አንዳንድ አገልግሎቶች አልፎ አልፎ በመተግበሪያው ጭነት ሊገለጽ የማይችል መዘግየት እያጋጠማቸው መሆኑን ማስተዋል ጀመርን።

በመሰረቱ፣ አፕሊኬሽኖች የዘፈቀደ የአውታረ መረብ መዘግየት እስከ 100ሚሴ ወይም ከዚያ በላይ ያጋጥማቸዋል፣ይህም ጊዜ ያበቃል ወይም እንደገና ይሞክራል። አገልግሎቶቹ ለጥያቄዎች ከ100ሚሴ በላይ ፈጣን ምላሽ ሊሰጡ እንደሚችሉ ይጠበቃል። ግንኙነቱ ራሱ ብዙ ጊዜ የሚወስድ ከሆነ ግን ይህ የማይቻል ነው። ለየብቻ፣ ሚሊሰከንዶች የሚወስዱ የ MySQL መጠይቆችን ተመልክተናል፣ እና MySQL በ ሚሊሰከንዶች አጠናቋል፣ ነገር ግን ከጠያቂው መተግበሪያ እይታ አንጻር፣ ምላሹ 100 ሚሴ ወይም ከዚያ በላይ ወስዷል።

ምንም እንኳን ጥሪው ከ Kubernetes ውጭ ቢሆንም ችግሩ የተከሰተው ከ Kubernetes node ጋር ሲገናኝ ብቻ እንደሆነ ወዲያውኑ ግልጽ ሆነ። ችግሩን ለማባዛት ቀላሉ መንገድ በፈተና ውስጥ ነው Etaጋታ።, ከማንኛውም የውስጥ አስተናጋጅ የሚሰራ, የኩበርኔትስ አገልግሎትን በአንድ የተወሰነ ወደብ ላይ ይፈትሻል, እና አልፎ አልፎ ከፍተኛ መዘግየትን ይመዘግባል. በዚህ ጽሑፍ ውስጥ የዚህን ችግር መንስኤ እንዴት መፈለግ እንደቻልን እንመለከታለን.

ወደ ውድቀት የሚያመራውን ሰንሰለት ውስጥ አላስፈላጊ ውስብስብነትን ማስወገድ

ተመሳሳዩን ምሳሌ በማባዛት የችግሩን ትኩረት ለማጥበብ እና አላስፈላጊ ውስብስብ ነገሮችን ለማስወገድ እንፈልጋለን። መጀመሪያ ላይ በቬጄታ እና በኩበርኔትስ ፖድ መካከል ባለው ፍሰት ውስጥ በጣም ብዙ ንጥረ ነገሮች ነበሩ። የጠለቀ የአውታረ መረብ ችግርን ለመለየት, አንዳንዶቹን ማስወገድ ያስፈልግዎታል.

በ Kubernetes ውስጥ የአውታረ መረብ መዘግየትን ማረም

ደንበኛው (Vegeta) በክላስተር ውስጥ ካለ ማንኛውም መስቀለኛ መንገድ ጋር የTCP ግንኙነት ይፈጥራል። Kubernetes የሚጠቀመው እንደ ተደራቢ አውታረመረብ ነው (በነባሩ የውሂብ ማዕከል አውታረ መረብ ላይ) አይፒፒ፣ ማለትም ፣ በመረጃ ማእከሉ የአይፒ ፓኬቶች ውስጥ የተደራቢ አውታረ መረብን የአይፒ ፓኬቶችን ያጠቃልላል። ከመጀመሪያው መስቀለኛ መንገድ ጋር ሲገናኙ የአውታረ መረብ አድራሻ መተርጎም ይከናወናል የአውታረ መረብ አድራሻ ትርጉም (NAT) የኩበርኔትስ መስቀለኛ መንገድን የአይፒ አድራሻ እና ወደብ ወደ አይፒ አድራሻ እና በተደራቢ አውታረመረብ ውስጥ (በተለይ ከመተግበሪያው ጋር ያለው ፖድ) ለመተርጎም የተረጋገጠ ነው። ለገቢ ፓኬቶች, የተገላቢጦሽ የእርምጃዎች ቅደም ተከተል ይከናወናል. አገልግሎቶቹ ሲዘረጉ እና ሲንቀሳቀሱ በየጊዜው የሚሻሻሉ እና የሚቀየሩ ብዙ ግዛት እና ብዙ አካላት ያሉት ውስብስብ ስርዓት ነው።

መገልገያ tcpdump በ Vegeta ሙከራ በTCP እጅ መጨባበጥ (በSYN እና SYN-ACK መካከል) መዘግየት አለ። ይህንን አላስፈላጊ ውስብስብነት ለማስወገድ, መጠቀም ይችላሉ hping3 ለቀላል “ፒንግ” ከSYN ፓኬቶች ጋር። በምላሽ ፓኬት ውስጥ መዘግየት ካለ እናረጋግጣለን እና ግንኙነቱን እንደገና ያስጀምራል። ከ100ሚሴ በላይ ፓኬጆችን ለማካተት ውሂቡን ማጣራት እና ችግሩን ለማባዛት ቀላል መንገድ ከ Vegeta's ሙሉ የአውታረ መረብ ንብርብር 7 ሙከራ የበለጠ ማግኘት እንችላለን። በ 30927ms ክፍተቶች በ 10ms ክፍተቶች ላይ TCP SYN/SYN-ACKን በመጠቀም Kubernetes node "pings" እዚህ አሉ።

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 ህጎች ውስጥ አንዳንዶቹ ናቸው? ወይም በአውታረ መረቡ ላይ በአይፒአይፒ መሿለኪያ ላይ ችግሮች አሉ? ይህንን ለማረጋገጥ አንዱ መንገድ የስርዓቱን እያንዳንዱን ደረጃ በማጥፋት መሞከር ነው። የአይፒአይፒ ክፍሉን ብቻ በመተው NAT እና ፋየርዎል ሎጂክን ካስወገዱ ምን ይከሰታል።

በ Kubernetes ውስጥ የአውታረ መረብ መዘግየትን ማረም

እንደ እድል ሆኖ፣ ማሽኑ በተመሳሳዩ አውታረ መረብ ላይ ከሆነ ሊኑክስ የአይፒ ተደራቢውን ንብርብር በቀጥታ ማግኘት ቀላል ያደርገዋል።

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

ውጤቶቹ እንደሚያሳዩት ችግሩ አልቀረም. ምናልባት ይህ የአይፒአይፒ ዋሻ ነው? ፈተናውን የበለጠ እናቅልለው፡-

በ Kubernetes ውስጥ የአውታረ መረብ መዘግየትን ማረም

ሁሉም ፓኬቶች በእነዚህ ሁለት አስተናጋጆች መካከል ይላካሉ?

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 ፒንግ እንዲልክ አድርገነዋል። የታለመው አስተናጋጅ "መጥፎ" ከሆነ (አንዳንዶቹ ከሌሎቹ የከፋ) ከሆነ አሁንም መዘግየትን ያያሉ።

አሁን የመጨረሻው ጥያቄ፡ ለምንድነው መዘግየቱ በ 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

የቆይታ ፓኬት ቀረጻዎችን በመመርመር አንዳንድ ተጨማሪ መረጃዎችን አግኝተናል። በተለይም፣ ላኪው (ከታች) ይህን የጊዜ ማብቂያ ያያል፣ ተቀባዩ (ከላይ) ግን አያይም - የዴልታ አምድ (በሴኮንዶች) ይመልከቱ፡

በ Kubernetes ውስጥ የአውታረ መረብ መዘግየትን ማረም

በተጨማሪም, በተቀባዩ በኩል የ TCP እና ICMP እሽጎች (በቅደም ተከተል ቁጥሮች) ላይ ያለውን ልዩነት ከተመለከቱ, የ ICMP ፓኬቶች ሁልጊዜ በተላኩበት ተመሳሳይ ቅደም ተከተል ይደርሳሉ, ነገር ግን በተለያየ ጊዜ. በተመሳሳይ ጊዜ, የ TCP ፓኬቶች አንዳንድ ጊዜ እርስ በርስ ይጣመራሉ, እና አንዳንዶቹ ይጣበቃሉ. በተለይም የ SYN ፓኬቶችን ወደቦች ከመረመሩ, እነሱ በቅደም ተከተል በላኪው በኩል ናቸው, ነገር ግን በተቀባዩ በኩል አይደለም.

እንዴት በሚለው ላይ ትንሽ ልዩነት አለ። የአውታረ መረብ ካርዶች ዘመናዊ ሰርቨሮች (እንደ እኛ የመረጃ ማዕከል ያሉ) TCP ወይም ICMP የያዙ ፓኬጆችን ያዘጋጃሉ። አንድ ፓኬት ሲመጣ የአውታረ መረብ አስማሚው "በግንኙነት Hashes it" ማለትም ግንኙነቶቹን ወደ ወረፋ ለመከፋፈል ይሞክራል እና እያንዳንዱን ወረፋ ወደ የተለየ ፕሮሰሰር ኮር ይልካል። ለTCP፣ ይህ ሃሽ ሁለቱንም ምንጭ እና መድረሻ IP አድራሻ እና ወደብ ያካትታል። በሌላ አገላለጽ፣ እያንዳንዱ ግንኙነት በተለየ መንገድ የተጠለፈ ነው (በሚቻል)። ለ ICMP፣ ምንም ወደቦች ስለሌለ የአይ ፒ አድራሻዎች ብቻ ነው የተጠለፉት።

ሌላ አዲስ ምልከታ፡ በዚህ ጊዜ ውስጥ የ ICMP መዘግየቶችን በሁለት አስተናጋጆች መካከል ያለውን ግንኙነት እናያለን ነገርግን TCP አያደርገውም። ይህ መንስኤው ከ RX ወረፋ ሃሺንግ ጋር የተያያዘ ሊሆን እንደሚችል ይነግረናል፡ መጨናነቁ ከሞላ ጎደል በ RX ፓኬቶች ሂደት ላይ እንጂ ምላሾችን በመላክ ላይ አይደለም።

ይህ ሊሆኑ ከሚችሉ ምክንያቶች ዝርዝር ውስጥ ፓኬቶችን መላክን ያስወግዳል። አሁን የፓኬት ማቀናበር ችግር በአንዳንድ የኩቤ-ኖድ አገልጋዮች ላይ በተቀባዩ በኩል እንዳለ እናውቃለን።

በሊኑክስ ከርነል ውስጥ የፓኬት ሂደትን መረዳት

ችግሩ ለምን በአንዳንድ የ kube-node አገልጋዮች ላይ በተቀባዩ ላይ እንደሚከሰት ለመረዳት የሊኑክስ ከርነል እሽጎችን እንዴት እንደሚያስኬድ እንመልከት።

ወደ ቀላሉ ባህላዊ አተገባበር ስንመለስ የኔትወርክ ካርዱ ፓኬጁን ተቀብሎ ይልካል ማቋረጥ የሊኑክስ ከርነል ማቀናበር ያለበት ጥቅል እንዳለ። ከርነሉ ሌላ ስራ ያቆማል፣ አውዱን ወደ ማቋረጥ ተቆጣጣሪው ይቀይራል፣ ፓኬጁን ያስኬዳል እና ወደ አሁኑ ተግባራት ይመለሳል።

በ Kubernetes ውስጥ የአውታረ መረብ መዘግየትን ማረም

ይህ አውድ መቀያየር ቀርፋፋ ነው፡ በ10ዎቹ ውስጥ በ90Mbps አውታረ መረብ ካርዶች ላይ መዘግየት ላይታይ ይችላል፣ነገር ግን በዘመናዊ 10ጂ ካርዶች ከፍተኛ መጠን 15ሚሊየን ፓኬቶች በሰከንድ፣የትንሽ ስምንት ኮር አገልጋይ እያንዳንዱ ኮር በሚሊዮን የሚቆጠሩ ሊቋረጥ ይችላል። በሰከንድ ጊዜዎች.

ማቋረጥን ያለማቋረጥ ላለማስተናገድ ከብዙ አመታት በፊት ሊኑክስ ታክሏል። NAPIበከፍተኛ ፍጥነት አፈጻጸምን ለማሻሻል ሁሉም ዘመናዊ አሽከርካሪዎች የሚጠቀሙበት የአውታረ መረብ ኤፒአይ። በዝቅተኛ ፍጥነት ከርነል አሁንም በአሮጌው መንገድ ከአውታረ መረብ ካርድ መቆራረጦችን ይቀበላል። አንዴ ከገደቡ በላይ የሆኑ በቂ እሽጎች ከደረሱ በኋላ ከርነሉ መቆራረጥን ያሰናክላል እና በምትኩ የኔትወርክ አስማሚውን ድምጽ መስጠት እና እሽጎችን ከፋፍሎ መውሰድ ይጀምራል። ማቀነባበር የሚከናወነው በ softirq፣ ማለትም፣ ውስጥ ነው። የሶፍትዌር ማቋረጦች አውድ ከስርዓት ጥሪዎች እና ሃርድዌር ከተቋረጠ በኋላ ከርነል (ከተጠቃሚው ቦታ በተቃራኒ) ቀድሞውኑ እየሰራ ነው።

በ Kubernetes ውስጥ የአውታረ መረብ መዘግየትን ማረም

ይህ በጣም ፈጣን ነው, ግን የተለየ ችግር ይፈጥራል. በጣም ብዙ እሽጎች ካሉ ፣ ከዚያ ሁሉም ጊዜ ከአውታረ መረብ ካርዱ ላይ እሽጎችን ለማስኬድ ነው ፣ እና የተጠቃሚ ቦታ ሂደቶች በእውነቱ እነዚህን ወረፋዎች ባዶ ለማድረግ ጊዜ አይኖራቸውም (ከ TCP ግንኙነቶች ማንበብ ፣ ወዘተ)። በመጨረሻም ወረፋዎቹ ተሞልተው ፓኬቶችን መጣል እንጀምራለን. ሚዛኑን ለማግኘት በሚደረገው ሙከራ ከርነል በሶፍትሪክ አውድ ውስጥ ለተዘጋጁት ከፍተኛው የፓኬቶች ብዛት በጀት ያዘጋጃል። ይህ በጀት ካለፈ በኋላ የተለየ ክር ይነሳል ksoftirqd (ከመካከላቸው አንዱን ያያሉ ps እነዚህን softirqs ከመደበኛው syscall/መቆራረጥ መንገድ ውጭ የሚያስተናግደው በኮር)። ይህ ክር መርሐግብር የተያዘለት መደበኛውን የሂደት መርሐግብር በመጠቀም ነው፣ ይህም ሀብቶችን በአግባቡ ለመመደብ ይሞክራል።

በ Kubernetes ውስጥ የአውታረ መረብ መዘግየትን ማረም

ከርነል እሽጎችን እንዴት እንደሚያከናውን ካጠናህ በኋላ የተወሰነ የመጨናነቅ እድል እንዳለ ማየት ትችላለህ። የSoftirq ጥሪዎች ባነሰ ጊዜ የሚደርሱ ከሆነ፣ እሽጎች በኔትወርክ ካርድ ላይ ባለው RX ወረፋ ውስጥ ለመስራት ለተወሰነ ጊዜ መጠበቅ አለባቸው። ይህ የሆነበት ምክንያት ፕሮሰሰር ኮርን በመከልከል ወይም የሆነ ነገር ኮርሱ 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 ወረፋ ገብተው በአንድ ሲፒዩ ኮር ነው። ሊኑክስ እንዴት እንደሚሰራ ለመረዳት ከፈለግን ሂደቱን ለመከታተል የት (በየትኛው ሲፒዩ ኮር) እና (softirq, ksoftirqd) እነዚህ ጥቅሎች እንዴት እንደሚሰሩ ማወቅ ጠቃሚ ነው.

አሁን የሊኑክስ ከርነልን በእውነተኛ ጊዜ እንድትከታተሉ የሚያስችሉዎትን መሳሪያዎች ለመጠቀም ጊዜው አሁን ነው። እዚህ ተጠቀምን። ስውር ቅጂ. ይህ የመሳሪያዎች ስብስብ የዘፈቀደ ተግባራትን በከርነል ውስጥ የሚያያይዙ ትናንሽ C ፕሮግራሞችን እንዲጽፉ እና ክስተቶቹን ወደ ተጠቃሚ ቦታ ፓይዘን ፕሮግራም እንዲይዙ እና እነሱን ለማስኬድ እና ውጤቱን ወደ እርስዎ እንዲመልሱ ያስችልዎታል። በከርነል ውስጥ ለሚሰሩ የዘፈቀደ ተግባራት መንጠቆዎች ውስብስብ ጉዳዮች ናቸው፣ ነገር ግን መገልገያው ለከፍተኛ ደህንነት ተብሎ የተነደፈ እና በፈተና ወይም በእድገት አካባቢ በቀላሉ የማይራቡ የምርት ጉዳዮችን በትክክል ለመከታተል የተነደፈ ነው።

እዚህ ያለው እቅድ ቀላል ነው፡ ከርነሉ እነዚህን አይሲኤምፒ ፒንግ እንደሚያስኬድ እናውቃለን፣ ስለዚህ በከርነል ተግባር ላይ መንጠቆን እናደርጋለን icmp_echoገቢ የ ICMP echo ጥያቄ ፓኬትን የሚቀበል እና የICMP የማስተጋባት ምላሽ መላክን ይጀምራል። የሚያሳየው icmp_seq ቁጥር በመጨመር ፓኬትን መለየት እንችላለን hping3 ከፍ ያለ።

ኮድ ቢሲሲ ስክሪፕት ውስብስብ ይመስላል፣ ግን የሚመስለውን ያህል አስፈሪ አይደለም። ተግባር icmp_echo ያስተላልፋል struct sk_buff *skb: ይህ "የማስተጋባት ጥያቄ" ያለው ፓኬት ነው። እኛ ተከታትለን, ቅደም ተከተሎችን ማውጣት እንችላለን echo.sequence (ከዚህ ጋር ይነጻጸራል። icmp_seq በ hping3 выше) እና ወደ ተጠቃሚ ቦታ ይላኩት። የአሁኑን ሂደት ስም/መታወቂያ ለመያዝም ምቹ ነው። የከርነል እሽጎችን በሚያከናውንበት ጊዜ በቀጥታ የምናያቸው ውጤቶች ከዚህ በታች አሉ።

TGID PID ሂደት ስም ICMP_SEQ 0 0 ስዋፐር/11 770 0 0 ስዋፐር/11 771 0 0 ስዋፐር/11 772 0 0 ስዋፐር/11 773 0 0 ስዋፐር/11 774 20041ሜ 20086 775 0 ስዋፐር/0 11 776 0 swapper/0 11 777 0 spokes-report-s 0

እዚህ ላይ በዐውደ-ጽሑፉ ውስጥ መታወቅ አለበት softirq የስርዓት ጥሪዎችን ያደረጉ ሂደቶች እንደ “ሂደቶች” ሆነው የሚታዩት በእውነቱ በከርነል አውድ ውስጥ እሽጎችን ደህንነቱ በተጠበቀ ሁኔታ የሚያስኬድ ከርነል ነው።

በዚህ መሳሪያ የተወሰኑ ሂደቶችን መዘግየቱን ከሚያሳዩ የተወሰኑ ጥቅሎች ጋር ማያያዝ እንችላለን hping3. ቀላል እናድርገው። grep በዚህ ቀረጻ ላይ ለተወሰኑ እሴቶች icmp_seq. ከላይ ከተጠቀሱት icmp_seq እሴቶች ጋር የሚዛመዱ እሽጎች ከላይ ከተመለከትናቸው አርቲቲ ጋር ተገልጸዋል (በቅንፍ ውስጥ ከ50 ሚሴ ባነሰ ጊዜ በአርቲቲ እሴቶች ምክንያት ያጣናቸው ለፓኬቶች የሚጠበቁ የRTT እሴቶች አሉ)

TGID PID ሂደት ስም ICMP_SEQ ** RTT -- 10137 10436 cadvisor 1951 10137 10436 cadvisor 1952 76 76 ksoftirqd/11 1953 ** 99ms 76 76 k11softirqd1954ms/89softirqd76 76 ** 11ms 1955 79 ksoftirqd/76 76 ** 11ms 1956 69 ksoftirqd/76 76 ** 11ms 1957 59 ksoftirqd/76 76 ** (11ms) 1958 49 ksoftirqd/76 76 ** (11ms) 1959 39 ksoftirqd/76 ksoftirqd/76 ksoftirqd/11 / 1960 29 ** (76ms) 76 11 ksoftirqd/1961 19 ** (76ms) -- 76 11 cadvisor 1962 9 10137 cadvisor 10436 2068 10137 ksoftirqd/10436 ksoftirqd/2069 76 76 11 ksoftirqd/2070 75 76 ** 76ms 11 2071 ksoftirqd/ 65 76 ** 76ms 11 2072 ksoftirqd/55 76 ** (76ms) 11 2073 ksoftirqd/45 76 ** (76ms) 11 2074 ksoftirqd/35 76 ** (76ms) 11 ksoftirqd/2075 25 ** (76ms) 76 11 ksoftirqd/2076 15 ** (76ms) 76 ksoftirqd ) 11 2077 ksoftirqd/5 XNUMX ** (XNUMXms)

ውጤቶቹ ብዙ ነገሮችን ይነግሩናል. በመጀመሪያ እነዚህ ሁሉ ፓኬጆች በዐውደ-ጽሑፉ ይከናወናሉ ksoftirqd/11. ይህ ማለት ለዚህ ልዩ ጥንድ ማሽኖች የ ICMP ፓኬቶች በተቀባይ መጨረሻ ላይ ወደ ኮር 11 ተጭነዋል። በተጨማሪም መጨናነቅ በሚኖርበት ጊዜ ሁሉ በስርዓት ጥሪ አውድ ውስጥ የሚዘጋጁ ፓኬቶች እንዳሉ እናያለን። cadvisor... ከዚያ ksoftirqd ተግባሩን ተረክቦ የተከማቸ ወረፋውን ያካሂዳል: በትክክል በኋላ የተጠራቀሙ ፓኬቶች ብዛት cadvisor.

ከሱ በፊት ሁል ጊዜ የሚሠራው እውነታ cadvisor, በችግሩ ውስጥ ያለውን ተሳትፎ ያመለክታል. የሚገርመው አላማው ነው። ካድቪሰር - ይህንን የአፈፃፀም ችግር ከመፍጠር ይልቅ የንብረት አጠቃቀምን እና የአፈፃፀም ባህሪያትን ይተንትኑ ።

ልክ እንደሌሎች የመያዣዎች ገጽታዎች፣ እነዚህ ሁሉ በጣም የተሻሻሉ መሳሪያዎች ናቸው እና በአንዳንድ ያልተጠበቁ ሁኔታዎች ውስጥ የአፈፃፀም ጉዳዮችን ሊያገኙ ይችላሉ ተብሎ ይጠበቃል።

የፓኬት ወረፋውን የሚያዘገየው ካድቪሰር ምን ያደርጋል?

አሁን ብልሽቱ እንዴት እንደሚከሰት፣ በምን ሂደት ላይ እንደሚገኝ እና በየትኛው ሲፒዩ ላይ ጥሩ ግንዛቤ አግኝተናል። በጠንካራ እገዳ ምክንያት የሊኑክስ ከርነል የጊዜ ሰሌዳ ለማውጣት ጊዜ እንደሌለው እናያለን ksoftirqd. እና እሽጎች በዐውደ-ጽሑፍ ውስጥ እንደሚሠሩ እናያለን cadvisor. እንደሆነ መገመት ምክንያታዊ ነው። cadvisor ቀርፋፋ syscall ይጀምራል ፣ ከዚያ በኋላ ሁሉም እሽጎች ይከናወናሉ

በ Kubernetes ውስጥ የአውታረ መረብ መዘግየትን ማረም

ይህ ጽንሰ-ሐሳብ ነው, ግን እንዴት እንደሚሞከር? እኛ ማድረግ የምንችለው በዚህ ሂደት ውስጥ የሲፒዩ ኮርን መከታተል ነው ፣ የፓኬቶች ብዛት ከበጀት በላይ የሚሄድበት እና ksoftirqd የሚጠራበትን ነጥብ ይፈልጉ እና ከዚያ ነጥብ በፊት በትክክል በሲፒዩ ኮር ላይ ምን እየሰራ እንደነበረ ለማየት ትንሽ ወደ ኋላ ይመልከቱ። . በየጥቂት ሚሊሰከንዶች ሲፒዩውን ራጅ እንደማስቀመጥ ነው። እንደዚህ ያለ ነገር ይመስላል።

በ Kubernetes ውስጥ የአውታረ መረብ መዘግየትን ማረም

በምቾት ይህ ሁሉ አሁን ባሉት መሳሪያዎች ሊከናወን ይችላል. ለምሳሌ, perf መዝገብ የተሰጠውን ሲፒዩ ኮር በተወሰነ ፍሪኩዌንሲ ይፈትሻል እና ሁለቱንም የተጠቃሚ ቦታ እና የሊኑክስ ከርነልን ጨምሮ ወደ ሩጫ ስርዓቱ የጥሪ መርሃ ግብር ማመንጨት ይችላል። ይህንን መዝገብ ወስደህ ትንሽ የፕሮግራሙን ሹካ በመጠቀም ማስኬድ ትችላለህ FlameGraph የቁልል ዱካውን ቅደም ተከተል የሚጠብቅ ከብሬንዳን ግሬግ። ነጠላ-መስመር ቁልል ዱካዎችን በየ1 ሚሴ እናቆጥባለን እና ምልክቱ ከመምታቱ በፊት ናሙናውን 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

እዚህ ብዙ ነገሮች አሉ ነገር ግን ዋናው ነገር ቀደም ሲል በICMP መፈለጊያ ውስጥ ያየነውን "ካድቪሰር ከ ksoftirqd በፊት" ስርዓተ-ጥለት ማግኘታችን ነው። ምን ማለት ነው?

እያንዳንዱ መስመር በተወሰነ ጊዜ ውስጥ የሲፒዩ መከታተያ ነው። በአንድ መስመር ላይ ባለው ቁልል ላይ ያለው እያንዳንዱ ጥሪ በሴሚኮሎን ይለያል። በመስመሮቹ መሃል ላይ ሲስካል ሲጠራ እናያለን፡- read(): .... ;do_syscall_64;sys_read; .... ስለዚህ ካድቪሰር በስርዓት ጥሪ ላይ ብዙ ጊዜ ያሳልፋል read()ተግባራት ጋር የተያያዙ mem_cgroup_* (የጥሪ ቁልል/የመስመሩ መጨረሻ)።

በትክክል ምን እየተነበበ እንዳለ በጥሪ ዱካ ውስጥ ማየት የማይመች ነው፣ ስለዚህ እንሩጥ strace እና ካድቪሰር የሚያደርገውን እንይ እና ከ100 ሚሴ በላይ የስርዓት ጥሪዎችን እናገኝ።

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የማህደረ ትውስታ አጠቃቀምን እና የቡድን ስብስቦችን (የዶከር ሪሶርስ ማግለል ቴክኖሎጂ) ያሳያል። የካድቪሰር መሳሪያው ለመያዣዎች የመረጃ አጠቃቀም መረጃ ለማግኘት ይህንን ፋይል ይጠይቃል። ከርነል ወይም ካድቪሰር ያልተጠበቀ ነገር እያደረገ መሆኑን እንፈትሽ፡-

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 ~ $

አሁን ስህተቱን እንደገና ማባዛት እና የሊኑክስ ከርነል የፓቶሎጂ ችግር እንዳለበት መረዳት እንችላለን።

የንባብ ክዋኔው በጣም ቀርፋፋ የሆነው ለምንድነው?

በዚህ ደረጃ, ስለ ተመሳሳይ ችግሮች ከሌሎች ተጠቃሚዎች መልዕክቶችን ማግኘት በጣም ቀላል ነው. እንደ ተለወጠ፣ በካድቪሰር መከታተያ ውስጥ ይህ ስህተት እንደ ተዘገበ ከመጠን በላይ የሲፒዩ አጠቃቀም ችግር፣ መዘግየት እንዲሁ በዘፈቀደ በአውታረ መረብ ቁልል ውስጥ እንደሚንፀባረቅ ማንም አላስተዋለም። በእርግጥም ካድቪሰር ከሚጠበቀው በላይ ሲፒዩ የሚፈጅ መሆኑ ተስተውሏል ነገርግን ይህ ብዙም ትኩረት አልተሰጠውም ምክንያቱም የእኛ አገልጋዮች ብዙ የሲፒዩ ግብአት ስላላቸው ችግሩ በጥንቃቄ አልተጠናም።

ችግሩ ቡድኖች በስም ቦታ (ኮንቴይነር) ውስጥ ያለውን የማህደረ ትውስታ አጠቃቀም ግምት ውስጥ ያስገባሉ። በዚህ ስብስብ ውስጥ ያሉት ሁሉም ሂደቶች ሲወጡ፣ ዶከር የማህደረ ትውስታ ቡድንን ይለቃል። ይሁን እንጂ "ማህደረ ትውስታ" የሂደት ማህደረ ትውስታ ብቻ አይደለም. ምንም እንኳን የሂደቱ ማህደረ ትውስታ በራሱ ጥቅም ላይ ባይውልም, ከርነል አሁንም የተሸጎጡ ይዘቶችን እንደ ጥርስ እና ኢኖዶች (ማውጫ እና ፋይል ሜታዳታ) ይመድባል, እነዚህም በማህደረ ትውስታ ስብስብ ውስጥ የተሸጎጡ ናቸው. ከችግር መግለጫው፡-

የዞምቢ ስብስቦች: ምንም ሂደቶች የሌላቸው እና የተሰረዙ, ግን አሁንም ማህደረ ትውስታ ተመድበዋል (በእኔ ሁኔታ, ከጥርስ መሸጎጫ, ነገር ግን ከገጽ መሸጎጫ ወይም tmpfs ሊመደብ ይችላል).

ቡድንን በሚለቁበት ጊዜ በካሼው ውስጥ ያሉት ሁሉም ገፆች የከርነል ቼክ በጣም አዝጋሚ ሊሆን ይችላል ፣ ስለሆነም ሰነፍ ሂደት ይመረጣል እነዚህ ገጾች እንደገና እስኪጠየቁ ድረስ ይጠብቁ እና በመጨረሻም ማህደረ ትውስታው በሚያስፈልግበት ጊዜ ቡድኑን ያፅዱ። እስከዚህ ነጥብ ድረስ, ግሩፕ ስታቲስቲክስን በሚሰበስቡበት ጊዜ አሁንም ግምት ውስጥ ይገባል.

ከአፈፃፀሙ አንፃር፣ ትውስታን ለአፈጻጸም መስዋዕትነት ከፍለዋል፡ አንዳንድ የተሸጎጠ ማህደረ ትውስታን ወደ ኋላ በመተው የመጀመሪያውን ጽዳት ማፋጠን። ይህ ጥሩ ነው። ከርነሉ የተሸጎጠውን ማህደረ ትውስታ የመጨረሻውን ሲጠቀም ፣ ግሩፕ በመጨረሻ ይጸዳል ፣ ስለሆነም “ሊክ” ሊባል አይችልም። እንደ አለመታደል ሆኖ የፍለጋ ዘዴው ልዩ አተገባበር memory.stat በዚህ የከርነል ሥሪት (4.9) በአገልጋዮቻችን ላይ ካለው ከፍተኛ መጠን ያለው ማህደረ ትውስታ ጋር ተዳምሮ የቅርብ ጊዜውን የተሸጎጠ ዳታ ወደነበረበት ለመመለስ እና የቡድን ዞምቢዎችን ለማጽዳት ብዙ ጊዜ ይወስዳል ማለት ነው።

አንዳንድ የእኛ አንጓዎች በጣም ብዙ ስብስብ ዞምቢዎች ስለነበሯቸው ንባቡ እና መዘግየት ከአንድ ሰከንድ በላይ አልፏል።

ለካድቪሰር ችግር መፍትሄው በስርአቱ ውስጥ ያሉ የጥርስ መሸጎጫዎች/ኢኖዶች መሸጎጫዎችን ወዲያውኑ ነፃ ማድረግ ሲሆን ይህም ወዲያውኑ የንባብ መዘግየትን እንዲሁም በአስተናጋጁ ላይ ያለውን የኔትወርክ መዘግየት ያስወግዳል ምክንያቱም መሸጎጫውን ማጽዳት የተሸጎጡ የዞምቢ ቡድን ገጾችን ይከፍታል እና እነሱንም ነፃ ያወጣቸዋል። ይህ መፍትሄ አይደለም, ነገር ግን የችግሩን መንስኤ ያረጋግጣል.

በአዲሶቹ የከርነል ስሪቶች (4.19+) የጥሪ አፈጻጸም ተሻሽሏል። memory.statስለዚህ ወደዚህ ከርነል መቀየር ችግሩን አስተካክሏል። በተመሳሳይ ጊዜ፣ ችግር ያለባቸውን አንጓዎች በኩበርኔትስ ክላስተር ውስጥ የምንለይበት፣ በሚያምር ሁኔታ ለማፍሰስ እና እንደገና ለማስነሳት መሳሪያዎች ነበሩን። ሁሉንም ዘለላዎች በማበጠር፣ ከፍተኛ መዘግየት ያላቸውን አንጓዎች አግኝተን ዳግም አስነሳናቸው። ይህ በቀሪዎቹ አገልጋዮች ላይ ስርዓተ ክወናውን ለማዘመን ጊዜ ሰጠን።

ለማጠቃለል

ይህ ሳንካ የ RX NIC ወረፋ ሂደትን በመቶ ሚሊሰከንዶች ስላቆመ፣ በአንድ ጊዜ ሁለቱንም በአጭር ግንኙነቶች እና በግንኙነት መሀል መዘግየት ላይ፣ ለምሳሌ MySQL ጥያቄዎች እና የምላሽ እሽጎች ላይ ሁለቱንም ከፍተኛ መዘግየት አስከትሏል።

እንደ ኩበርኔትስ ያሉ በጣም መሠረታዊ ስርዓቶችን መረዳት እና አፈፃፀምን መጠበቅ በእነሱ ላይ ተመስርተው ለሁሉም አገልግሎቶች አስተማማኝነት እና ፍጥነት ወሳኝ ነው። እያንዳንዱ የሚያሄዱት ስርዓት ከKubernetes የአፈጻጸም ማሻሻያዎችን ይጠቀማል።

ምንጭ: hab.com

አስተያየት ያክሉ