လွန်ခဲ့သော နှစ်နှစ်ခန့်က Kubernetes ဆွေးနွေးထားပြီးသား တရားဝင် GitHub ဘလော့ဂ်တွင်။ ထိုအချိန်မှစ၍ ၎င်းသည် ဝန်ဆောင်မှုများကို ဖြန့်ကျက်ရန်အတွက် စံနည်းပညာတစ်ခု ဖြစ်လာခဲ့သည်။ ယခု Kubernetes သည် အတွင်းပိုင်းနှင့် အများသူငှာ ဝန်ဆောင်မှုများ၏ သိသာထင်ရှားသော အပိုင်းကို စီမံခန့်ခွဲပါသည်။ ကျွန်ုပ်တို့၏အစုအဖွဲ့များ ကြီးထွားလာကာ စွမ်းဆောင်ရည်လိုအပ်ချက်များ ပိုမိုတင်းကျပ်လာသည်နှင့်အမျှ Kubernetes ပေါ်ရှိ ဝန်ဆောင်မှုအချို့သည် အပလီကေးရှင်း၏ဝန်အားကြောင့် မရှင်းပြနိုင်သော တုံ့ပြန်ချိန်ကို ရံဖန်ရံခါကြုံတွေ့နေရသည်ကို သတိပြုမိလာသည်။

အခြေခံအားဖြင့်၊ အပလီကေးရှင်းများသည် 100ms သို့မဟုတ် ထို့ထက်ပိုသော ကျပန်းကွန်ရက် latency ကိုခံစားရပြီး အချိန်ကုန်ခြင်း သို့မဟုတ် ထပ်စမ်းခြင်းများ ဖြစ်ပေါ်စေပါသည်။ ဝန်ဆောင်မှုများသည် တောင်းဆိုမှုများကို 100ms ထက် ပိုမိုမြန်ဆန်စွာ တုံ့ပြန်နိုင်မည်ဟု မျှော်လင့်ထားသည်။ ဒါပေမယ့် ချိတ်ဆက်မှုကိုယ်တိုင်က အချိန်အများကြီးယူရင် ဒါက မဖြစ်နိုင်ပါဘူး။ သီးခြားအားဖြင့်၊ ကျွန်ုပ်တို့သည် မီလီစက္ကန့်များကြာသင့်သော MySQL queries များကို အလွန်လျင်မြန်စွာ တွေ့ရှိခဲ့ပြီး MySQL သည် မီလီစက္ကန့်အတွင်း ပြီးမြောက်ခဲ့သည်၊ သို့သော် တောင်းဆိုနေသော အပလီကေးရှင်း၏ ရှုထောင့်မှ တုံ့ပြန်မှုသည် 100 ms သို့မဟုတ် ထို့ထက်ပို၍ ကြာပါသည်။

Kubernetes ပြင်ပမှ ဖုန်းခေါ်ဆိုမှုမှ ထွက်လာသည့်တိုင် Kubernetes node နှင့် ချိတ်ဆက်သည့်အခါမှသာ ပြဿနာဖြစ်ပွားကြောင်း ချက်ချင်းသိလာရသည်။ ပြဿနာကို မျိုးပွားရန် အလွယ်ကူဆုံးနည်းလမ်းမှာ စမ်းသပ်မှုတစ်ခုဖြစ်သည်။ Vegetaမည်သည့်အတွင်းရေးဌာနမှ လုပ်ဆောင်သည့်၊ တိကျသော ဆိပ်ကမ်းတစ်ခုတွင် Kubernetes ဝန်ဆောင်မှုကို စမ်းသပ်ပြီး ကြာမြင့်ချိန်ကို မကြာခဏ မှတ်ပုံတင်ပါသည်။ ဤဆောင်းပါးတွင်၊ ဤပြဿနာ၏အကြောင်းရင်းကို ကျွန်ုပ်တို့ မည်သို့ခြေရာခံနိုင်သည်ကို လေ့လာကြည့်ပါမည်။

ကွင်းဆက်အတွင်း မလိုလားအပ်သော ရှုပ်ထွေးမှုများကို ဖယ်ရှားခြင်းသည် ကျရှုံးမှုကို ဖြစ်စေသည်။

တူညီသောဥပမာကိုပြန်ထုတ်ခြင်းဖြင့်၊ ကျွန်ုပ်တို့သည် ပြဿနာ၏အာရုံကိုကျဉ်းမြောင်းစေပြီး မလိုအပ်သောရှုပ်ထွေးမှုအလွှာများကိုဖယ်ရှားလိုပါသည်။ အစပိုင်းတွင်၊ Vegeta နှင့် Kubernetes pods များအကြား စီးဆင်းမှုတွင် ဒြပ်စင်များ အလွန်များသည်။ ပိုမိုနက်ရှိုင်းသော ကွန်ရက်ပြဿနာကို ဖော်ထုတ်ရန်၊ ၎င်းတို့ထဲမှ အချို့ကို ဖယ်ရှားရန် လိုအပ်သည်။

