په هره ثانیه کې د 1.2 ملیون JSON غوښتنې اداره کولو لپاره لینکس اصلاح کول

د HTTP غوښتنو پروسس کولو لپاره اعظمي فعالیت ترلاسه کولو لپاره د لینکس چاپیریال تنظیم کولو په اړه مفصل لارښود خپور شوی. وړاندیز شوي میتودونو دا امکان رامینځته کړی چې د ایمیزون EC2 چاپیریال (4 vCPU) کې د لیبریکټر کتابتون پراساس د JSON پروسیسر فعالیت ته وده ورکړي له 224 زره API غوښتنو څخه په هره ثانیه کې د ایمیزون لینکس 2 معیاري ترتیباتو سره د کرنل 4.14 څخه تر 1.2 ملیون غوښتنو پورې. د اصلاح کولو وروسته دویم (د 436٪ زیاتوالی)، او همدارنګه د 79٪ لخوا د پروسس غوښتنو کې ځنډ کمولو المل شو. وړاندیز شوي میتودونه د لیبریکتور لپاره ځانګړي ندي او کار کوي کله چې نور http سرورونه کاروي ، پشمول د nginx, Actix, Netty او Node.js (لیبریکتور په ازموینو کې کارول شوی ځکه چې د دې پراساس حل غوره فعالیت ښودلی).

په هره ثانیه کې د 1.2 ملیون JSON غوښتنې اداره کولو لپاره لینکس اصلاح کول

