കുറച്ച് വർഷങ്ങൾക്ക് മുമ്പ് കുബർനെറ്റസ് ഇതിനകം ചർച്ച ചെയ്തു ഔദ്യോഗിക GitHub ബ്ലോഗിൽ. അതിനുശേഷം, സേവനങ്ങൾ വിന്യസിക്കുന്നതിനുള്ള അടിസ്ഥാന സാങ്കേതികവിദ്യയായി ഇത് മാറി. കുബർനെറ്റസ് ഇപ്പോൾ ആഭ്യന്തര, പൊതു സേവനങ്ങളുടെ ഒരു പ്രധാന ഭാഗം കൈകാര്യം ചെയ്യുന്നു. ഞങ്ങളുടെ ക്ലസ്റ്ററുകൾ വളരുകയും പ്രകടന ആവശ്യകതകൾ കൂടുതൽ കർശനമാക്കുകയും ചെയ്തപ്പോൾ, കുബർനെറ്റിലെ ചില സേവനങ്ങൾ ആപ്പിന്റെ ലോഡുകൊണ്ട് തന്നെ വിശദീകരിക്കാൻ കഴിയാത്ത കാലതാമസം നേരിടുന്നത് ഞങ്ങൾ ശ്രദ്ധിക്കാൻ തുടങ്ങി.

അടിസ്ഥാനപരമായി, ആപ്ലിക്കേഷനുകൾക്ക് 100ms അല്ലെങ്കിൽ അതിൽ കൂടുതലുള്ള ക്രമരഹിതമായ നെറ്റ്‌വർക്ക് ലേറ്റൻസി അനുഭവപ്പെടുന്നു, അതിന്റെ ഫലമായി സമയപരിധികൾ അല്ലെങ്കിൽ വീണ്ടും ശ്രമിക്കാം. സേവനങ്ങൾക്ക് അഭ്യർത്ഥനകളോട് 100 എംഎസിനേക്കാൾ വേഗത്തിൽ പ്രതികരിക്കാൻ കഴിയുമെന്ന് പ്രതീക്ഷിച്ചിരുന്നു. എന്നാൽ കണക്ഷൻ തന്നെ വളരെയധികം സമയമെടുത്താൽ ഇത് അസാധ്യമാണ്. വെവ്വേറെ, മില്ലിസെക്കൻഡ് എടുക്കേണ്ട വളരെ വേഗതയുള്ള MySQL അന്വേഷണങ്ങൾ ഞങ്ങൾ നിരീക്ഷിച്ചു, കൂടാതെ MySQL മില്ലിസെക്കൻഡിൽ പൂർത്തിയാക്കി, എന്നാൽ അപേക്ഷയുടെ വീക്ഷണകോണിൽ നിന്ന്, പ്രതികരണത്തിന് 100 ms അല്ലെങ്കിൽ അതിൽ കൂടുതൽ സമയമെടുത്തു.

ഒരു കുബർനെറ്റസ് നോഡിലേക്ക് കണക്‌റ്റ് ചെയ്യുമ്പോൾ മാത്രമാണ് പ്രശ്‌നം സംഭവിച്ചതെന്ന് ഉടൻ തന്നെ വ്യക്തമായി, കുബർനെറ്റസിന് പുറത്ത് നിന്ന് കോൾ വന്നാലും. പ്രശ്നം പുനർനിർമ്മിക്കാനുള്ള എളുപ്പവഴി ഒരു പരിശോധനയാണ് വെജിറ്റ, ഏത് ആന്തരിക ഹോസ്റ്റിൽ നിന്നും പ്രവർത്തിക്കുന്നു, ഒരു നിർദ്ദിഷ്‌ട പോർട്ടിൽ കുബർനെറ്റസ് സേവനം പരിശോധിക്കുന്നു, ഇടയ്ക്കിടെ ഉയർന്ന ലേറ്റൻസി രജിസ്റ്റർ ചെയ്യുന്നു. ഈ ലേഖനത്തിൽ, ഈ പ്രശ്നത്തിന്റെ കാരണം കണ്ടെത്താൻ ഞങ്ങൾക്ക് എങ്ങനെ കഴിഞ്ഞുവെന്ന് നോക്കാം.

പരാജയത്തിലേക്ക് നയിക്കുന്ന ചങ്ങലയിലെ അനാവശ്യ സങ്കീർണ്ണത ഇല്ലാതാക്കുന്നു

അതേ ഉദാഹരണം പുനർനിർമ്മിക്കുന്നതിലൂടെ, പ്രശ്നത്തിന്റെ ശ്രദ്ധ ചുരുക്കാനും സങ്കീർണ്ണതയുടെ അനാവശ്യ പാളികൾ നീക്കംചെയ്യാനും ഞങ്ങൾ ആഗ്രഹിച്ചു. തുടക്കത്തിൽ, വെജിറ്റയ്ക്കും കുബർനെറ്റസ് പോഡുകൾക്കും ഇടയിലുള്ള ഒഴുക്കിൽ വളരെയധികം ഘടകങ്ങൾ ഉണ്ടായിരുന്നു. ആഴത്തിലുള്ള നെറ്റ്‌വർക്ക് പ്രശ്‌നം തിരിച്ചറിയുന്നതിന്, അവയിൽ ചിലത് നിങ്ങൾ ഒഴിവാക്കേണ്ടതുണ്ട്.