client (Vegeta) သည် အစုအဝေးရှိ မည်သည့် node နှင့် TCP ချိတ်ဆက်မှုကို ဖန်တီးပေးသည်။ Kubernetes သည် အသုံးပြုသော ထပ်ဆင့်ကွန်ရက် (လက်ရှိဒေတာစင်တာကွန်ရက်၏ထိပ်တွင်) အဖြစ် လုပ်ဆောင်သည်။ IPIPဆိုလိုသည်မှာ၊ ၎င်းသည် data center ၏ IP packets အတွင်းရှိ overlay network ၏ IP packet များကို ဖုံးအုပ်ထားသည်။ ပထမ node သို့ ချိတ်ဆက်သောအခါ၊ ကွန်ရက်လိပ်စာ ဘာသာပြန်ခြင်းကို လုပ်ဆောင်ပါသည်။ ကွန်ယက်လိပ်စာဘာသာပြန်ခြင်း (NAT) သည် Kubernetes node ၏ IP လိပ်စာနှင့် ပို့တ်ကို ထပ်ဆင့်ကွန်ရက်ရှိ IP လိပ်စာနှင့် ဆိပ်ကမ်းသို့ ဘာသာပြန်ဆိုရန် (အထူးသဖြင့်၊ အပလီကေးရှင်းနှင့် ပေါ့ဒ်)။ အဝင်ပက်ကတ်များအတွက်၊ လုပ်ဆောင်ချက်များ၏ ပြောင်းပြန်အစီအစဥ်ကို လုပ်ဆောင်သည်။ ၎င်းသည် ဝန်ဆောင်မှုများကို အသုံးချပြီး ရွှေ့ထားသောကြောင့် အဆက်မပြတ် အပ်ဒိတ်လုပ်ပြီး ပြောင်းလဲနေသော အခြေအနေများစွာနှင့် အစိတ်အပိုင်းများစွာပါရှိသော ရှုပ်ထွေးသောစနစ်တစ်ခုဖြစ်သည်။

အသုံးဝင်သည် tcpdump Vegeta စမ်းသပ်မှုတွင် TCP လက်ဆွဲခြင်း (SYN နှင့် SYN-ACK အကြား) နှောင့်နှေးမှုရှိသည်။ ဤမလိုအပ်သော ရှုပ်ထွေးမှုများကို ဖယ်ရှားရန် သင်သုံးနိုင်သည်။ hping3 SYN အစုံလိုက်များဖြင့် ရိုးရှင်းသော “pings” အတွက်။ တုံ့ပြန်မှုပက်ကတ်တွင် နှောင့်နှေးမှုရှိမရှိ စစ်ဆေးပြီးနောက် ချိတ်ဆက်မှုကို ပြန်လည်သတ်မှတ်ပါ။ ကျွန်ုပ်တို့သည် 100ms ထက်ကြီးသော ပက်ကေ့ဂျ်များကိုသာ စစ်ထုတ်နိုင်ပြီး Vegeta ၏ ကွန်ရက်အလွှာ 7 စမ်းသပ်မှုထက် ပြဿနာကို ပြန်လည်ထုတ်လုပ်ရန် ပိုမိုလွယ်ကူသောနည်းလမ်းကို ရယူနိုင်ပါသည်။ ဤသည်မှာ 30927ms ကြားကာလတွင် ဝန်ဆောင်မှု "node port" (10) တွင် 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 ရာနှင့်ချီသော စည်းမျဉ်းများထဲမှ အချို့ဖြစ်နိုင်ပါသလား။ သို့မဟုတ် ကွန်ရက်ပေါ်တွင် IPIP ဥမင်လိုဏ်ခေါင်းတင်ခြင်းဆိုင်ရာ ပြဿနာများ ရှိပါသလား။ ၎င်းကိုစစ်ဆေးရန်နည်းလမ်းတစ်ခုမှာ ၎င်းကိုဖယ်ရှားခြင်းဖြင့် စနစ်၏အဆင့်တိုင်းကိုစမ်းသပ်ရန်ဖြစ်သည်။ NAT နှင့် firewall logic ကို ဖယ်ရှားပြီး IPIP အပိုင်းကိုသာ ချန်ထားလျှင် ဘာဖြစ်နိုင်မည်နည်း။

ကံကောင်းထောက်မစွာ၊ စက်သည် ကွန်ရက်တစ်ခုတည်းတွင်ရှိပါက၊ Linux သည် IP ထပ်ဆင့်လွှာကို တိုက်ရိုက်ဝင်ရောက်ရန် လွယ်ကူစေသည်။

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 ping ဘယ်လိုသွားလဲ ကြည့်ရအောင်။

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 ဥမင်ဖြစ်နိုင်ပါသလား။ စမ်းသပ်မှုကို ပိုမိုရိုးရှင်းအောင် လုပ်ကြပါစို့။

ဤ host နှစ်ခုကြားတွင် packet အားလုံးကို ပို့ပါသလား။

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 ping တစ်ခုမှ တစ်ခုသို့ ပက်ကတ်တစ်ခုသို့ ပေးပို့သည့် Kubernetes node နှစ်ခုမှ အခြေအနေကို ရိုးရှင်းအောင် ပြုလုပ်ထားပါသည်။ ပစ်မှတ်အိမ်ရှင်သည် "ဆိုးသည်" (အခြားအရာများထက် အချို့က ပိုဆိုးသည်) ဆိုလျှင် latency ကိုမြင်နေသေးသည်။

ယခုနောက်ဆုံးမေးခွန်း- အဘယ်ကြောင့်နှောင့်နှေးမှုသည် kube-node ဆာဗာများတွင်သာ ဖြစ်ပွားသနည်း။ 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