اساسي اصلاح کول:

  • د لیبریکټر کوډ اصلاح کول. د ټیکیم پاور کټ څخه د R18 اختیار د اساس په توګه کارول شوی و ، کوم چې د CPU کورونو شمیر محدودولو لپاره د کوډ په لرې کولو سره ښه شوی و (اصلاح کول اجازه ورکړل شوې د 25-27٪ لخوا کار ګړندی کړي) ، په GCC کې د "-O3" اختیارونو سره راټولول (د 5-10٪ زیاتوالی) او "-march-native" (5-10٪)، د لوستلو / لیکلو زنګونه د recv/send (5-10٪) سره ځای په ځای کول او د پیټریډ کارولو پر مهال د سر کمول (2-3٪) . د کوډ د اصلاح کولو وروسته د ټولیز فعالیت زیاتوالی 55٪ و، او له 224k غوښتنه/s څخه 347k غوښتنه/s ته زیاتوالی راغلی.
  • د اټکلي اعدام زیانونو پروړاندې محافظت غیر فعال کړئ. د پیرامیټرونو په کارولو سره "nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off" کله چې د کرنل بار کولو اجازه ورکړل شوه چې فعالیت 28٪ ته لوړ کړي، او د 347k req/s څخه 446k req/s ته زیاتوالی ومومي. په جلا توګه، د پیرامیټر "nospectre_v1" څخه زیاتوالی (د سپیکٹر v1 + SWAPGS څخه محافظت) 1-2٪، "nospectre_v2" (د سپیکٹر v2 څخه محافظت) - 15-20٪، "pti=off" (Spectre v3/Meltdown) - 6٪، "mds=off tsx_async_abort=off" (MDS/Zombieload او TSX غیر متناسب بند) - 6٪. د L1TF/Foreshadow (l1tf=flush)، iTLB ملټي هیټ، د قیاس پلورنځي بای پاس او SRBDS بریدونو په وړاندې د محافظت لپاره تنظیمات بدل شوي ندي، کوم چې په فعالیت اغیزه نه کوي ځکه چې دوی د ازمول شوي ترتیب سره نه وصل شوي (د مثال په توګه، د KVM لپاره ځانګړي، nested) مجازی کول او نور د CPU ماډلونه).
  • د "auditctl -a never,task" کمانډ په کارولو سره د پلټنې او سیسټم کال بلاک کولو میکانیزمونو غیر فعال کول او د ډاکر کانټینر پیل کولو پرمهال د "--security-opt seccomp=unconfined" اختیار مشخص کول. په ټولیز ډول د فعالیت زیاتوالی 11٪ و، او د 446k غوښتنه/s څخه 495k غوښتنې/s ته زیاتوالی راغلی.
  • د اړونده کرنل ماډلونو له پورته کولو سره د iptables/netfilter غیر فعال کول. د فایر وال غیر فعال کولو نظر ، کوم چې په ځانګړي سرور حل کې نه و کارول شوی ، د پایلو پروفایل کولو لخوا هڅول شوی و ، د دې قضاوت کولو سره چې د nf_hook_slow فنکشن د اجرا کولو لپاره 18٪ وخت نیولی. دا یادونه وشوه چې nftables د iptables په پرتله ډیر اغیزمن کار کوي، مګر ایمیزون لینکس د iptables کارولو ته دوام ورکوي. د iptables غیر فعال کولو وروسته، د فعالیت زیاتوالی 22٪ و، او د 495k req/s څخه 603k req/s ته زیاتوالی راغلی.
  • د پروسیسر کیچ کارولو موثریت ته وده ورکولو لپاره د مختلف CPU کورونو ترمینځ د هینډلرونو مهاجرت کم شوی. اصلاح کول دواړه د CPU کور (CPU پنینګ) ته د پابند لیبریکټر پروسې په کچه او د کرنل شبکې هینډلرونو (د اړخ سکیلینګ ترلاسه کولو) د پننګ کولو له لارې ترسره شوي. د مثال په توګه، irqbalance غیر فعال شوی و او CPU ته د قطار تړاو په ښکاره ډول په /proc/irq/$IRQ/smp_affinity_list کې ټاکل شوی و. د لیبریکټر پروسې پروسس کولو لپاره د ورته CPU کور کارولو لپاره او د راتلونکو پاکټونو شبکې کتار لپاره، یو دودیز BPF هینډلر کارول کیږي، د SO_ATTACH_REUSEPORT_CBPF بیرغ په ترتیب کولو سره وصل شوی کله چې ساکټ رامینځته کوي. CPU ته د وتلو پاکټونو قطارونو تړلو لپاره، ترتیبات /sys/class/net/eth0/queues/tx- بدل شوي /xps_cpus. په ټولیزه توګه د فعالیت زیاتوالی 38٪ و، او د 603k غوښتنه/s څخه 834k غوښتنه/s ته زیاتوالی راغلی.
  • د مداخلې اداره کولو او د رایې ورکولو کارولو اصلاح کول. په ENA ډرایور کې د انډول-rx حالت فعالول او د sysctl net.core.busy_read د چلولو فعالیت د 28٪ لخوا زیات شوی (د 834k req/s څخه 1.06M req/s ته زیات شوی، او ځنډ له 361μs څخه 292μs ته راټیټ شوی).
  • د سیسټم خدماتو غیر فعال کول چې د شبکې سټیک کې د غیر ضروري بلاک کولو لامل کیږي. د dhclient غیر فعال کول او په لاسي ډول د IP پته تنظیم کول د 6٪ فعالیت زیاتوالي لامل شوي او له 1.06M req/s څخه 1.12M req/s ته زیاتوالی موندلی. هغه دلیل چې dhclient په فعالیت اغیزه کوي د خام ساکټ په کارولو سره د ترافیک تحلیل کې دی.
  • د سپن لاک سره مبارزه. د شبکې سټیک د sysctl "net.core.default_qdisc=noqueue" او "tc qdisc ځای په ځای dev eth0 root mq" له لارې "noqueue" حالت ته بدلول د 2٪ فعالیت زیاتوالي لامل شوی، او د 1.12M req/s څخه 1.15M ته زیاتوالی راغلی. غوښتنې
  • وروستني کوچني اصلاحونه، لکه د "ethtool -K eth0 gro off" کمانډ سره د GRO غیر فعال کول (Generic Receive Offload) او د sysctl "net.ipv4.tcp_congestion_control=reno" په کارولو سره د رینو سره د کیوبک کنجشن کنټرول الګوریتم ځای په ځای کول. په ټولیزه توګه د تولید زیاتوالی 4٪ وه. له 1.15M req/s څخه 1.2M req/s ته زیاتوالی.

د اصلاح کولو سربیره چې کار یې کړی، مقاله د هغو میتودونو په اړه هم بحث کوي چې د متوقع فعالیت زیاتوالي لامل نه شوي. د مثال په توګه، لاندې غیر موثر ثابت شوي:

  • په جلا توګه د لیبریکټر چلول په کانټینر کې د چلولو څخه په فعالیت کې توپیر نه درلود. د رایټیو ځای په ځای کول د لیږلو سره، په ایپل_ویټ کې د maxevents زیاتول، او د GCC نسخو او بیرغونو سره تجربه کول هیڅ اغیزه نلري (اثر یوازې د "-O3" او "-march-native" بیرغونو لپاره د پام وړ و).
  • د لینکس کرنل د 4.19 او 5.4 نسخو ته پورته کول، د SCHED_FIFO او SCHED_RR مهالویشونو په کارولو سره، د sysctl kernel.sched_min_granularity_ns، kernel.sched_wakeup_granularity_ns، شفاف_hugepages=never,tsk=tskew=1 په فعالیت اغیزه نه کوي.
  • په ENA ډرایور کې، د آفلوډ حالتونو فعالول (سیګمینټیشن، سکریټر-ګادر، rx/tx چیکسم)، د "-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

    سرچینه: opennet.ru

Add a comment