တစ်စက္ကန့်လျှင် JSON တောင်းဆိုမှု 1.2 သန်းကို ကိုင်တွယ်ရန် Linux optimization

HTTP တောင်းဆိုမှုများကို လုပ်ဆောင်ရန်အတွက် အမြင့်ဆုံးစွမ်းဆောင်ရည်ရရှိစေရန် Linux ပတ်၀န်းကျင်ကို ချိန်ညှိခြင်းတွင် အသေးစိတ်လမ်းညွှန်ချက်ကို ထုတ်ပြန်ထားပါသည်။ အဆိုပြုထားသောနည်းလမ်းများသည် Amazon EC2 ပတ်ဝန်းကျင်ရှိ libreactor library (4 vCPU) တွင် အခြေခံ၍ JSON ပရိုဆက်ဆာ၏စွမ်းဆောင်ရည်ကို တစ်စက္ကန့်လျှင် API တောင်းဆိုမှု 224 မှ kernel 2 မှ 4.14 သန်းအထိ တောင်းဆိုမှုနှုန်းဖြင့် Amazon Linux 1.2 ၏ စံဆက်တင်များအဖြစ် တိုးမြှင့်နိုင်စေခဲ့သည်။ ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ပြီးနောက် ဒုတိယ (436%) တိုးလာကာ တောင်းဆိုမှုများကို လုပ်ဆောင်ရာတွင် နှောင့်နှေးမှုကို 79% လျှော့ချပေးခဲ့သည်။ အဆိုပြုထားသောနည်းလမ်းများသည် nginx၊ Actix၊ Netty နှင့် Node.js အပါအဝင် အခြားသော http ဆာဗာများကို အသုံးပြုသောအခါတွင် libreactor နှင့် အလုပ်လုပ်ရာတွင် တိကျမှုမရှိပါ (၎င်းကိုအခြေခံသည့်ဖြေရှင်းချက်တွင် ပိုမိုကောင်းမွန်သောစွမ်းဆောင်ရည်ပြသသောကြောင့် libreactor ကို စမ်းသပ်မှုများတွင် အသုံးပြုခဲ့သည်)။

အခြေခံ ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ခြင်း-