ထို့နောက် ကျွန်ုပ်တို့သည် ယခင်ရင်းမြစ် kube-node မှ တူညီသောတောင်းဆိုမှုများကို ပြင်ပ host သို့ run ပါမည် (ping တွင် 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

latency packet ဖမ်းယူမှုများကို စစ်ဆေးခြင်းဖြင့်၊ ကျွန်ုပ်တို့သည် နောက်ထပ် အချက်အလက်အချို့ကို ရရှိခဲ့ပါသည်။ အတိအကျအားဖြင့်၊ ပေးပို့သူ (အောက်ခြေ) သည် ဤအချိန်ကုန်သွားသည်ကို မြင်သော်လည်း လက်ခံသူ (အပေါ်) သည် Delta ကော်လံ (စက္ကန့်ပိုင်းအတွင်း) ကို မမြင်ရပါ။

ထို့အပြင်၊ လက်ခံသူဘက်ခြမ်းရှိ TCP နှင့် ICMP ပက်ကေ့ခ်ျများ၏ အစီအစဥ်ကွာခြားချက်ကို ကြည့်ရှုပါက၊ ICMP ပက်ကေ့ခ်ျများသည် ၎င်းတို့ပေးပို့ခဲ့သည့် တူညီသောအစီအစဥ်အတိုင်း အမြဲရောက်ရှိသော်လည်း အချိန်ကွာခြားပါသည်။ တစ်ချိန်တည်းမှာပင်၊ TCP packets များသည် တစ်ခါတစ်ရံတွင် ကြားဝင်ပြီး အချို့မှာ ပိတ်မိနေပါသည်။ အထူးသဖြင့်၊ SYN packets များ၏ ports များကို စစ်ဆေးကြည့်လျှင် ၎င်းတို့သည် ပေးပို့သူဘက်တွင် အစဉ်လိုက်ရှိသော်လည်း လက်ခံသူဘက်တွင် မဟုတ်ပါ။

လုပ်ပုံလုပ်နည်းမှာ မသိမသာ ကွာခြားချက်တစ်ခုရှိပါတယ်။ ကွန်ရက်ကတ်များ ခေတ်မီဆာဗာများ (ကျွန်ုပ်တို့၏ဒေတာစင်တာရှိအရာများကဲ့သို့) TCP သို့မဟုတ် ICMP ပါရှိသော ပက်ကေ့ချ်များကို လုပ်ဆောင်သည်။ ပက်ကက်တစ်ခုရောက်လာသောအခါ၊ ကွန်ရက်အဒက်တာသည် "ချိတ်ဆက်မှုတစ်ခုစီကို ဟစ်ဟစ်စေသည်" ဟု ဆိုလိုသည်မှာ၊ ၎င်းသည် ချိတ်ဆက်မှုများကို တန်းစီရန်ကြိုးစားကာ တန်းစီတစ်ခုစီကို သီးခြားပရိုဆက်ဆာ အူတိုင်သို့ ပေးပို့သည်။ TCP အတွက်၊ ဤ hash တွင် source နှင့် destination IP လိပ်စာနှင့် port နှစ်ခုလုံးပါ၀င်သည်။ တစ်နည်းဆိုရသော် ချိတ်ဆက်မှုတစ်ခုစီကို hashed (ဖြစ်နိုင်ချေ) ကွဲပြားသည်။ ICMP အတွက်၊ ဆိပ်ကမ်းများမရှိသောကြောင့် IP လိပ်စာများကိုသာ hashed လုပ်ထားသည်။

နောက်ထပ်လေ့လာတွေ့ရှိချက်အသစ်- ဤကာလအတွင်း host နှစ်ခုကြားရှိ ဆက်သွယ်မှုအားလုံးတွင် ICMP နှောင့်နှေးမှုများကို ကျွန်ုပ်တို့တွေ့မြင်ရသော်လည်း TCP သည် မရှိပါ။ ၎င်းသည် ကျွန်ုပ်တို့အား RX တန်းစီ hashing နှင့် ဆက်စပ်နိုင်ဖွယ်ရှိကြောင်းကို ပြောပြသည်- တုံ့ပြန်မှုများပေးပို့ရာတွင်မဟုတ်ဘဲ RX packet များလုပ်ဆောင်ရာတွင် ပိတ်ဆို့ခြင်းမှာ သေချာပေါက်နီးပါးဖြစ်သည်။

၎င်းသည် ဖြစ်နိုင်သောအကြောင်းတရားများစာရင်းမှ ထုပ်ပိုးပေးပို့ခြင်းကို ဖယ်ရှားပေးပါသည်။ အချို့သော kube-node ဆာဗာများတွင် packet လုပ်ဆောင်ခြင်းပြဿနာသည် လက်ခံသည့်ဘက်တွင် ရှိနေကြောင်း ယခု ကျွန်ုပ်တို့သိပါသည်။

Linux kernel တွင် packet လုပ်ဆောင်ခြင်းကို နားလည်ခြင်း။

အချို့သော kube-node ဆာဗာများတွင် လက်ခံသူတွင် အဘယ်ကြောင့် ပြဿနာဖြစ်ပွားသည်ကို နားလည်ရန်၊ Linux kernel သည် packet များကို မည်သို့လုပ်ဆောင်သည်ကို လေ့လာကြည့်ကြပါစို့။

အရိုးရှင်းဆုံး သမားရိုးကျ အကောင်အထည်ဖော်မှုသို့ ပြန်သွားသောအခါ ကွန်ရက်ကတ်သည် ပက်ကတ်ကို လက်ခံရရှိပြီး ပေးပို့သည်။ နှောက်ယှက်သည်။ စီမံဆောင်ရွက်ရန်လိုအပ်သည့် အထုပ်တစ်ခုရှိနေသည့် Linux kernel။ kernel သည် အခြားအလုပ်များကို ရပ်တန့်ကာ၊ ကြားဖြတ်ကိုင်တွယ်သူထံ အကြောင်းအရာကို ပြောင်းကာ ပက်ကတ်ကို လုပ်ဆောင်ပြီးနောက် လက်ရှိလုပ်ဆောင်စရာများဆီသို့ ပြန်သွားပါသည်။

ဤအကြောင်းအရာပြောင်းခြင်းမှာ နှေးကွေးသည်- 10s များတွင် 90Mbps ကွန်ရက်ကတ်များတွင် latency သည် ထင်သာမြင်သာမရှိနိုင်သော်လည်း ခေတ်မီ 10G ကတ်များတွင် တစ်စက္ကန့်လျှင် အများဆုံး 15 သန်း packet နှုန်းဖြင့် သေးငယ်သော XNUMX-core ဆာဗာတစ်ခုစီ၏ core တစ်ခုစီသည် သန်းပေါင်းများစွာပြတ်တောက်နိုင်သည်။ တစ်စက္ကန့်ကို အကြိမ်ရေ။

အနှောင့်အယှက်များကို အဆက်မပြတ် ကိုင်တွယ်ဖြေရှင်းနိုင်ရန် လွန်ခဲ့သော နှစ်များစွာက Linux က ထည့်သွင်းခဲ့သည်။ NAPI: ခေတ်မီယာဉ်မောင်းများအားလုံး အသုံးပြုသည့် ကွန်ရက် API နှေးကွေးသောအမြန်နှုန်းဖြင့် kernel သည် ယခင်ပုံစံအတိုင်း ကွန်ရက်ကတ်မှ ကြားဖြတ်မှုများကို လက်ခံရရှိဆဲဖြစ်သည်။ အတိုင်းအတာထက် ကျော်လွန်သော ပက်ကတ်များ လုံလောက်စွာရောက်ရှိသည်နှင့်တစ်ပြိုင်နက်၊ kernel သည် နှောင့်ယှက်ခြင်းကို ရပ်တန့်လိုက်ပြီး ၎င်းအစား ကွန်ရက်အဒက်တာအား စတင်မဲဆွယ်ပြီး ပက်ကေ့ခ်ျများကို အပိုင်းလိုက် ကောက်ယူသည်။ လုပ်ငန်းစဉ်ကို softirq၊ ဆိုလိုသည်မှာ in ဆော့ဖ်ဝဲ၏ ဆက်စပ်မှု အနှောင့်အယှက်များ စနစ်ခေါ်ဆိုမှုများနှင့် ဟာ့ဒ်ဝဲများ နှောင့်ယှက်ပြီးနောက်၊ kernel (အသုံးပြုသူနေရာနှင့် ဆန့်ကျင်ဘက်) လည်ပတ်နေပြီဖြစ်သည်။

၎င်းသည် ပိုမိုမြန်ဆန်သော်လည်း မတူညီသောပြဿနာကို ဖြစ်စေသည်။ ပက်ကေ့ချ်များ များလွန်းပါက၊ ကွန်ရက်ကတ်မှ ပက်ကေ့ခ်ျများကို အချိန်တိုင်း စီမံဆောင်ရွက်ပေးနေသဖြင့် အသုံးပြုသူ နေရာလွတ် လုပ်ငန်းစဉ်များသည် အဆိုပါ စီတန်းများကို အမှန်တကယ် ရှင်းရန် အချိန်မရှိပါ (TCP ချိတ်ဆက်မှုများမှ ဖတ်ရှုခြင်း စသည်)။ နောက်ဆုံးတွင် တန်းစီမှုများ ပြည့်လာပြီး ပက်ကေ့ခ်ျများကို စတင်ချပေးပါသည်။ ချိန်ခွင်လျှာကိုရှာဖွေရန် ကြိုးပမ်းမှုတွင်၊ kernel သည် softirq ဆက်စပ်မှုတွင် လုပ်ဆောင်ခဲ့သော အများဆုံး ပက်ကတ်အရေအတွက်အတွက် ဘတ်ဂျက်တစ်ခု သတ်မှတ်သည်။ ဤဘတ်ဂျက်ကို ကျော်လွန်သွားသည်နှင့်၊ သီးခြားအစီအစဥ်တစ်ခု နိုးထလာပါသည်။ ksoftirqd (သူတို့ထဲက တစ်ယောက်ကို တွေ့လိမ့်မယ်။ ps per core) ပုံမှန် syscall/interrupt လမ်းကြောင်း၏ အပြင်ဘက်တွင် အဆိုပါ softirqs များကို ကိုင်တွယ်သည်။ အရင်းအမြစ်များကို မျှမျှတတခွဲဝေရန် ကြိုးပမ်းသည့် စံလုပ်ငန်းစဉ် အချိန်ဇယားကို အသုံးပြု၍ ဤစာတွဲကို စီစဉ်ထားပါသည်။

kernel သည် packets များကို မည်သို့လုပ်ဆောင်သည်ကို လေ့လာပြီးပါက၊ congestion ဖြစ်နိုင်ခြေအချို့ရှိကြောင်း သင်တွေ့မြင်နိုင်ပါသည်။ softirq ခေါ်ဆိုမှုများကို မကြာခဏနည်းပါးစွာ လက်ခံရရှိပါက၊ ပက်ကတ်များသည် ကွန်ရက်ကတ်ပေါ်ရှိ RX တန်းစီတွင် လုပ်ဆောင်ရန် အချိန်အတန်ကြာ စောင့်ဆိုင်းရမည်ဖြစ်ပါသည်။ ၎င်းမှာ ပရိုဆက်ဆာ core ကို ပိတ်ဆို့ထားသည့် အလုပ်အချို့ကြောင့် ဖြစ်နိုင်သည်၊ သို့မဟုတ် အခြားအရာတစ်ခုခုက core ကို 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 core တစ်ခုတည်းဖြင့် လုပ်ဆောင်သည်။ Linux မည်သို့အလုပ်လုပ်သည်ကိုနားလည်လိုပါက၊ ဤပက်ကေ့ဂျ်များကိုခြေရာခံရန်အတွက် မည်သည့်နေရာတွင် (CPU core) နှင့် (softirq၊ ksoftirqd) တို့ကို မည်သို့လုပ်ဆောင်နေသည်ကို သိရှိရန် အသုံးဝင်ပါသည်။

ယခုအချိန်သည် သင့်အား Linux kernel ကို အချိန်နှင့်တပြေးညီ စောင့်ကြည့်နိုင်စေမည့် ကိရိယာများကို အသုံးပြုရန် အချိန်ကျရောက်ပြီဖြစ်သည်။ ဒီမှာ ကျွန်တော်တို့ သုံးတယ်။ ဘီစီ. ဤကိရိယာအစုံသည် သင့်အား kernel တွင် မထင်မှတ်ထားသောလုပ်ဆောင်ချက်များကို ချိတ်တွဲကာ အဖြစ်အပျက်များကို ၎င်းတို့ကို လုပ်ဆောင်နိုင်ပြီး သင့်ထံ ရလဒ်ကို ပြန်ပေးနိုင်သည့် user-space Python ပရိုဂရမ်တွင် ကြားခံလုပ်ဆောင်သည့် C ပရိုဂရမ်ငယ်များကို ရေးသားခွင့်ပြုသည်။ kernel တွင် မထင်သလို လုပ်ဆောင်ချက်များကို ချိတ်ဆွဲခြင်းသည် ရှုပ်ထွေးသော ကိစ္စတစ်ခုဖြစ်သော်လည်း အသုံးဝင်မှုသည် အမြင့်ဆုံးလုံခြုံရေးအတွက် ဒီဇိုင်းထုတ်ထားပြီး စမ်းသပ်မှု သို့မဟုတ် ဖွံ့ဖြိုးတိုးတက်မှုပတ်ဝန်းကျင်တွင် အလွယ်တကူ ပြန်မရနိုင်သည့် ထုတ်လုပ်မှုဆိုင်ရာ ပြဿနာအမျိုးအစားများကို တိတိကျကျခြေရာခံရန် ဒီဇိုင်းထုတ်ထားသည်။

ဤနေရာတွင် အစီအစဉ်သည် ရိုးရှင်းပါသည်- kernel သည် ဤ ICMP pings များကို လုပ်ဆောင်ကြောင်း ကျွန်ုပ်တို့သိသည်၊ ထို့ကြောင့် kernel လုပ်ဆောင်ချက်တွင် ချိတ်တစ်ခု ထည့်လိုက်ပါမည်။ icmp_echoအဝင် ICMP ပဲ့တင်သံ တောင်းဆိုချက်ပက်ကတ်ကို လက်ခံပြီး ICMP ပဲ့တင်သံတုံ့ပြန်မှုကို စတင်သည်။ ဖော်ပြထားသည့် icmp_seq နံပါတ်ကို တိုးမြှင့်ခြင်းဖြင့် ပက်ကတ်တစ်ခုကို ခွဲခြားသတ်မှတ်နိုင်သည်။ hping3 ပိုမိုမြင့်မား။

ကုဒ် bcc ဇာတ်ညွှန်း ကြည့်ရတာ ရှုပ်ထွေးပေမယ့် ထင်သလောက် ကြောက်စရာတော့ မဟုတ်ပါဘူး။ လုပ်ဆောင်ချက် icmp_echo ပို့ဆောင်ပေးသည်။ struct sk_buff *skb: ဤသည်မှာ "ပဲ့တင်သံတောင်းဆိုမှု" ပါသည့် ပက်ကတ်တစ်ခုဖြစ်သည်။ အဲဒါကို ခြေရာခံနိုင်တယ်၊ အတွဲလိုက်ကို ဆွဲထုတ်နိုင်တယ်။ echo.sequence (၎င်းနှင့် နှိုင်းယှဉ်သည်။ icmp_seq hping3 ဖြင့် выше) ပြီးလျှင် user space သို့ ပို့ပါ။ လက်ရှိလုပ်ငန်းစဉ်အမည်/id ကိုဖမ်းယူရန်လည်း အဆင်ပြေပါသည်။ kernel သည် packet များကို လုပ်ဆောင်နေစဉ်တွင် ကျွန်ုပ်တို့ တိုက်ရိုက်တွေ့မြင်ရသော ရလဒ်များမှာ အောက်ပါအတိုင်းဖြစ်သည် ။

TGID PID လုပ်ငန်းစဉ်အမည် ICMP_SEQ 0 0 11 swapper/770 0 0 11 swapper/771 0 0 11 772 swapper/0 0 11 773 swapper/0 0 11 774 swapper/20041 20086 775 0the 0 11 776 0 swapper/0 11 777 0 0 swapper/11 778 4512 4542 spokes-report-s 779

ဤနေရာတွင် စကားစပ်မိကြောင်း သတိပြုသင့်သည်။ softirq စနစ်ခေါ်ဆိုမှုများပြုလုပ်သော လုပ်ငန်းစဉ်များသည် အမှန်တကယ်တွင် kernel သည် kernel ၏အခြေအနေတွင် packet များကို ဘေးကင်းစွာစီမံဆောင်ရွက်ပေးသည့် kernel ဖြစ်သောကြောင့် "လုပ်ငန်းစဉ်များ" အဖြစ် ပေါ်လာမည်ဖြစ်သည်။

ဤကိရိယာဖြင့် ကျွန်ုပ်တို့သည် နှောင့်နှေးမှုကိုပြသသည့် သီးခြား ပက်ကေ့ခ်ျများနှင့် သီးခြားလုပ်ငန်းစဉ်များကို ချိတ်ဆက်နိုင်ပါသည်။ 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 11mk1954 ** ir qd/89 76 ** 76ms 11 1955 ksoftirqd/ 79 76 ** 76ms 11 1956 ksoftirqd/69 76 ** 76ms 11 1957 ksoftirqd/59 76** (76ms) 11 1958 ksoftirqd/49 76 ** (76ms) 11 1959 39k (76 76ms) ** ksoft irqd/ 11 1960 ** (29ms) 76 76 ksoftirqd/11 1961 ** (19ms) -- 76 76 cadvisor 11 1962 9 cadvisor 10137 10436 2068 10137 ksoft 10436 ksoftirq 2069 qd/76 76 ** 11ms 2070 ၇၆ ksoftirqd/ 75 76 ** 76ms 11 2071 ksoftirqd/ 65 76 ** (76ms) 11 2072 ksoftirqd/ 55 76 ** (76ms) 11 2073 ksoftirqd/45 76 ** (76ms) (11ms) 2074 (35ms) ms ) 76 76 ksoftirqd/11 2075 ** (25ms)