ക്ലയന്റ് (വെജിറ്റ) ക്ലസ്റ്ററിലെ ഏത് നോഡുമായി ഒരു ടിസിപി കണക്ഷൻ സൃഷ്ടിക്കുന്നു. കുബെർനെറ്റസ് ഒരു ഓവർലേ നെറ്റ്‌വർക്കായി പ്രവർത്തിക്കുന്നു (നിലവിലുള്ള ഡാറ്റാ സെന്റർ നെറ്റ്‌വർക്കിന്റെ മുകളിൽ). IPIP, അതായത്, ഇത് ഡാറ്റാ സെന്ററിന്റെ ഐപി പാക്കറ്റുകൾക്കുള്ളിൽ ഓവർലേ നെറ്റ്‌വർക്കിന്റെ ഐപി പാക്കറ്റുകളെ ഉൾക്കൊള്ളുന്നു. ആദ്യ നോഡിലേക്ക് കണക്റ്റുചെയ്യുമ്പോൾ, നെറ്റ്‌വർക്ക് വിലാസ വിവർത്തനം നടത്തുന്നു നെറ്റ്‌വർക്ക് വിലാസ വിവർത്തനം (NAT) കുബെർനെറ്റസ് നോഡിന്റെ IP വിലാസവും പോർട്ടും ഓവർലേ നെറ്റ്‌വർക്കിലെ IP വിലാസത്തിലേക്കും പോർട്ടിലേക്കും (പ്രത്യേകിച്ച്, ആപ്ലിക്കേഷനുമൊത്തുള്ള പോഡ്) വിവർത്തനം ചെയ്യാൻ വ്യക്തമാണ്. ഇൻകമിംഗ് പാക്കറ്റുകൾക്കായി, പ്രവർത്തനങ്ങളുടെ വിപരീത ക്രമം നടപ്പിലാക്കുന്നു. സേവനങ്ങൾ വിന്യസിക്കുകയും നീക്കുകയും ചെയ്യുന്നതിനനുസരിച്ച് നിരന്തരം അപ്‌ഡേറ്റ് ചെയ്യുകയും മാറുകയും ചെയ്യുന്ന നിരവധി സംസ്ഥാനങ്ങളും നിരവധി ഘടകങ്ങളും ഉള്ള ഒരു സങ്കീർണ്ണ സംവിധാനമാണിത്.

യൂട്ടിലിറ്റി tcpdump വെജിറ്റ ടെസ്റ്റിൽ TCP ഹാൻഡ്‌ഷേക്ക് സമയത്ത് (SYN-നും SYN-ACK-നും ഇടയിൽ) കാലതാമസമുണ്ട്. ഈ അനാവശ്യ സങ്കീർണ്ണത നീക്കം ചെയ്യാൻ, നിങ്ങൾക്ക് ഉപയോഗിക്കാം hping3 SYN പാക്കറ്റുകളുള്ള ലളിതമായ "പിംഗ്സ്". പ്രതികരണ പാക്കറ്റിൽ കാലതാമസമുണ്ടോ എന്ന് ഞങ്ങൾ പരിശോധിക്കുന്നു, തുടർന്ന് കണക്ഷൻ പുനഃസജ്ജമാക്കുക. വെജിറ്റയുടെ പൂർണ്ണ നെറ്റ്‌വർക്ക് ലെയർ 100 ടെസ്‌റ്റിനേക്കാൾ 7ms-ൽ കൂടുതലുള്ള പാക്കറ്റുകൾ മാത്രം ഉൾപ്പെടുത്താനും പ്രശ്‌നം പുനർനിർമ്മിക്കാനുള്ള എളുപ്പവഴി നേടാനും ഞങ്ങൾക്ക് ഡാറ്റ ഫിൽട്ടർ ചെയ്യാനാകും. "നോഡ് പോർട്ട്" (30927) എന്ന സേവനത്തിൽ TCP SYN/SYN-ACK ഉപയോഗിക്കുന്ന Kubernetes നോഡ് "പിംഗ്സ്" ഇതാ, 10ms ഇടവേളകളിൽ, വേഗത കുറഞ്ഞ പ്രതികരണങ്ങളാൽ ഫിൽട്ടർ ചെയ്‌തിരിക്കുന്നു:

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 ഭാഗം മാത്രം അവശേഷിക്കുന്നു:

ഭാഗ്യവശാൽ, മെഷീൻ ഒരേ നെറ്റ്‌വർക്കിലാണെങ്കിൽ ഐപി ഓവർലേ ലെയർ നേരിട്ട് ആക്‌സസ് ചെയ്യുന്നത് Linux എളുപ്പമാക്കുന്നു:

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 പിംഗ് പോലും അയയ്ക്കുന്നു. ടാർഗെറ്റ് ഹോസ്റ്റ് "മോശം" ആണെങ്കിൽ (മറ്റുള്ളതിനേക്കാൾ മോശമായത്) അവർ ഇപ്പോഴും ലേറ്റൻസി കാണുന്നു.

ഇപ്പോൾ അവസാന ചോദ്യം: എന്തുകൊണ്ടാണ് ക്യൂബ്-നോഡ് സെർവറുകളിൽ മാത്രം കാലതാമസം സംഭവിക്കുന്നത്? kube-node അയയ്ക്കുന്നയാളോ സ്വീകർത്താവോ ആയിരിക്കുമ്പോൾ അത് സംഭവിക്കുമോ? ഭാഗ്യവശാൽ, കുബെർനെറ്റസിന് പുറത്തുള്ള ഒരു ഹോസ്റ്റിൽ നിന്ന് ഒരു പാക്കറ്റ് അയച്ചുകൊണ്ട് ഇത് കണ്ടെത്തുന്നത് വളരെ എളുപ്പമാണ്, എന്നാൽ അതേ "അറിയപ്പെടുന്ന മോശം" സ്വീകർത്താവിനൊപ്പം. നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, പ്രശ്നം അപ്രത്യക്ഷമായിട്ടില്ല:

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

ലേറ്റൻസി പാക്കറ്റ് ക്യാപ്‌ചറുകൾ പരിശോധിക്കുന്നതിലൂടെ, ഞങ്ങൾക്ക് ചില അധിക വിവരങ്ങൾ ലഭിച്ചു. പ്രത്യേകമായി, അയച്ചയാൾ (ചുവടെ) ഈ സമയപരിധി കാണുന്നു, എന്നാൽ സ്വീകർത്താവ് (മുകളിൽ) കാണുന്നില്ല - ഡെൽറ്റ കോളം കാണുക (സെക്കൻഡിൽ):