• libreactor ကုဒ်ကို ကောင်းမွန်အောင်ပြုလုပ်ခြင်း။ Techempower kit မှ R18 ရွေးချယ်မှုကို အသုံးပြုပြီး CPU cores အရေအတွက်ကို ကန့်သတ်ရန် ကုဒ်ကို ဖယ်ရှားခြင်းဖြင့် ပိုမိုကောင်းမွန်အောင် ပြုလုပ်ထားသည် (ကောင်းမွန်အောင်လုပ်ဆောင်ခြင်းဖြင့် 25-27%)၊ GCC တွင် "-O3" ရွေးချယ်မှုများဖြင့် စုစည်းမှုပြုထားသည် (5-10% တိုးလာသည်) နှင့် "-march-native" (5-10%)၊ ခေါ်ဆိုမှုများကို read/write calls များကို recv/send (5-10%) နှင့် pthreads ကိုအသုံးပြုသောအခါ overhead (2-3%)၊ . ကုဒ်ပိုကောင်းအောင်ပြုလုပ်ပြီးနောက် အလုံးစုံစွမ်းဆောင်ရည်တိုးလာမှုသည် 55% ရှိပြီး ဖြတ်သန်းမှုပမာဏသည် 224k req/s မှ 347k req/s သို့ တိုးလာသည်။
• မှန်းဆလုပ်ဆောင်မှု အားနည်းချက်များကို ကာကွယ်ခြင်းအား ပိတ်ပါ။ kernel ကို loading လုပ်သောအခါ "nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off" ကိုအသုံးပြုခြင်းဖြင့် kernel သည် စွမ်းဆောင်ရည် 28% တိုးလာစေရန် ခွင့်ပြုပေးပြီး throughput သည် 347k req/s မှ 446k req/s သို့ တိုးလာသည်။ သီးခြားအားဖြင့်၊ “nospectre_v1” ( Spectre v1 + SWAPGS မှကာကွယ်မှု) သည် 1-2%, “nospectre_v2” ( Spectre v2 မှကာကွယ်မှု) - 15-20%, "pti=off" (Spectre v3/Meltdown)၊ - 6 %, "mds=off tsx_async_abort=off" (MDS/Zombieload နှင့် TSX Asynchronous Abort) - 6%. L1TF/Foreshadow (l1tf=flush)၊ iTLB multihit၊ Speculative Store Bypass နှင့် SRBDS တိုက်ခိုက်မှုများကို အကာအကွယ်ပေးရန်အတွက် ဆက်တင်များကို မပြောင်းလဲထားဘဲ စမ်းသပ်ထားသည့် ဖွဲ့စည်းမှုပုံစံနှင့် မဖြတ်တောက်ထားသောကြောင့် စွမ်းဆောင်ရည်ကို မထိခိုက်စေပါ (ဥပမာ၊ KVM သီးသန့်၊ nested virtualization နှင့် အခြား CPU မော်ဒယ်များ)။
• "auditctl -a never,task" ညွှန်ကြားချက်ကို အသုံးပြု၍ စာရင်းစစ်ခြင်းနှင့် စနစ်ခေါ်ဆိုမှု ပိတ်ဆို့ခြင်း ယန္တရားများကို ပိတ်ခြင်းနှင့် docker container ကို စတင်သောအခါ "--security-opt seccomp=unconfined" option ကို သတ်မှတ်ခြင်း။ အလုံးစုံ စွမ်းဆောင်ရည် တိုးလာမှုသည် 11% ဖြစ်ပြီး ဖြတ်သန်းမှု 446k req/s မှ 495k req/s သို့ တိုးလာသည်။
• ဆက်စပ် kernel မော်ဂျူးများကို ပြန်ဖွင့်ခြင်းဖြင့် iptables/netfilter ကို ပိတ်ခြင်း တိကျသောဆာဗာဖြေရှင်းချက်တွင်အသုံးမပြုသည့် firewall ကို disable လုပ်ရန်စိတ်ကူးကို nf_hook_slow function သည် execute ရန်အချိန်၏ 18% ယူကြောင်းအကဲဖြတ်ခြင်းဖြင့် ပရိုဖိုင်ရလဒ်များဖြင့် အချက်ပြခဲ့သည်။ nftables သည် iptables များထက်ပိုမိုထိရောက်စွာအလုပ်လုပ်ကြောင်းသတိပြုမိသော်လည်း Amazon Linux သည် iptables ကိုဆက်လက်အသုံးပြုသည်။ iptables များကို ပိတ်ပြီးနောက်၊ စွမ်းဆောင်ရည် 22% တိုးလာပြီး 495k req/s မှ 603k req/s သို့ တိုးလာသည်။
• ပရိုဆက်ဆာ ကက်ရှ်အသုံးပြုမှု၏ စွမ်းဆောင်ရည်ကို မြှင့်တင်ရန် မတူညီသော CPU core များကြားတွင် ကိုင်တွယ်သူများကို ရွှေ့ပြောင်းခြင်းကို လျှော့ချပါ။ ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ခြင်းအား CPU cores (CPU Pinning) နှင့် binding kernel network handlers (Receive Side Scaling) တို့မှတဆင့် ပေါင်းစပ်ထားသော libreactor လုပ်ငန်းစဉ်များအဆင့်တွင် နှစ်ခုစလုံးကို ပိုမိုကောင်းမွန်အောင်လုပ်ဆောင်ခဲ့ပါသည်။ ဥပမာအားဖြင့်၊ irqbalance ကို ပိတ်ထားပြီး CPU နှင့် တန်းစီနေသော ဆက်စပ်မှုကို /proc/irq/$IRQ/smp_affinity_list တွင် အတိအလင်းသတ်မှတ်ထားသည်။ libreactor လုပ်ငန်းစဉ်နှင့် အဝင်ပက်ကတ်များ၏ ကွန်ရက်တန်းစီခြင်းကို လုပ်ဆောင်ရန် တူညီသော CPU core ကိုအသုံးပြုရန်အတွက် SO_ATTACH_REUSEPORT_CBPF အလံကိုဖန်တီးသောအခါ SO_ATTACH_REUSEPORT_CBPF အလံကိုသတ်မှတ်ခြင်းဖြင့် ချိတ်ဆက်ထားသော စိတ်ကြိုက် BPF လက်ကိုင်ကိရိယာကို အသုံးပြုပါသည်။ အထွက်ပက်ကတ်များ၏ တန်းစီခြင်းကို CPU တွင် ချိတ်ရန်၊ ဆက်တင်များ /sys/class/net/eth0/queues/tx- ကို ပြောင်းလဲထားသည်။ /xps_cpus။ အလုံးစုံစွမ်းဆောင်ရည်တိုးလာမှုသည် 38% ရှိပြီး ဖြတ်သန်းမှု 603k req/s မှ 834k req/s သို့ တိုးလာသည်။
• ကြားဖြတ်ကိုင်တွယ်ခြင်းနှင့် မဲရုံအသုံးပြုခြင်းတို့ကို ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ခြင်း။ ENA ဒရိုက်ဗာရှိ adaptive-rx မုဒ်ကိုဖွင့်ပြီး sysctl net.core.busy_read ကို ကိုင်တွယ်အသုံးပြုခြင်းက စွမ်းဆောင်ရည် 28% တိုးလာသည် (ဖြတ်သန်းမှု 834k req/s မှ 1.06M req/s သို့ တိုးလာပြီး latency 361μs မှ 292μs သို့ လျော့နည်းသွားသည်)။
• ကွန်ရက်အစုအဝေးတွင် မလိုအပ်ဘဲ ပိတ်ဆို့ခြင်းကို ဖြစ်စေသော စနစ်ဝန်ဆောင်မှုများကို ပိတ်ခြင်း။ dhclient ကိုပိတ်ထားပြီး IP လိပ်စာကို ကိုယ်တိုင်သတ်မှတ်ခြင်းကို ပိတ်ထားခြင်းဖြင့် စွမ်းဆောင်ရည် 6% တိုးလာပြီး 1.06M req/s မှ 1.12M req/s သို့ တိုးလာသည်။ dhclient သည် စွမ်းဆောင်ရည်အပေါ်သက်ရောက်သည့်အကြောင်းရင်းမှာ raw socket ကိုအသုံးပြု၍ traffic analysis တွင်ဖြစ်သည်။
• လှည့်ပတ်လော့ခ်တိုက်ပွဲ။ sysctl “net.core.default_qdisc=noqueue” မှတဆင့် ကွန်ရက် stack အား "noqueue" မုဒ်သို့ ပြောင်းခြင်းနှင့် "tc qdisc အစားထိုး dev eth0 root mq" သည် စွမ်းဆောင်ရည် 2% တိုးလာကာ ပေးပို့မှု 1.12M req/s မှ 1.15M သို့ တိုးလာသည် လိုအပ်ချက်
• “ethtool -K eth0 gro off” ဟူသော အမိန့်ဖြင့် GRO (ယေဘုယျ လက်ခံခြင်း Offload) ကို ပိတ်ခြင်းနှင့် sysctl “net.ipv4.tcp_congestion_control=reno” ကို အသုံးပြု၍ ကုဗပိတ်ထိန်းချုပ်မှု အယ်လဂိုရီသမ်ကို reno ဖြင့် အစားထိုးခြင်းကဲ့သို့သော နောက်ဆုံးအသေးစား ပိုမိုကောင်းမွန်အောင် လုပ်ဆောင်မှုများ။ အလုံးစုံ ကုန်ထုတ်စွမ်းအား တိုးနှုန်းမှာ ၄ ရာခိုင်နှုန်းဖြစ်သည်။ ဖြတ်သန်းစီးဆင်းမှုသည် 4M req/s မှ 1.15M req/s သို့ တိုးလာသည်။