ရလဒ်များက ကျွန်ုပ်တို့အား အရာများစွာကို ပြောပြသည်။ ပထမဦးစွာ၊ ဤပက်ကေ့ဂျ်များအားလုံးကို အကြောင်းအရာအားဖြင့် လုပ်ဆောင်ပါသည်။ ksoftirqd/11. ဆိုလိုသည်မှာ ဤစက်အတွဲများအတွက် ICMP packet များကို လက်ခံရရှိသည့်အဆုံးတွင် core 11 သို့ hashed လုပ်ထားသည်။ ယိုမှုများရှိသည့်အခါတိုင်း၊ စနစ်ခေါ်ဆိုမှု၏အကြောင်းအရာတွင် စီမံဆောင်ရွက်ထားသော ပက်ကေ့ခ်ျများရှိသည်ကိုလည်း ကျွန်ုပ်တို့တွေ့မြင်ရပါသည်။ cadvisor... ထိုအခါ ksoftirqd လုပ်ငန်းတာဝန်ကို လွှဲပြောင်းယူပြီး စုဆောင်းထားသော တန်းစီခြင်းကို လုပ်ဆောင်သည်- ပြီးနောက် စုဆောင်းထားသော ပက်ကေ့ခ်ျအရေအတွက် အတိအကျ cadvisor.