കൂടാതെ, സ്വീകർത്താവിന്റെ ഭാഗത്ത് ടിസിപി, ഐസിഎംപി പാക്കറ്റുകളുടെ ക്രമത്തിലെ വ്യത്യാസം (അനുക്രമ നമ്പറുകൾ പ്രകാരം) നിങ്ങൾ നോക്കുകയാണെങ്കിൽ, ഐസിഎംപി പാക്കറ്റുകൾ എല്ലായ്‌പ്പോഴും അവ അയച്ച അതേ ശ്രേണിയിൽ എത്തുന്നു, പക്ഷേ വ്യത്യസ്ത സമയത്തോടെ. അതേ സമയം, ടിസിപി പാക്കറ്റുകൾ ചിലപ്പോൾ ഇടകലരുന്നു, അവയിൽ ചിലത് കുടുങ്ങുന്നു. പ്രത്യേകിച്ചും, നിങ്ങൾ SYN പാക്കറ്റുകളുടെ പോർട്ടുകൾ പരിശോധിക്കുകയാണെങ്കിൽ, അവ അയച്ചയാളുടെ ഭാഗത്ത് ക്രമത്തിലാണ്, പക്ഷേ റിസീവറുടെ വശത്തല്ല.

എങ്ങനെ എന്നതിൽ സൂക്ഷ്മമായ വ്യത്യാസമുണ്ട് നെറ്റ്വർക്ക് കാർഡുകൾ ആധുനിക സെർവറുകൾ (ഞങ്ങളുടെ ഡാറ്റാ സെന്ററിലുള്ളത് പോലെ) TCP അല്ലെങ്കിൽ ICMP അടങ്ങിയ പാക്കറ്റുകൾ പ്രോസസ്സ് ചെയ്യുന്നു. ഒരു പാക്കറ്റ് വരുമ്പോൾ, നെറ്റ്‌വർക്ക് അഡാപ്റ്റർ "ഓരോ കണക്ഷനും ഹാഷ് ചെയ്യുന്നു", അതായത്, കണക്ഷനുകളെ ക്യൂകളാക്കി മാറ്റി ഓരോ ക്യൂവും ഒരു പ്രത്യേക പ്രോസസർ കോറിലേക്ക് അയയ്ക്കാൻ ശ്രമിക്കുന്നു. ടിസിപിക്ക്, ഈ ഹാഷിൽ ഉറവിടവും ലക്ഷ്യസ്ഥാന ഐപി വിലാസവും പോർട്ടും ഉൾപ്പെടുന്നു. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ഓരോ കണക്ഷനും വ്യത്യസ്തമായി (സാധ്യതയുള്ള) ഹാഷ് ചെയ്തിരിക്കുന്നു. ഐസിഎംപിക്ക്, പോർട്ടുകൾ ഇല്ലാത്തതിനാൽ ഐപി വിലാസങ്ങൾ മാത്രമേ ഹാഷ് ചെയ്തിട്ടുള്ളൂ.

മറ്റൊരു പുതിയ നിരീക്ഷണം: ഈ കാലയളവിൽ രണ്ട് ഹോസ്റ്റുകൾ തമ്മിലുള്ള എല്ലാ ആശയവിനിമയങ്ങളിലും ICMP കാലതാമസം ഞങ്ങൾ കാണുന്നു, പക്ഷേ TCP ഇല്ല. കാരണം RX ക്യൂ ഹാഷിംഗുമായി ബന്ധപ്പെട്ടതാണെന്ന് ഇത് നമ്മോട് പറയുന്നു: തിരക്ക് മിക്കവാറും RX പാക്കറ്റുകളുടെ പ്രോസസ്സിംഗിലാണ്, പ്രതികരണങ്ങൾ അയയ്ക്കുന്നതിലല്ല.

ഇത് സാധ്യമായ കാരണങ്ങളുടെ പട്ടികയിൽ നിന്ന് പാക്കറ്റുകൾ അയയ്ക്കുന്നത് ഒഴിവാക്കുന്നു. ചില ക്യൂബ്-നോഡ് സെർവറുകളിൽ സ്വീകരിക്കുന്ന ഭാഗത്ത് പാക്കറ്റ് പ്രോസസ്സിംഗ് പ്രശ്നം ഉണ്ടെന്ന് ഇപ്പോൾ ഞങ്ങൾക്കറിയാം.

Linux കേർണലിലെ പാക്കറ്റ് പ്രോസസ്സിംഗ് മനസ്സിലാക്കുന്നു

ചില kube-node സെർവറുകളിലെ റിസീവറിൽ പ്രശ്നം സംഭവിക്കുന്നത് എന്തുകൊണ്ടാണെന്ന് മനസിലാക്കാൻ, Linux കേർണൽ എങ്ങനെയാണ് പാക്കറ്റുകൾ പ്രോസസ്സ് ചെയ്യുന്നത് എന്ന് നോക്കാം.

ലളിതമായ പരമ്പരാഗത നടപ്പാക്കലിലേക്ക് മടങ്ങുമ്പോൾ, നെറ്റ്വർക്ക് കാർഡ് പാക്കറ്റ് സ്വീകരിക്കുകയും അയയ്ക്കുകയും ചെയ്യുന്നു തടസ്സപ്പെടുത്തുക പ്രോസസ്സ് ചെയ്യേണ്ട ഒരു പാക്കേജ് ഉണ്ടെന്ന് Linux കേർണൽ. കേർണൽ മറ്റ് ജോലികൾ നിർത്തുന്നു, ഇന്ററപ്റ്റ് ഹാൻഡ്‌ലറിലേക്ക് സന്ദർഭം മാറ്റുന്നു, പാക്കറ്റ് പ്രോസസ്സ് ചെയ്യുന്നു, തുടർന്ന് നിലവിലെ ജോലികളിലേക്ക് മടങ്ങുന്നു.

