Mwongozo wa kina umechapishwa kuhusu kurekebisha mazingira ya Linux ili kufikia utendakazi wa juu zaidi wa kuchakata maombi ya HTTP. Mbinu zilizopendekezwa zilifanya iwezekane kuongeza utendakazi wa kichakataji cha JSON kulingana na maktaba ya libreactor katika mazingira ya Amazon EC2 (4 vCPU) kutoka kwa maombi elfu 224 ya API kwa sekunde na mipangilio ya kawaida ya Amazon Linux 2 yenye kernel 4.14 hadi maombi milioni 1.2 kwa kila pili baada ya uboreshaji (ongezeko la 436%), na pia ilisababisha kupunguzwa kwa ucheleweshaji wa maombi ya usindikaji kwa 79%. Mbinu zilizopendekezwa si mahususi kwa libreactor na hufanya kazi wakati wa kutumia seva zingine za http, ikiwa ni pamoja na nginx, Actix, Netty na Node.js (libreactor ilitumika katika majaribio kwa sababu suluhu kulingana nayo ilionyesha utendaji bora).
Uboreshaji msingi:
- Kuboresha msimbo wa kibreactor. Chaguo la R18 kutoka kwa kifurushi cha Techempower lilitumika kama msingi, ambalo liliboreshwa kwa kuondoa msimbo ili kupunguza idadi ya cores za CPU zinazotumiwa (uboreshaji uliruhusu kuharakisha kazi kwa 25-27%), kukusanyika katika GCC na chaguzi za "-O3" (ongezeko la 5-10%) na "-march-native" (5-10%), ikibadilisha simu za kusoma/kuandika na recv/send (5-10%) na kupunguza vichwa vya juu wakati wa kutumia njia (2-3%). . Ongezeko la jumla la utendakazi baada ya uboreshaji wa msimbo lilikuwa 55%, na matokeo yaliongezeka kutoka 224k req/s hadi 347k req/s.
- Zima ulinzi dhidi ya athari za kubahatisha za utekelezaji. Kwa kutumia vigezo "nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off" wakati wa kupakia kerneli inayoruhusiwa kuongeza utendakazi kwa 28%, na upitishaji uliongezeka kutoka 347k req/s hadi 446k req/s. Kando, ongezeko kutoka kwa kigezo "nospectre_v1" (ulinzi kutoka kwa Specter v1 + SWAPGS) lilikuwa 1-2%, "nospectre_v2" (ulinzi kutoka kwa Specter v2) - 15-20%, "pti=off" (Specter v3/Meltdown) - 6 %, "mds=off tsx_async_abort=off" (MDS/Zombieload na TSX Asynchronous Abortion) - 6%. Mipangilio ya ulinzi dhidi ya L1TF/Foreshadow (l1tf=flush), iTLB multihit, Speculative Store Bypass na SRBDS mashambulizi yaliachwa bila kubadilika, ambayo hayakuathiri utendakazi kwa vile hayakuingiliana na usanidi uliojaribiwa (kwa mfano, mahususi kwa KVM, iliyopangwa. virtualization na mifano mingine ya CPU).
- Inazima ukaguzi na mifumo ya kuzuia simu za mfumo kwa kutumia amri ya "auditctl -a never,task" na kubainisha chaguo la "--security-opt seccomp=unconfined" unapoanzisha kontena la kituo. Ongezeko la jumla la utendakazi lilikuwa 11%, na matokeo yaliongezeka kutoka 446k req/s hadi 495k req/s.
- Inalemaza iptables/netfilter kwa kupakua moduli za kernel zinazohusiana. Wazo la kuzima ngome, ambalo halikutumiwa katika suluhu mahususi la seva, lilichochewa na matokeo ya wasifu, kwa kuzingatia ambayo kitendakazi cha nf_hook_slow kilichukua 18% ya muda kutekeleza. Ikumbukwe kwamba nftables hufanya kazi kwa ufanisi zaidi kuliko iptables, lakini Amazon Linux inaendelea kutumia iptables. Baada ya kuzima iptables, ongezeko la utendaji lilikuwa 22%, na matokeo yaliongezeka kutoka 495k req/s hadi 603k req/s.
- Uhamishaji uliopunguzwa wa vidhibiti kati ya viini tofauti vya CPU ili kuboresha ufanisi wa matumizi ya akiba ya kichakataji. Uboreshaji ulifanyika katika kiwango cha kushurutisha michakato ya kiboreshaji kwa cores za CPU (CPU Upachikaji) na kupitia kubandika vidhibiti vya mtandao wa kernel (Pokea Kuongeza Upande). Kwa mfano, irqbalance ilizimwa na uhusiano wa foleni kwa CPU umewekwa kwa uwazi katika /proc/irq/$IRQ/smp_affinity_list. Ili kutumia msingi uleule wa CPU kuchakata mchakato wa kiondoaji na foleni ya mtandao ya pakiti zinazoingia, kidhibiti maalum cha BPF kinatumika, kilichounganishwa kwa kuweka alama ya SO_ATTACH_REUSEPORT_CBPF wakati wa kuunda tundu. Ili kufunga foleni za pakiti zinazotoka kwa CPU, mipangilio /sys/class/net/eth0/queues/tx- imebadilishwa. /xps_cpus. Ongezeko la jumla la utendakazi lilikuwa 38%, na matokeo yaliongezeka kutoka req/s 603 hadi 834k req/s.
- Uboreshaji wa kushughulikia usumbufu na matumizi ya upigaji kura. Kuwasha modi ya kurekebisha-rx katika kiendeshi cha ENA na kuendesha sysctl net.core.busy_read iliongeza utendakazi kwa 28% (mapitio yaliongezeka kutoka 834k req/s hadi 1.06M req/s, na muda wa kusubiri ulipungua kutoka 361ΞΌs hadi 292ΞΌs).
- Kuzima huduma za mfumo zinazosababisha kuzuia bila ya lazima kwenye stack ya mtandao. Kuzima dhclient na kuweka mwenyewe anwani ya IP kulisababisha ongezeko la utendakazi la 6% na upitishaji uliongezeka kutoka 1.06M req/s hadi 1.12M req/s. Sababu ya dhclient kuathiri utendakazi ni katika uchanganuzi wa trafiki kwa kutumia tundu mbichi.
- Kupiga Spin Lock. Kubadilisha rafu ya mtandao hadi modi ya "noqueue" kupitia sysctl "net.core.default_qdisc=noqueue" na "tc qdisc replace dev eth0 root mq" ilisababisha ongezeko la utendakazi la 2%, na upitishaji uliongezeka kutoka 1.12M req/s hadi 1.15M. req/s.
- Uboreshaji mdogo wa mwisho, kama vile kuzima GRO (Upakiaji wa Jumla wa Kupokea) kwa amri ya "ethtool -K eth0 gro off" na kubadilisha algoriti ya udhibiti wa msongamano wa ujazo na reno kwa kutumia sysctl βnet.ipv4.tcp_congestion_control=renoβ. Ongezeko la jumla la tija lilikuwa 4%. Upitishaji uliongezeka kutoka req/s 1.15M hadi 1.2M req/s.
Mbali na uboreshaji ambao ulifanya kazi, nakala hiyo pia inajadili njia ambazo hazikusababisha ongezeko la utendaji linalotarajiwa. Kwa mfano, zifuatazo ziligeuka kuwa zisizofaa:
- Uendeshaji libreactor kando haukutofautiana katika utendaji na kuiendesha kwenye kontena. Kubadilisha writev kwa send, kuongeza matukio makubwa katika epoll_wait, na kujaribu matoleo na bendera za GCC hakukuwa na athari (athari ilionekana kwa bendera za "-O3" na "-march-native" pekee).
- Kusasisha kinu cha Linux hadi matoleo ya 4.19 na 5.4, kwa kutumia vipanga ratiba vya SCHED_FIFO na SCHED_RR, kudhibiti sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never, performance not affect_tscw.
- Katika kiendeshi cha ENA, kuwezesha hali za Kupakia (kugawanya, kukusanya-kutawanya, rx/tx checksum), kujenga kwa alama ya "-O3", na kutumia ena.rx_queue_size na ena.force_large_llq_header vigezo havikuwa na athari.
- Mabadiliko katika safu ya mtandao hayakuboresha utendakazi:
- Zima IPv6: ipv6.disable=1
- Zima VLAN: modprobe -rv 8021q
- Zima ukaguzi wa chanzo cha kifurushi
- net.ipv4.conf.all.rp_filter=0
- net.ipv4.conf.eth0.rp_filter=0
- net.ipv4.conf.all.accept_local=1 (athari hasi)
- 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
Chanzo: opennet.ru