ချက်ခြင်းရှေ့ရောက်မှ နိစ္စဓူဝ အလုပ်ဖြစ်တယ်။ cadvisorပြဿနာတွင် သူပါဝင်ပတ်သက်မှုကို ဆိုလိုသည်။ ဖြစ်ချင်တော့ ရည်ရွယ်ချက်၊ cadvisor - "လည်ပတ်နေသောကွန်တိန်နာများ၏ အရင်းအမြစ်အသုံးပြုမှုနှင့် စွမ်းဆောင်ရည်လက္ခဏာများကို ခွဲခြမ်းစိတ်ဖြာပါ"

ကွန်တိန်နာများ၏ အခြားသော အသွင်အပြင်များကဲ့သို့၊ ၎င်းတို့အားလုံးသည် အလွန်အဆင့်မြင့်သည့် ကိရိယာများဖြစ်ပြီး အချို့သော အခြေအနေများတွင် စွမ်းဆောင်ရည်ဆိုင်ရာ ပြဿနာများကို ကြုံတွေ့ရမည်ဟု မျှော်လင့်နိုင်ပါသည်။

ပက်ကတ်တန်းစီခြင်းကို နှေးကွေးစေသော cadvisor သည် အဘယ်အရာလုပ်ဆောင်သနည်း။