ഈ സന്ദർഭ സ്വിച്ചിംഗ് മന്ദഗതിയിലാണ്: 10-കളിൽ 90Mbps നെറ്റ്‌വർക്ക് കാർഡുകളിൽ ലേറ്റൻസി ശ്രദ്ധയിൽപ്പെട്ടിട്ടുണ്ടാകില്ല, എന്നാൽ സെക്കൻഡിൽ പരമാവധി 10 ദശലക്ഷം പാക്കറ്റുകളുള്ള ആധുനിക 15G കാർഡുകളിൽ, ഒരു ചെറിയ എട്ട് കോർ സെർവറിന്റെ ഓരോ കോറും ദശലക്ഷക്കണക്കിന് തടസ്സപ്പെടാം. സെക്കൻഡിൽ തവണ.

തടസ്സങ്ങൾ നിരന്തരം കൈകാര്യം ചെയ്യാതിരിക്കാൻ, വർഷങ്ങൾക്ക് മുമ്പ് Linux ചേർത്തു NAPI: ഉയർന്ന വേഗതയിൽ പ്രകടനം മെച്ചപ്പെടുത്താൻ എല്ലാ ആധുനിക ഡ്രൈവറുകളും ഉപയോഗിക്കുന്ന നെറ്റ്‌വർക്ക് API. കുറഞ്ഞ വേഗതയിൽ, കെർണലിന് ഇപ്പോഴും പഴയ രീതിയിൽ നെറ്റ്‌വർക്ക് കാർഡിൽ നിന്ന് തടസ്സങ്ങൾ ലഭിക്കുന്നു. പരിധി കവിയുന്ന മതിയായ പാക്കറ്റുകൾ എത്തിക്കഴിഞ്ഞാൽ, കേർണൽ തടസ്സങ്ങൾ പ്രവർത്തനരഹിതമാക്കുകയും പകരം നെറ്റ്‌വർക്ക് അഡാപ്റ്റർ പോളിംഗ് ചെയ്യുകയും പാക്കറ്റുകൾ കഷണങ്ങളായി എടുക്കുകയും ചെയ്യുന്നു. പ്രോസസ്സിംഗ് നടത്തുന്നത് softirq-ൽ ആണ്, അതായത് ഇൻ സോഫ്റ്റ്വെയർ തടസ്സങ്ങളുടെ സന്ദർഭം സിസ്റ്റം കോളുകൾക്കും ഹാർഡ്‌വെയർ തടസ്സങ്ങൾക്കും ശേഷം, കേർണൽ (ഉപയോക്തൃ സ്ഥലത്തിന് വിപരീതമായി) ഇതിനകം പ്രവർത്തിക്കുമ്പോൾ.

ഇത് വളരെ വേഗതയുള്ളതാണ്, പക്ഷേ മറ്റൊരു പ്രശ്നം ഉണ്ടാക്കുന്നു. വളരെയധികം പാക്കറ്റുകൾ ഉണ്ടെങ്കിൽ, നെറ്റ്‌വർക്ക് കാർഡിൽ നിന്നുള്ള പാക്കറ്റുകൾ പ്രോസസ്സ് ചെയ്യുന്നതിന് മുഴുവൻ സമയവും ചെലവഴിക്കുന്നു, കൂടാതെ ഈ ക്യൂകൾ യഥാർത്ഥത്തിൽ ശൂന്യമാക്കാൻ ഉപയോക്തൃ സ്പേസ് പ്രോസസ്സുകൾക്ക് സമയമില്ല (ടിസിപി കണക്ഷനുകളിൽ നിന്ന് വായിക്കുന്നത് മുതലായവ). ഒടുവിൽ ക്യൂകൾ നിറയുകയും ഞങ്ങൾ പാക്കറ്റുകൾ ഇടാൻ തുടങ്ങുകയും ചെയ്യുന്നു. ഒരു ബാലൻസ് കണ്ടെത്താനുള്ള ശ്രമത്തിൽ, softirq സന്ദർഭത്തിൽ പ്രോസസ്സ് ചെയ്യുന്ന പരമാവധി പാക്കറ്റുകൾക്ക് കേർണൽ ഒരു ബജറ്റ് സജ്ജമാക്കുന്നു. ഈ ബജറ്റ് കവിഞ്ഞാൽ, ഒരു പ്രത്യേക ത്രെഡ് ഉണർന്നിരിക്കുന്നു ksoftirqd (അവരിൽ ഒരാളെ നിങ്ങൾ കാണും ps ഓരോ കോർ) സാധാരണ സിസ്‌കോൾ/ഇന്ററപ്റ്റ് പാത്തിന് പുറത്ത് ഈ സോഫ്റ്റ്‌ഇർക്‌സ് കൈകാര്യം ചെയ്യുന്നു. ഈ ത്രെഡ് സ്റ്റാൻഡേർഡ് പ്രോസസ്സ് ഷെഡ്യൂളർ ഉപയോഗിച്ചാണ് ഷെഡ്യൂൾ ചെയ്തിരിക്കുന്നത്, അത് വിഭവങ്ങൾ ന്യായമായി അനുവദിക്കാൻ ശ്രമിക്കുന്നു.

