Optimization Linux om 1.2 miljoen JSON-versoeke per sekonde te verwerk

'n Gedetailleerde gids vir die instelling van die omgewing is gepubliseer. Linux om maksimum werkverrigting vir HTTP-versoekverwerking te behaal. Die voorgestelde metodes het ons toegelaat om die werkverrigting van die JSON-ontleder gebaseer op die libreactor-biblioteek in 'n Amazon EC2-omgewing (4 vCPU's) te verhoog vanaf 224 000 API-versoeke per sekonde onder standaard Amazon-instellings. Linux 2 met kern 4.14 het die deurset verhoog tot 1.2 miljoen versoeke per sekonde na optimalisering (’n toename van 436%), en ook die verwerking van versoeke met 79% verminder. Die voorgestelde metodes is nie spesifiek vir libreactor nie en werk met ander HTTP-bedieners, insluitend nginx, Actix, Netty en Node.js (libreactor is in die toetse gebruik, aangesien die oplossing wat daarop gebaseer is, beter werkverrigting getoon het).

Basiese optimalisering:

• Optimaliseer bevryder-kode. Die R18-opsie van die Techempower-stel is as basis gebruik, wat verbeter is deur kode te verwyder om die aantal SVE-kerns wat gebruik word te beperk (optimering het dit moontlik gemaak om werk met 25-27% te versnel, en in GCC saam te stel met die "-O3"-opsies ('n toename van 5-10%) en "-march-native" (5-10%), vervang lees/skryf-oproepe met recv/send (5-10%) en vermindering van bokoste wanneer pthreads gebruik word (2-3%) . Die algehele prestasieverhoging na kode-optimering was 55%, en deurset het toegeneem van 224k versoek/s tot 347k versoek/s.
• Deaktivering van beskerming teen kwesbaarhede wat veroorsaak word deur spekulatiewe uitvoering van instruksies. Deur die kern-opstartparameters "nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off" te gebruik, het die werkverrigting met 28% verhoog, en die deurset het toegeneem van 347k req/s tot 446k req/s. Individueel was die wins van die "nospectre_v1" parameter (beskerming teen Spectre v1 + SWAPGS) 1-2%, "nospectre_v2" (beskerming teen Spectre v2) - 15-20%, "pti=off" (Spectre v3/Meltdown) - 6%, "mds=off tsx_async_abort=off" (MDS/Zombieload en TSX Asynchronous Abort) - 6%. Die instellings vir beskerming teen L1TF/Foreshadow-aanvalle (l1tf=flush), iTLB multihit, Speculative Store Bypass en SRBDS, wat nie die werkverrigting beïnvloed het nie, is onveranderd gelaat, aangesien hulle nie met die getoetste konfigurasie oorvleuel het nie (byvoorbeeld, hulle is spesifiek vir KVM, geneste virtualisering en ander SVE-modelle).
• Deaktiveer ouditering en stelseloproepblokkeringsmeganismes deur die "auditctl -a never,task" opdrag te gebruik en die "--security-opt seccomp=unconfined" opsie te spesifiseer wanneer die docker-houer begin word. Die algehele prestasieverhoging was 11%, en deurset het van 446k versoek/s tot 495k versoek/s toegeneem.
• Deaktiveer iptables/netfilter deur geassosieerde kernmodules af te laai. Die idee om 'n firewall te deaktiveer wat nie in 'n spesifieke bedieneroplossing gebruik is nie, is aangespoor deur profileringsresultate, wat getoon het dat die nf_hook_slow-funksie 18% van die tyd aan uitvoering bestee het. Daar word opgemerk dat nftables meer doeltreffend is as iptables, maar op Amazon Linux iptables word steeds gebruik. Nadat iptables gedeaktiveer is, het die werkverrigting met 22% toegeneem, en die deurset het van 495k req/s tot 603k req/s toegeneem.
• Verminderde migrasie van hanteerders tussen verskillende SVE-kerne om die doeltreffendheid van verwerkerkasgebruik te verbeter. Optimalisering is uitgevoer op die vlak van die binding van bevryderprosesse aan SVE-kerns (CPU Pinning) en deur die vaspen van kernnetwerkhanteerders (Receive Side Scaling). Byvoorbeeld, irqbalance is gedeaktiveer en tou-affiniteit vir die SVE is eksplisiet in /proc/irq/$IRQ/smp_affinity_list gestel. Om dieselfde SVE-kern te gebruik om die bevryder-proses en die netwerk-tou van inkomende pakkies te verwerk, word 'n pasgemaakte BPF-hanteerder gebruik, verbind deur die SO_ATTACH_REUSEPORT_CBPF-vlag te stel wanneer die sok geskep word. Om rye van uitgaande pakkies aan die SVE te bind, is die instellings /sys/class/net/eth0/queues/tx- verander /xps_cpus. Die algehele prestasieverhoging was 38%, en deurset het toegeneem van 603k versoek/s tot 834k versoek/s.
• Optimalisering van onderbrekingshantering en gebruik van peiling. Deur die adaptive-rx-modus in die ENA-bestuurder te aktiveer en sysctl net.core.busy_read te manipuleer, het werkverrigting met 28% verhoog (deurset het toegeneem van 834k req/s tot 1.06M req/s, en latency het van 361μs tot 292μs afgeneem).
• Deaktiveer stelseldienste wat onnodige netwerkstapelblokke veroorsaak. Deaktiveer dhclient en installeer IP-adresse Die handmatige uitvoering van hierdie taak het 'n 6%-prestasietoename tot gevolg gehad, met deurset wat van 1.06 miljoen aanv/s tot 1.12 miljoen aanv/s toegeneem het. Die rede vir dhclient se impak op prestasie is as gevolg van verkeersanalise met behulp van 'n rou sok.
• Veg Spin Lock. Die oorskakeling van die netwerkstapel na "noqueue"-modus via sysctl "net.core.default_qdisc=noqueue" en "tc qdisc replace dev eth0 root mq" het gelei tot 'n 2% prestasieverhoging, en deurset het toegeneem van 1.12M req/s tot 1.15M versoek/s.
• Finale geringe optimaliserings, soos om GRO (Generic Receive Offload) te deaktiveer met die opdrag "ethtool -K eth0 gro off" en die vervanging van die kubieke opeenhopingsbeheeralgoritme met reno deur sysctl "net.ipv4.tcp_congestion_control=reno" te gebruik. Die algehele produktiwiteitsverhoging was 4%. Deurvloei het van 1.15M versoek/s tot 1.2M versoek/s toegeneem.

Benewens die optimaliserings wat gewerk het, bespreek die artikel ook metodes wat nie tot die verwagte prestasieverhoging gelei het nie. Die volgende het byvoorbeeld geblyk ondoeltreffend te wees:

• Om libreactor afsonderlik te laat loop het nie verskil in werkverrigting as om dit in 'n houer te laat loop nie. Die vervanging van writev met send, die verhoging van maxevents in epoll_wait, en eksperimentering met GCC-weergawes en vlae het geen effek gehad nie (die effek was slegs opmerklik vir die "-O3" en "-march-native" vlae).
• Die kernopdatering het nie die werkverrigting beïnvloed nie. Linux tot weergawes 4.19 en 5.4, met behulp van die SCHED_FIFO en SCHED_RR skeduleerders, manipulasie van sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never, skew_tick=1 en clocksource=tsc.
• In die ENA-drywer, die aktivering van Aflaai-modusse (segmentering, scatter-gather, rx/tx checksum), bou met die "-O3" vlag, en die gebruik van die ena.rx_queue_size en ena.force_large_llq_header parameters het geen effek gehad nie.
• Veranderinge in die netwerkstapel het nie werkverrigting verbeter nie:
  • Deaktiveer IPv6: ipv6.disable=1
  • Deaktiveer VLAN: modprobe -rv 8021q
  • Deaktiveer pakketbronkontrolering
    • net.ipv4.conf.all.rp_filter=0
    • net.ipv4.conf.eth0.rp_filter=0
    • net.ipv4.conf.all.accept_local=1 (negatiewe effek)
  • 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

  Bron: opennet.ru