ယခု ကျွန်ုပ်တို့သည် ပျက်စီးမှုဖြစ်ပွားပုံ၊ မည်သည့်ဖြစ်စဉ်ကို ဖြစ်စေသနည်း၊ မည်သည့် CPU ဖြစ်သည်ကို ကျွန်ုပ်တို့ နားလည်သဘောပေါက်နေပြီဖြစ်သည်။ ခက်ခဲသောပိတ်ဆို့ခြင်းကြောင့် Linux kernel တွင် အချိန်ဇယားဆွဲရန် အချိန်မရှိသည်ကို ကျွန်ုပ်တို့မြင်ရပါသည်။ ksoftirqd. ပက်ကေ့ချ်များကို ဆက်စပ်၍ လုပ်ဆောင်သည်ကို ကျွန်ုပ်တို့မြင်သည်။ cadvisor. ထိုသို့ယူဆခြင်းသည် ယုတ္တိရှိသည်။ cadvisor နှေးကွေးသော syscall ကိုဖွင့်လိုက်သည်၊ ထို့နောက် ထိုအချိန်တွင် စုဆောင်းထားသော ပက်ကေ့ခ်ျအားလုံးကို စီမံဆောင်ရွက်သည်-

ဒါက သီအိုရီတစ်ခုပါ၊ ဒါပေမယ့် ဘယ်လိုစမ်းသပ်မလဲ။ ကျွန်ုပ်တို့လုပ်နိုင်သည်မှာ ဤလုပ်ငန်းစဉ်တစ်လျှောက်လုံး CPU core ကိုခြေရာခံပါ၊ ဘတ်ဂျတ်ထက် packet အရေအတွက်များသွားပြီး ksoftirqd ကိုခေါ်သည့်အချက်ကိုရှာပါ၊ ထို့နောက်ထိုအမှတ်မတိုင်မီလေးတင် CPU core တွင်မည်သည့်အရာကိုအတိအကျလုပ်ဆောင်ထားသည်ကိုကြည့်ရန်နောက်သို့အနည်းငယ်ပြန်ကြည့်ပါ။ . CPU ကို မီလီစက္ကန့်အနည်းငယ်တိုင်း ဓာတ်မှန်ရိုက်သလိုပါပဲ။ ၎င်းသည်ဤကဲ့သို့သောပုံရသည်-

အဆင်ပြေစွာ၊ ဤအရာအားလုံးကို လက်ရှိကိရိယာများဖြင့် လုပ်ဆောင်နိုင်သည်။ ဥပမာအားဖြင့်, perf မှတ်တမ်း သတ်မှတ်ထားသော ကြိမ်နှုန်းဖြင့် ပေးထားသည့် CPU core ကို စစ်ဆေးပြီး အသုံးပြုသူနေရာနှင့် Linux kernel နှစ်ခုလုံးအပါအဝင် လည်ပတ်နေသော စနစ်သို့ ခေါ်ဆိုမှုများ အချိန်ဇယားကို ထုတ်ပေးနိုင်သည်။ သင်သည် ဤမှတ်တမ်းကို ယူ၍ ပရိုဂရမ်၏ ခက်ရင်းငယ်ကို အသုံးပြု၍ ၎င်းကို လုပ်ဆောင်နိုင်သည်။ FlameGraph stack trace ၏အစီအစဥ်ကိုထိန်းသိမ်းထားသည့် Brendan Gregg မှ။ ကျွန်ုပ်တို့သည် 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