കേർണൽ പാക്കറ്റുകൾ എങ്ങനെ പ്രോസസ്സ് ചെയ്യുന്നു എന്ന് പഠിച്ച ശേഷം, തിരക്ക് ഉണ്ടാകാനുള്ള ഒരു സാധ്യതയുണ്ടെന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും. 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 കോർ ഉപയോഗിച്ച് പ്രോസസ്സ് ചെയ്യുകയും ചെയ്യുന്നു. Linux എങ്ങനെയാണ് പ്രവർത്തിക്കുന്നത് എന്ന് നമുക്ക് മനസ്സിലാക്കണമെങ്കിൽ, പ്രക്രിയ ട്രാക്ക് ചെയ്യുന്നതിനായി ഈ പാക്കേജുകൾ എവിടെ (ഏത് CPU കോർ) എങ്ങനെ (softirq, ksoftirqd) പ്രോസസ്സ് ചെയ്യുന്നു എന്നറിയുന്നത് ഉപയോഗപ്രദമാണ്.

ലിനക്സ് കേർണൽ തത്സമയം നിരീക്ഷിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന ടൂളുകൾ ഉപയോഗിക്കാനുള്ള സമയമാണിത്. ഇവിടെ ഞങ്ങൾ ഉപയോഗിച്ചു ബിസിസി. കേർണലിൽ അനിയന്ത്രിതമായ ഫംഗ്‌ഷനുകൾ ഹുക്ക് ചെയ്യുന്ന ചെറിയ സി പ്രോഗ്രാമുകൾ എഴുതാനും ഇവന്റുകൾ ഒരു യൂസർ-സ്‌പേസ് പൈത്തൺ പ്രോഗ്രാമിലേക്ക് ബഫർ ചെയ്യാനും ഈ ടൂളുകളുടെ ഒരു കൂട്ടം നിങ്ങളെ അനുവദിക്കുന്നു, അവ പ്രോസസ്സ് ചെയ്യാനും ഫലം നിങ്ങൾക്ക് തിരികെ നൽകാനും കഴിയും. കേർണലിലെ അനിയന്ത്രിതമായ ഫംഗ്‌ഷനുകൾക്കുള്ള കൊളുത്തുകൾ ഒരു സങ്കീർണ്ണമായ കാര്യമാണ്, എന്നാൽ യൂട്ടിലിറ്റി പരമാവധി സുരക്ഷയ്‌ക്കായി രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നതും ഒരു ടെസ്റ്റ് അല്ലെങ്കിൽ ഡെവലപ്‌മെന്റ് പരിതസ്ഥിതിയിൽ എളുപ്പത്തിൽ പുനർനിർമ്മിക്കാത്ത തരത്തിലുള്ള ഉൽ‌പാദന പ്രശ്‌നങ്ങൾ കൃത്യമായി കണ്ടെത്തുന്നതിനാണ് രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നത്.

ഇവിടെയുള്ള പ്ലാൻ ലളിതമാണ്: കേർണൽ ഈ ഐസിഎംപി പിംഗുകൾ പ്രോസസ്സ് ചെയ്യുന്നുവെന്ന് ഞങ്ങൾക്കറിയാം, അതിനാൽ ഞങ്ങൾ കേർണൽ ഫംഗ്ഷനിൽ ഒരു ഹുക്ക് ഇടും. 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 സ്വാപ്പർ/11 770 0 0 സ്വാപ്പർ/11 771 0 0 സ്വാപ്പർ/11 772 0 0 സ്വാപ്പർ/11 773 0 0 swapper/11 prome സ്വാപ്പർ/774 20041 20086 775 സ്വാപ്പർ/0 0 11 776 0 സ്വാപ്പർ/0 11 777 0 സ്‌പോക്ക്‌സ്-റിപ്പോർട്ട്-എസ് 0

എന്ന സന്ദർഭത്തിലാണ് ഇവിടെ ശ്രദ്ധിക്കേണ്ടത് softirq കേർണലിന്റെ പശ്ചാത്തലത്തിൽ പാക്കറ്റുകൾ സുരക്ഷിതമായി പ്രോസസ്സ് ചെയ്യുന്നത് കേർണലായിരിക്കുമ്പോൾ സിസ്റ്റം കോളുകൾ ഉണ്ടാക്കിയ പ്രോസസ്സുകൾ "പ്രോസസുകൾ" ആയി ദൃശ്യമാകും.

ഈ ടൂൾ ഉപയോഗിച്ച്, കാലതാമസം കാണിക്കുന്ന നിർദ്ദിഷ്ട പാക്കേജുകളുമായി നമുക്ക് നിർദ്ദിഷ്ട പ്രക്രിയകളെ ബന്ധപ്പെടുത്താൻ കഴിയും hping3. നമുക്ക് ഇത് ലളിതമാക്കാം grep ചില മൂല്യങ്ങൾക്കായി ഈ ക്യാപ്‌ചറിൽ icmp_seq. മുകളിൽ പറഞ്ഞിരിക്കുന്ന icmp_seq മൂല്യങ്ങളുമായി പൊരുത്തപ്പെടുന്ന പാക്കറ്റുകൾ അവയുടെ RTTയ്‌ക്കൊപ്പം ഞങ്ങൾ മുകളിൽ നിരീക്ഷിച്ചു (50 ms-ൽ താഴെയുള്ള RTT മൂല്യങ്ങൾ കാരണം ഞങ്ങൾ ഫിൽട്ടർ ചെയ്‌ത പാക്കറ്റുകൾക്കായുള്ള പ്രതീക്ഷിക്കുന്ന RTT മൂല്യങ്ങളാണ് പരാൻതീസിസിൽ നൽകിയിരിക്കുന്നത്):

