Linux-optimalisering om 1.2 miljoen JSON-versoeke per sekonde te hanteer

'n Gedetailleerde gids is gepubliseer oor die instel van die Linux-omgewing om maksimum werkverrigting vir die verwerking van HTTP-versoeke te behaal. Die voorgestelde metodes het dit moontlik gemaak om die werkverrigting van die JSON-verwerker gebaseer op die libreactor-biblioteek in die Amazon EC2-omgewing (4 vCPU) te verhoog van 224 duisend API-versoeke per sekonde met standaardinstellings van Amazon Linux 2 met kern 4.14 tot 1.2 miljoen versoeke per sekonde tweede ná optimalisering ('n toename van 436%), en het ook gelei tot 'n vermindering in vertragings in die verwerking van versoeke met 79%. Die voorgestelde metodes is nie spesifiek vir libreactor nie en werk wanneer ander http-bedieners gebruik word, insluitend nginx, Actix, Netty en Node.js (libreactor is in toetse gebruik omdat 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.
• Deaktiveer beskerming teen spekulatiewe uitvoering kwesbaarhede. Deur die parameters “nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off” te gebruik wanneer die kern gelaai word, kon werkverrigting met 28% verhoog word, en deurset het toegeneem van 347k versoek/s tot 446k versoek/s. Afsonderlik was die toename vanaf die parameter "nospectre_v1" (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 (l1tf=spoel), iTLB multihit, Speculative Store Bypass en SRBDS-aanvalle is onveranderd gelaat, wat nie werkverrigting beïnvloed het nie, aangesien hulle nie met die getoetste konfigurasie gekruis het nie (byvoorbeeld 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 die firewall, wat nie in 'n spesifieke bedieneroplossing gebruik is nie, te deaktiveer, is aangespoor deur profileringsresultate, te oordeel waarvolgens die nf_hook_slow-funksie 18% van die tyd geneem het om uit te voer. Daar word opgemerk dat nftables doeltreffender werk as iptables, maar Amazon Linux gebruik steeds iptables. Nadat iptables gedeaktiveer is, was die prestasieverhoging 22%, en deurset het toegeneem van 495k versoek/s tot 603k versoek/s.
• 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 lei tot onnodige blokkering in die netwerkstapel. Die deaktivering van dhclient en die handmatige instelling van die IP-adres het gelei tot 'n 6% prestasieverhoging en deurset het van 1.06M versoek/s tot 1.12M versoek/s toegeneem. Die rede waarom dhclient prestasie beïnvloed, is in 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 opgradering van die Linux-kern na weergawes 4.19 en 5.4, deur gebruik te maak van die SCHED_FIFO- en SCHED_RR-skeduleerders, die manipulering van sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=nooit, skew_tick=1 en klok het nie werkverrigting beïnvloed nie.
• 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