ဤနေရာတွင်အရာများစွာရှိပါသည်၊ သို့သော်အဓိကအရာမှာ ICMP tracer တွင်အစောပိုင်းကကျွန်ုပ်တို့တွေ့မြင်ခဲ့သော "cadvisor before ksoftirqd" ပုံစံကိုကျွန်ုပ်တို့တွေ့ရှိခြင်းဖြစ်သည်။ ဘာကိုဆိုလိုတာလဲ?

စာကြောင်းတစ်ခုစီသည် အချိန်ကာလတစ်ခုတွင် CPU ခြေရာခံသည်။ လိုင်းတစ်ခုပေါ်ရှိ stack down ခေါ်ဆိုမှုတစ်ခုစီကို semicolon ဖြင့် ပိုင်းခြားထားသည်။ မျဉ်းများအလယ်တွင် syscall ဟုခေါ်သည်- read(): .... ;do_syscall_64;sys_read; .... ဒါကြောင့် cadvisor က system call မှာ အချိန်အများကြီးကုန်တယ်။ read()functions များနှင့်ဆက်စပ် mem_cgroup_* (ခေါ်ဆိုမှုအစုစု၏ထိပ်/လိုင်းအဆုံး)။

ခေါ်ဆိုမှုတွင် မည်သည့်အရာကို အတိအကျဖတ်နေသနည်းဆိုသည်ကို ကြည့်ရန် အဆင်မပြေသောကြောင့် ပြေးကြည့်ကြပါစို့ strace ပြီးလျှင် 100 ms ထက် ပိုရှည်သော စနစ်ခေါ်ဆိုမှုများကို cadvisor က မည်သို့လုပ်ဆောင်သည်ကို ကြည့်ကြပါစို့။

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 ကန့်သတ်ချက်များကိုပြသသည့် (Docker ၏အရင်းအမြစ် သီးခြားခွဲထုတ်ခြင်းနည်းပညာ)။ ကွန်တိန်နာများအတွက် အရင်းအမြစ်အသုံးပြုမှုအချက်အလက်ကို ရယူရန် cadvisor တူးလ်က ဤဖိုင်ကို မေးမြန်းသည်။ ၎င်းသည် kernel သို့မဟုတ် cadvisor သည် မမျှော်လင့်ထားသော တစ်စုံတစ်ရာကို လုပ်ဆောင်နေခြင်း ဟုတ်မဟုတ် စစ်ဆေးကြပါစို့။

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

ယခု ကျွန်ုပ်တို့သည် bug ကို မျိုးပွားနိုင်ပြီး Linux kernel သည် ရောဂါဗေဒနှင့် ရင်ဆိုင်နေရကြောင်း နားလည်ပါသည်။

စာဖတ်ခြင်းလုပ်ဆောင်မှုသည် အဘယ်ကြောင့် နှေးကွေးသနည်း။

ဤအဆင့်တွင်၊ အလားတူပြဿနာများအကြောင်း အခြားအသုံးပြုသူများထံမှ မက်ဆေ့ချ်များကို ရှာဖွေရန် ပိုမိုလွယ်ကူသည်။ ထွက်လာသည့်အတိုင်း၊ cadvisor tracker တွင် ဤ bug ကိုအစီရင်ခံထားသည်။ CPU အလွန်အကျွံအသုံးပြုမှုပြဿနာ၊ latency သည် network stack တွင် ကျပန်းထင်ဟပ်နေသည်ကိုလည်း မည်သူမျှ သတိမထားမိဘဲ ဖြစ်နေပါသည်။ cadvisor သည် မျှော်လင့်ထားသည်ထက် CPU အချိန်ပိုသုံးစွဲနေသည်ကို အမှန်ပင် သတိပြုမိသော်လည်း ကျွန်ုပ်တို့၏ဆာဗာများတွင် CPU အရင်းအမြစ်များစွာရှိသောကြောင့် ပြဿနာကို ဂရုတစိုက်မလေ့လာခဲ့ပါ။

ပြဿနာမှာ cgroups များသည် namespace (container) အတွင်း မှတ်ဉာဏ်အသုံးပြုမှုကို ထည့်သွင်းစဉ်းစားခြင်းဖြစ်သည်။ ဤ cgroup ထွက်ပေါက်ရှိ လုပ်ငန်းစဉ်များအားလုံးတွင်၊ Docker သည် memory cgroup ကို ထုတ်ပေးသည်။ သို့သော် “မှတ်ဉာဏ်” သည် လုပ်ငန်းစဉ်မှတ်ဉာဏ်မျှသာ မဟုတ်ပါ။ လုပ်ငန်းစဉ်မှတ်ဉာဏ်ကိုယ်တိုင်က အသုံးမပြုတော့သော်လည်း၊ kernel သည် memory cgroup တွင် ကက်ရှ်လုပ်ထားသည့် dentries နှင့် inodes (directory and file metadata) ကဲ့သို့သော ကက်ရှ်အကြောင်းအရာများကို kernel က သတ်မှတ်ပေးနေဆဲဖြစ်ပုံရသည်။ ပြဿနာဖော်ပြချက်မှ

zombie cgroups- လုပ်ငန်းစဉ်များမရှိ၍ ဖျက်ထားသော cgroups များဖြစ်သော်လည်း memory ခွဲဝေထားဆဲဖြစ်သည် (ကျွန်ုပ်၏ကိစ္စတွင်၊ dentry cache မှ၊ ဒါပေမယ့် page cache သို့မဟုတ် tmpfs မှလည်း ခွဲဝေပေးနိုင်ပါတယ်)။