TGID PID പ്രക്രിയയുടെ പേര് ICMP_SEQ ** RTT -- 10137 10436 cadvisor 1951 10137 10436 cadvisor 1952 76 76 ksoftirqd/11 1953 ** 99ms/soft 76 76 11 ksoftir qd/1954 89 ** 76ms 76 11 ksoftirqd/ 1955 79 ** 76ms 76 11 ksoftirqd/1956 69 ** 76ms 76 11 ksoftirqd/1957 59 ** (76ms) 76 11 ksoftirqd/1958 49 ** (76ms) ksoft (76ms) 11 1959 39 ksoft irqd/ 76 76 ** (11ms) 1960 29 ksoftirqd/76 76 ** (11ms) -- 1961 19 cadvisor 76 76 11 cadvisor 1962 * 9 10137 10436 k2068soft 10137 10436 ksoftirqd/2069 76 ** 76ms 11 2070 ksoftirqd/ 75 76 ** 76ms 11 2071 ksoftirqd/65 76 ** (76ms) 11 2072 ksoftirqd/55 76 ** (76ms) 11 2073 ksoftirqd/45 (76 ksoftirqd/76 11 ksoftirqd/2074 35*76 ** (76 മി ) 11 2075 ksoftirqd/25 76 ** (76ms)

ഫലങ്ങൾ നമ്മോട് നിരവധി കാര്യങ്ങൾ പറയുന്നു. ഒന്നാമതായി, ഈ പാക്കേജുകളെല്ലാം സന്ദർഭത്തിനനുസരിച്ചാണ് പ്രോസസ്സ് ചെയ്യുന്നത് ksoftirqd/11. ഇതിനർത്ഥം ഈ പ്രത്യേക ജോഡി മെഷീനുകൾക്കായി, സ്വീകരിക്കുന്ന അവസാനത്തിൽ ICMP പാക്കറ്റുകൾ കോർ 11 ലേക്ക് ഹാഷ് ചെയ്തു എന്നാണ്. ഒരു ജാം ഉണ്ടാകുമ്പോഴെല്ലാം, സിസ്റ്റം കോളിന്റെ പശ്ചാത്തലത്തിൽ പ്രോസസ്സ് ചെയ്യുന്ന പാക്കറ്റുകൾ ഉണ്ടെന്നും ഞങ്ങൾ കാണുന്നു cadvisor. പിന്നെ ksoftirqd ചുമതല ഏറ്റെടുക്കുകയും ശേഖരിക്കപ്പെട്ട ക്യൂ പ്രോസസ്സ് ചെയ്യുകയും ചെയ്യുന്നു: കൃത്യമായ ശേഷം ശേഖരിച്ച പാക്കറ്റുകളുടെ എണ്ണം cadvisor.

അതിന് തൊട്ടുമുമ്പ് അത് എല്ലായ്പ്പോഴും പ്രവർത്തിക്കുന്നു എന്നതാണ് വസ്തുത cadvisor, പ്രശ്നത്തിൽ അവന്റെ പങ്കാളിത്തം സൂചിപ്പിക്കുന്നു. വിരോധാഭാസമെന്നു പറയട്ടെ, ഉദ്ദേശ്യം കാഡ്വൈസർ - ഈ പ്രകടന പ്രശ്‌നത്തിന് കാരണമാകുന്നതിനുപകരം "പ്രവർത്തിക്കുന്ന കണ്ടെയ്‌നറുകളുടെ ഉറവിട ഉപയോഗവും പ്രകടന സവിശേഷതകളും വിശകലനം ചെയ്യുക".

കണ്ടെയ്‌നറുകളുടെ മറ്റ് വശങ്ങളെപ്പോലെ, ഇവയെല്ലാം വളരെ നൂതനമായ ഉപകരണങ്ങളാണ്, ചില അപ്രതീക്ഷിത സാഹചര്യങ്ങളിൽ പ്രകടന പ്രശ്‌നങ്ങൾ അനുഭവപ്പെടുമെന്ന് പ്രതീക്ഷിക്കാം.

പാക്കറ്റ് ക്യൂ മന്ദഗതിയിലാക്കാൻ കാഡ്‌വൈസർ എന്താണ് ചെയ്യുന്നത്?

ക്രാഷ് എങ്ങനെ സംഭവിക്കുന്നു, എന്ത് പ്രക്രിയയാണ് അതിന് കാരണമാകുന്നത്, ഏത് സിപിയുവിൽ ആണ് ഇപ്പോൾ ഞങ്ങൾക്ക് നല്ല ധാരണയുണ്ട്. ഹാർഡ് ബ്ലോക്കിംഗ് കാരണം, ലിനക്സ് കേർണലിന് ഷെഡ്യൂൾ ചെയ്യാൻ സമയമില്ലെന്ന് ഞങ്ങൾ കാണുന്നു ksoftirqd. പാക്കറ്റുകൾ സന്ദർഭത്തിൽ പ്രോസസ്സ് ചെയ്യുന്നതായി ഞങ്ങൾ കാണുന്നു cadvisor. അത് അനുമാനിക്കുന്നത് യുക്തിസഹമാണ് cadvisor ഒരു സ്ലോ സൈസ്കാൾ സമാരംഭിക്കുന്നു, അതിനുശേഷം ആ സമയത്ത് ശേഖരിച്ച എല്ലാ പാക്കറ്റുകളും പ്രോസസ്സ് ചെയ്യുന്നു:

ഇതൊരു സിദ്ധാന്തമാണ്, എന്നാൽ ഇത് എങ്ങനെ പരിശോധിക്കാം? ഈ പ്രക്രിയയിലുടനീളം സിപിയു കോർ കണ്ടെത്തുക, പാക്കറ്റുകളുടെ എണ്ണം ബജറ്റിനേക്കാൾ കൂടുതലായി പോകുന്ന പോയിന്റ് കണ്ടെത്തുകയും ksoftirqd എന്ന് വിളിക്കുകയും ചെയ്യുക, തുടർന്ന് ആ പോയിന്റിന് തൊട്ടുമുമ്പ് സിപിയു കോറിൽ കൃത്യമായി എന്താണ് പ്രവർത്തിക്കുന്നതെന്ന് കാണാൻ കുറച്ച് മുന്നോട്ട് നോക്കുക. . ഓരോ മില്ലിസെക്കൻഡിലും സിപിയു എക്സ്-റേ ചെയ്യുന്നത് പോലെയാണിത്. ഇത് ഇതുപോലെ കാണപ്പെടും:

സൗകര്യപ്രദമായി, നിലവിലുള്ള ഉപകരണങ്ങൾ ഉപയോഗിച്ച് ഇതെല്ലാം ചെയ്യാൻ കഴിയും. ഉദാഹരണത്തിന്, പെർഫ് റെക്കോർഡ് ഒരു നിശ്ചിത ആവൃത്തിയിൽ തന്നിരിക്കുന്ന സിപിയു കോർ പരിശോധിക്കുന്നു, കൂടാതെ യൂസർ സ്പേസും ലിനക്സ് കേർണലും ഉൾപ്പെടെ പ്രവർത്തിക്കുന്ന സിസ്റ്റത്തിലേക്കുള്ള കോളുകളുടെ ഒരു ഷെഡ്യൂൾ സൃഷ്ടിക്കാൻ കഴിയും. പ്രോഗ്രാമിന്റെ ഒരു ചെറിയ ഫോർക്ക് ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഈ റെക്കോർഡ് എടുത്ത് പ്രോസസ്സ് ചെയ്യാം ഫ്ലേംഗ്രാഫ് ബ്രെൻഡൻ ഗ്രെഗിൽ നിന്ന്, അത് സ്റ്റാക്ക് ട്രേസിന്റെ ക്രമം സംരക്ഷിക്കുന്നു. ഓരോ 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 ന് മുമ്പുള്ള cadvisor" പാറ്റേൺ കണ്ടെത്തുന്നു എന്നതാണ്. എന്താണ് ഇതിനർത്ഥം?

ഓരോ വരിയും ഒരു നിശ്ചിത സമയത്ത് ഒരു സിപിയു ട്രെയ്സ് ആണ്. ഒരു വരിയിലെ സ്റ്റാക്കിലെ ഓരോ കോളും ഒരു അർദ്ധവിരാമത്താൽ വേർതിരിച്ചിരിക്കുന്നു. വരികളുടെ മധ്യത്തിൽ സിസ്കാൽ എന്ന് വിളിക്കുന്നത് ഞങ്ങൾ കാണുന്നു: 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, ഇത് മെമ്മറി ഉപയോഗവും 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 ഉപയോഗത്തിന്റെ പ്രശ്നം, നെറ്റ്‌വർക്ക് സ്റ്റാക്കിൽ ലേറ്റൻസി ക്രമരഹിതമായി പ്രതിഫലിക്കുന്നത് ആരും ശ്രദ്ധിച്ചില്ല എന്ന് മാത്രം. കാഡ്‌വൈസർ പ്രതീക്ഷിച്ചതിലും കൂടുതൽ സിപിയു സമയം ചെലവഴിക്കുന്നതായി ശ്രദ്ധയിൽപ്പെട്ടു, പക്ഷേ ഇതിന് വലിയ പ്രാധാന്യം നൽകിയില്ല, കാരണം ഞങ്ങളുടെ സെർവറുകളിൽ ധാരാളം സിപിയു ഉറവിടങ്ങളുണ്ട്, അതിനാൽ പ്രശ്നം ശ്രദ്ധാപൂർവ്വം പഠിച്ചില്ല.

നെയിംസ്‌പെയ്‌സിലെ (കണ്ടെയ്‌നർ) മെമ്മറി ഉപയോഗം cgroups കണക്കിലെടുക്കുന്നു എന്നതാണ് പ്രശ്‌നം. ഈ cgroup-ലെ എല്ലാ പ്രക്രിയകളും പുറത്തുകടക്കുമ്പോൾ, ഡോക്കർ മെമ്മറി cgroup റിലീസ് ചെയ്യുന്നു. എന്നിരുന്നാലും, "മെമ്മറി" എന്നത് പ്രോസസ്സ് മെമ്മറി മാത്രമല്ല. പ്രോസസ്സ് മെമ്മറി തന്നെ ഇപ്പോൾ ഉപയോഗിക്കുന്നില്ലെങ്കിലും, മെമ്മറി സിഗ്രൂപ്പിൽ കാഷെ ചെയ്ത ഡെന്ററികളും ഐനോഡുകളും (ഡയറക്‌ടറിയും ഫയൽ മെറ്റാഡാറ്റയും) പോലുള്ള കാഷെ ചെയ്‌ത ഉള്ളടക്കങ്ങൾ കേർണൽ അസൈൻ ചെയ്യുന്നതായി കാണുന്നു. പ്രശ്ന വിവരണത്തിൽ നിന്ന്:

zombie cgroups: പ്രോസസ്സുകളില്ലാത്തതും ഇല്ലാതാക്കിയതും എന്നാൽ ഇപ്പോഴും മെമ്മറി അലോക്കേറ്റ് ചെയ്തിട്ടുള്ളതുമായ cgroups (എന്റെ കാര്യത്തിൽ, ഡെൻട്രി കാഷെയിൽ നിന്ന്, പക്ഷേ ഇത് പേജ് കാഷെ അല്ലെങ്കിൽ tmpfs എന്നിവയിൽ നിന്നും അനുവദിക്കാവുന്നതാണ്).

ഒരു cgroup സ്വതന്ത്രമാക്കുമ്പോൾ കാഷെയിലുള്ള എല്ലാ പേജുകളുടെയും കേർണലിന്റെ പരിശോധന വളരെ മന്ദഗതിയിലായിരിക്കും, അതിനാൽ അലസമായ പ്രക്രിയ തിരഞ്ഞെടുക്കുന്നു: ഈ പേജുകൾ വീണ്ടും ആവശ്യപ്പെടുന്നത് വരെ കാത്തിരിക്കുക, തുടർന്ന് മെമ്മറി ആവശ്യമുള്ളപ്പോൾ cgroup മായ്ക്കുക. ഈ സമയം വരെ, സ്ഥിതിവിവരക്കണക്കുകൾ ശേഖരിക്കുമ്പോൾ cgroup ഇപ്പോഴും കണക്കിലെടുക്കുന്നു.

പ്രകടനത്തിന്റെ കാഴ്ചപ്പാടിൽ, പ്രകടനത്തിനായി അവർ മെമ്മറി ത്യജിച്ചു: കുറച്ച് കാഷെ ചെയ്ത മെമ്മറി ഉപേക്ഷിച്ച് പ്രാരംഭ ക്ലീനപ്പ് വേഗത്തിലാക്കുന്നു. ഇത് കൊള്ളാം. കാഷെ ചെയ്ത മെമ്മറിയുടെ അവസാനഭാഗം കേർണൽ ഉപയോഗിക്കുമ്പോൾ, cgroup ഒടുവിൽ മായ്‌ക്കപ്പെടുന്നു, അതിനാൽ അതിനെ "ലീക്ക്" എന്ന് വിളിക്കാൻ കഴിയില്ല. നിർഭാഗ്യവശാൽ, തിരയൽ മെക്കാനിസത്തിന്റെ പ്രത്യേക നിർവ്വഹണം memory.stat ഈ കേർണൽ പതിപ്പിൽ (4.9), ഞങ്ങളുടെ സെർവറുകളിലെ വലിയ അളവിലുള്ള മെമ്മറിയുമായി ചേർന്ന്, ഏറ്റവും പുതിയ കാഷെ ചെയ്ത ഡാറ്റ പുനഃസ്ഥാപിക്കാനും cgroup zombies മായ്‌ക്കാനും കൂടുതൽ സമയമെടുക്കുമെന്നാണ് അർത്ഥമാക്കുന്നത്.

ഞങ്ങളുടെ ചില നോഡുകളിൽ വളരെയധികം സിഗ്രൂപ്പ് സോമ്പികൾ ഉണ്ടെന്ന് ഇത് മാറുന്നു, വായനയും ലേറ്റൻസിയും ഒരു സെക്കൻഡിൽ കവിഞ്ഞു.

കാഷെ മായ്‌ക്കുന്നത് കാഷെ ചെയ്‌ത zombie cgroup പേജുകൾ ഓണാക്കുകയും അവയും സ്വതന്ത്രമാക്കുകയും ചെയ്യുന്നതിനാൽ, ഹോസ്റ്റിലെ റീഡ് ലേറ്റൻസിയും നെറ്റ്‌വർക്ക് ലേറ്റൻസിയും ഉടനടി ഇല്ലാതാക്കുന്ന, സിസ്റ്റത്തിലുടനീളം ഡെന്ററി/ഇനോഡുകൾ കാഷെകൾ ഉടനടി സ്വതന്ത്രമാക്കുക എന്നതാണ് കാഡ്‌വൈസർ പ്രശ്‌നത്തിനുള്ള പ്രതിവിധി. ഇത് ഒരു പരിഹാരമല്ല, പക്ഷേ ഇത് പ്രശ്നത്തിന്റെ കാരണം സ്ഥിരീകരിക്കുന്നു.

പുതിയ കേർണൽ പതിപ്പുകളിൽ (4.19+) കോൾ പ്രകടനം മെച്ചപ്പെടുത്തിയതായി കണ്ടെത്തി memory.stat, അതിനാൽ ഈ കേർണലിലേക്ക് മാറുന്നത് പ്രശ്നം പരിഹരിച്ചു. അതേ സമയം, Kubernetes ക്ലസ്റ്ററുകളിലെ പ്രശ്‌നകരമായ നോഡുകൾ കണ്ടെത്താനും അവ ഭംഗിയായി വറ്റിക്കാനും റീബൂട്ട് ചെയ്യാനും ഞങ്ങൾക്ക് ഉപകരണങ്ങൾ ഉണ്ടായിരുന്നു. ഞങ്ങൾ എല്ലാ ക്ലസ്റ്ററുകളും കൂട്ടിയോജിപ്പിച്ചു, ആവശ്യത്തിന് ഉയർന്ന ലേറ്റൻസി ഉള്ള നോഡുകൾ കണ്ടെത്തി അവ റീബൂട്ട് ചെയ്തു. ശേഷിക്കുന്ന സെർവറുകളിൽ OS അപ്‌ഡേറ്റ് ചെയ്യാൻ ഇത് ഞങ്ങൾക്ക് സമയം നൽകി.

ചുരുക്കത്തിൽ

നൂറുകണക്കിന് മില്ലിസെക്കൻഡ് RX NIC ക്യൂ പ്രോസസ്സിംഗ് ഈ ബഗ് നിർത്തിയതിനാൽ, ഇത് ഒരേസമയം ചെറിയ കണക്ഷനുകളിൽ ഉയർന്ന ലേറ്റൻസിക്കും MySQL അഭ്യർത്ഥനകൾക്കും പ്രതികരണ പാക്കറ്റുകൾക്കും ഇടയിലുള്ള മിഡ്-കണക്ഷൻ ലേറ്റൻസിക്കും കാരണമായി.

Kubernetes പോലെയുള്ള ഏറ്റവും അടിസ്ഥാനപരമായ സിസ്റ്റങ്ങളുടെ പ്രകടനം മനസ്സിലാക്കുന്നതും പരിപാലിക്കുന്നതും, അവയെ അടിസ്ഥാനമാക്കിയുള്ള എല്ലാ സേവനങ്ങളുടെയും വിശ്വാസ്യതയ്ക്കും വേഗതയ്ക്കും നിർണ്ണായകമാണ്. നിങ്ങൾ പ്രവർത്തിപ്പിക്കുന്ന എല്ലാ സിസ്റ്റവും കുബർനെറ്റസ് പ്രകടന മെച്ചപ്പെടുത്തലുകളിൽ നിന്ന് പ്രയോജനം നേടുന്നു.

അവലംബം: www.habr.com