ပိုမိုကောင်းမွန်အောင်လုပ်ဆောင်ခဲ့သည့်အပြင်၊ ဆောင်းပါးတွင် မျှော်မှန်းထားသောစွမ်းဆောင်ရည်ကို တိုးမြင့်လာစေရန်မဖြစ်စေသောနည်းလမ်းများကိုလည်း ဆွေးနွေးထားသည်။ ဥပမာအားဖြင့်၊ အောက်ပါတို့သည် ထိရောက်မှုမရှိဟု ထင်မြင်လာပါသည်။

• ကွန်တိန်နာတစ်လုံးတွင် လည်ပတ်ခြင်းမှ သီးခြားလုပ်ဆောင်ခြင်းမှာ စွမ်းဆောင်ရည်မှာ ကွဲပြားခြင်းမရှိပါ။ writev ကို send ဖြင့် အစားထိုးခြင်း၊ epoll_wait တွင် အမြင့်ဆုံး ရလဒ်များကို တိုးမြှင့်ခြင်းနှင့် GCC ဗားရှင်းများနှင့် အလံများကို စမ်းသပ်ခြင်းတွင် အကျိုးသက်ရောက်မှု မရှိပါ (အကျိုးသက်ရောက်မှုသည် “-O3” နှင့် “-march-native” အလံများအတွက်သာ သိသာပါသည်။
• SCHED_FIFO နှင့် SCHED_RR အချိန်ဇယားများကို အသုံးပြု၍ Linux kernel ကို ဗားရှင်း 4.19 နှင့် 5.4 သို့ အဆင့်မြှင့်ခြင်း၊ sysctl kernel.sched_min_granularity_ns၊ kernel.sched_wakeup_granularity_ns၊ transparent_hugepages=clocktever နှင့် စွမ်းဆောင်ရည်ကို သက်ရောက်မှုမရှိပါ။
• ENA ဒရိုက်ဗာတွင်၊ Offload မုဒ်များ (ခွဲခြမ်းခွဲခြင်း၊ ဖြန့်ခွဲစုစည်းခြင်း၊ rx/tx checksum)၊ “-O3” အလံဖြင့် တည်ဆောက်ခြင်းနှင့် ena.rx_queue_size နှင့် ena.force_large_llq_header ဘောင်များကို အသုံးပြုခြင်းဖြင့် အကျိုးသက်ရောက်မှုမရှိပါ။
• ကွန်ရက်အစုအစည်းတွင် အပြောင်းအလဲများသည် စွမ်းဆောင်ရည်ကို မတိုးတက်ခဲ့ပါ။
  • IPv6 ကို ပိတ်ရန်- ipv6.disable=1
  • VLAN ကိုပိတ်ပါ- modprobe -rv 8021q
  • ပက်ကေ့ဂျ်ရင်းမြစ်စစ်ဆေးခြင်းကို ပိတ်ပါ။
    • net.ipv4.conf.all.rp_filter=0
    • net.ipv4.conf.eth0.rp_filter=0
    • net.ipv4.conf.all.accept_local=1 (အနုတ်လက္ခဏာသက်ရောက်မှု)
  • net.ipv4.tcp_sack = 0
  • net.ipv4.tcp_dsack=0
  • net.ipv4.tcp_mem/tcp_wmem/tcp_rmem
  • net.core.netdev_budget
  • net.core.dev_weight
  • net.core.netdev_max_backlog
  • net.ipv4.tcp_slow_start_after_idle=0
  • net.ipv4.tcp_moderate_rcvbuf=0
  • net.ipv4.tcp_timestamps=0
  • net.ipv4.tcp_low_latency = 1
  • SO_PRIORITY
  • TCP_NODELAY

  source: opennet.ru