cgroup ကို လွှတ်လိုက်သောအခါ ကက်ရှ်ရှိ စာမျက်နှာအားလုံး၏ kernel ၏ စစ်ဆေးမှုသည် အလွန်နှေးကွေးနိုင်သည်၊ ထို့ကြောင့် ပျင်းရိသည့် လုပ်ငန်းစဉ်ကို ရွေးချယ်လိုက်သည်- ဤစာမျက်နှာများကို ထပ်မံတောင်းဆိုလာသည်အထိ စောင့်ပါ၊ ထို့နောက် မှတ်ဉာဏ် အမှန်တကယ် လိုအပ်လာသောအခါ နောက်ဆုံးတွင် cgroup ကို ရှင်းလင်းပါ။ ဤအချက်အထိ၊ စာရင်းဇယားများစုဆောင်းသည့်အခါ cgroup ကိုထည့်သွင်းစဉ်းစားနေဆဲဖြစ်သည်။

စွမ်းဆောင်ရည်ရှုထောင့်မှကြည့်လျှင် ကက်ရှ်မမ်မိုရီအချို့ကို ချန်ထားခြင်းဖြင့် ကနဦးရှင်းလင်းမှုကို အရှိန်မြှင့်ပေးသည်။ ဒါကအဆင်ပြေပါတယ်။ kernel သည် ကက်ရှ်မမ်မိုရီ၏နောက်ဆုံးကိုအသုံးပြုသောအခါ၊ cgroup ကိုနောက်ဆုံးတွင်ရှင်းလင်းသွားသည်၊ ထို့ကြောင့်၎င်းကို "leak" ဟုခေါ်ဆို၍မရပါ။ ကံမကောင်းစွာပဲ, တိကျတဲ့ရှာဖွေရေးယန္တရား၏အကောင်အထည်ဖော်မှု memory.stat ဤ kernel ဗားရှင်း (4.9) တွင် ကျွန်ုပ်တို့၏ဆာဗာများရှိ မမ်မိုရီပမာဏများစွာဖြင့် ပေါင်းစပ်ထားသောကြောင့် နောက်ဆုံးပေါ် ကက်ရှ်ဒေတာများကို ပြန်လည်ရယူရန်နှင့် cgroup ဖုတ်ကောင်များကို ရှင်းလင်းရန် အချိန်ပိုကြာသည်ဟု ဆိုလိုသည်။

ကျွန်ုပ်တို့၏ node အချို့တွင် cgroup ဖုတ်ကောင်များစွာရှိသဖြင့် ဖတ်ရှုပြီး latency သည် တစ်စက္ကန့်ကို ကျော်လွန်သွားပါသည်။

cadvisor ပြဿနာအတွက် ဖြေရှင်းနည်းမှာ system တစ်လျှောက်လုံး dentries/inodes ကက်ရှ်များကို ချက်ခြင်းဖယ်ရှားရန်ဖြစ်ပြီး၊ ကက်ရှ်ကိုရှင်းလင်းခြင်းသည် ကက်ရှ်ဖုတ်ကောင် cgroup စာမျက်နှာများကို ရှင်းထုတ်ပြီး ၎င်းတို့ကိုလည်း လွတ်မြောက်စေသောကြောင့် စနစ်တစ်ခုလုံးတွင် read latency နှင့် network latency တို့ကို ချက်ချင်းဖယ်ရှားပေးပါသည်။ ဒါက ဖြေရှင်းချက်မဟုတ်ပေမယ့် ပြဿနာရဲ့အကြောင်းရင်းကို အတည်ပြုပါတယ်။

အသစ်သော kernel ဗားရှင်းများ (4.19+) တွင် ခေါ်ဆိုမှုစွမ်းဆောင်ရည် ပိုမိုကောင်းမွန်လာကြောင်း တွေ့ရှိရပါသည်။ memory.statထို့ကြောင့် ဤ kernel သို့ပြောင်းခြင်းက ပြဿနာကို ဖြေရှင်းပေးခဲ့သည်။ တစ်ချိန်တည်းမှာပင်၊ Kubernetes အစုအဝေးများတွင် ပြဿနာရှိသော ကုဒ်များကို ရှာဖွေရန် ကိရိယာများ ရှိပြီး ၎င်းတို့ကို လှပစွာ ဖယ်ရှားပြီး ၎င်းတို့ကို ပြန်လည်စတင်ပါ။ ကျွန်ုပ်တို့သည် အစုအဝေးအားလုံးကို စုစည်းပြီး လုံလောက်သော latency မြင့်မားသော ဆုံမှတ်များကို တွေ့ရှိပြီး ၎င်းတို့ကို ပြန်လည်စတင်ခဲ့သည်။ ၎င်းသည် ကျန်ရှိသောဆာဗာများတွင် OS ကို အပ်ဒိတ်လုပ်ရန် အချိန်ပေးခဲ့သည်။

တက်ကဉျြးခြုပျ

ဤချွတ်ယွင်းချက်သည် RX NIC တန်းစီခြင်းကို ရာနှင့်ချီသော မီလီစက္ကန့်များအတွက် စီတန်းလုပ်ဆောင်ခြင်းကို ရပ်တန့်သွားသောကြောင့်၊ ၎င်းသည် MySQL တောင်းဆိုချက်များနှင့် တုံ့ပြန်မှုပက်ကတ်များကြားကဲ့သို့သော တိုတောင်းသောချိတ်ဆက်မှုများနှင့် အလယ်အလတ်ကြာချိန်ကြာချိန်နှစ်ခုလုံးကို တပြိုင်နက်တည်းဖြစ်ပေါ်စေသည်။

Kubernetes ကဲ့သို့သော အခြေခံအကျဆုံးစနစ်များ၏ စွမ်းဆောင်ရည်ကို နားလည်ခြင်းနှင့် ထိန်းသိမ်းခြင်းသည် ၎င်းတို့အပေါ်အခြေခံသည့် ဝန်ဆောင်မှုအားလုံး၏ ယုံကြည်စိတ်ချရမှုနှင့် မြန်နှုန်းအတွက် အရေးကြီးပါသည်။ Kubernetes စွမ်းဆောင်ရည်မြှင့်တင်မှုများမှ သင်လုပ်ဆောင်သည့် စနစ်တိုင်းတွင် အကျိုးကျေးဇူးများ။

source: www.habr.com